Cryptographic Algorithms and Protocols

1
Cryptographic Algorithms and Protocols

• Text Book Williams Stalling
• Lecture Notes Adapted from that of Lawrie Brown
• Lecturer
• Professor Frances Yao Professor Xiaotie Deng
• Department of Computer Science
• City University of Hong Kong

2
Digital Signatures Authentication

• Digital Signature Using PKC
• Third Trusted Party Protocol
• Symmetric Key Cryptographic Solution for
  Authentication
• PKC solution for Authentication

3
Digital Signature with PKC
4
Introduction of Digital Signatures

• The notion of a digital signature may prove to be
  one of the most fundamental and useful inventions
  of modern cryptography.
• A signature scheme provides a way
• for each user to sign messages
• the signature can later be verified by anyone
  else.

5
Digital Signature Requirements

• Must depend on the message signed
• Must use information unique to sender
• to prevent both forgery and denial
• Must be relatively easy to produce
• Must be relatively easy to recognize verify
• Must be computationally infeasible to forge
• with new message for existing digital signature
• with fraudulent digital signature for given
  message
• Must be practical to save digital signature in
  storage

6
Use of PKC for Direct Digital Signatures

• Each user can create a matched pair of
• private and public keys
• so that only he can create
• a signature for a message (using his private
  key),
• but anyone can verify the signature for the
  message (using the signers public key).

7
Digital signature using RSA

• Suppose the public-key of A is (n, e) and the
  private-key is (n, d).
• Then to sign a message m,
• A just simply computes smd (mod n) as the
  digital signature of m.
• Then to verify the signature s of a message m,
• Compute se and check if it is m,
• Must be mde(mod n)m(mod n) if s is the valid
  signature

8
Property of PKC based Digital Signatures

• MAC does not address issues of lack of trust
• E.g., non-repudiation
• Digital signatures provide the ability to
• verify author, date time of signature
• authenticate message contents
• Be verifiable by third parties to resolve
  disputes
• Hence, it includes authentication function with
  additional capabilities

9
Possible Attacks

• An attacker can publish a public key claimed to
  be another persons.
• Key may be lost
• Administrative control of secure private key
• Time stamp and prompt report of losing key
• Adversary could sign with time stamp earlier?

10
Arbitrated Digital Signatures

• Use arbiter A to
• validates any signed message
• then dated and sent to recipient
• It requires suitable level of trust in arbiter
• It can be implemented with either private or
  public-key algorithms
• Arbiter may or may not see message

11
Arbiter Sees Message from X to Y

• X?A M EKxaIDX H(M)
• Send the message M and
• Encrypted ID of X and a hash of M, H(M)
• A?Y EKayIDX M EKxaIDX H(M) T
• Send the above and time and arbiters ID,
  encrypted with the shared secrete key of A and Y

12
Arbiter does not see message

• X?A
• EKxy M EKxaIDX H(EKxy M)
• A?Y
• EKayIDX EKxy M EKxaIDX H(EKxy M)
  T

13
Public key, Arbiter does not see Message

• X?A
• IDX EKRxIDX EKUy EKRx (M)
• A?Y
• EKRaIDX EKUy EKRx (M) T

14
Public-Key Certificate

• If the directory of public-keys is accessed over
  the network, one needs to protect the users from
  being fraudulent messages purporting to be
  public-keys from the directory.
• An elegant solution is the use of certificate a
  copy of a users public-key digitally signed by
  the public-key directory manager or other trusted
  party.

15

• If user A keeps locally a copy of the public-key
  of the directory manager, he can validate all the
  signed communications from the public-key
  directory and avoid being tricked into using
  fraudulent keys.
• Moreover, each user can transmit the certificate
  for his public-key with any message he signs,
  thus removing the need for a central directory
  and allowing one to verify signed messages with
  no information other than the directory managers
  public-key.

16
Authentication Protocols

• To convince parties of each others identity
  and/or to exchange session keys
• One-way or mutual
• key issues are
• confidentiality to protect session keys
• timeliness to prevent replay attacks

17
Replay Attacks

• Where a valid signed message is copied and later
  resent
• simple replay
• repetition that can be logged
• repetition that cannot be detected
• backward replay without modification
• countermeasures include
• use of sequence numbers (generally impractical)
• timestamps (needs synchronized clocks)
• challenge/response (using unique nonce)

18
Using Symmetric Encryption

• as discussed previously we can use a two-level
  hierarchy of keys
• usually with a trusted Key Distribution Center
  (KDC)
• each party shares own master key with KDC
• KDC generates session keys used for connections
  between parties
• master keys used to distribute keys to them

19
Needham-Schroeder Protocol

• Original third-party key distribution protocol
• for session between A B mediated by KDC
• protocol overview is
• 1. A?KDC IDA IDB N1
• 2. KDC?A EKaKs IDB N1 EKbKsIDA
• 3. A?B EKbKsIDA
• 4. B?A EKsN2
• 5. A?B EKsf(N2)

20
Needham-Schroeder Protocol

• To securely distribute a new session key for
  communications between A B
• but it is vulnerable to a replay attack if an old
  session key has been compromised
• then message 3 can be resent convincing B that is
  communicating with A
• Modifications to address this require
• timestamps (Denning 81)
• using an extra nonce (Neuman 93)

21
Using Public-Key Encryption

• A range of approaches are based on the use of
  public-key encryption
• Ensure to have correct public keys for other
  parties
• Using a central Authentication Server (AS)
• Various protocols exist using timestamps or nonces

22
Denning AS Protocol

• Denning 81 presented the following
• A?AS IDA IDB
• AS?A
• EKRasIDAKUaT EKRasIDBKUbT
• A?B
• EKRasIDAKUaT EKRasIDBKUbT
  EKUbEKRaKsT
• Session key is chosen by A
• timestamps prevent replay but require
  synchronized clocks
• NOTE KU public key, KR private key

23
One-Way Authentication

• Required when sender receiver are not in
  communications at same time (eg. email)
• It has header in clear so can be delivered by
  email system
• We may want contents of body protected sender
  authenticated

24
Using Symmetric Encryption

• We can refine use of KDC but cant have final
  exchange of nonces, vis
• 1. A?KDC IDA IDB N1
• 2. KDC?A EKaKs IDB N1 EKbKsIDA
• 3. A?B EKbKsIDA EKsM
• Therefore, it does not protect against replays
• could rely on timestamp in message, though email
  delays make this problematic

25
Public-Key Approaches

• There have been some public-key approaches
• if confidentiality is major concern, we can use
• A?B EKUbKs EKsM
• It has an encrypted session key, encrypted
  message
• If authentication is needed, use a digital
  signature with a digital certificate
• A?B M EKRaH(M) EKRasTIDAKUa
• with message, signature, certificate

26
Digital Signature Standard (DSS)

• US Govt approved signature scheme FIPS 186
• uses the SHA hash algorithm
• designed by NIST NSA in early 90's
• DSS is the standard, DSA is the algorithm
• a variant on ElGamal and Schnorr schemes
• creates a 320 bit signature, but with 512-1024
  bit security
• security depends on difficulty of computing
  discrete logarithms

27
DSA Key Generation

• It has a shared global public key values (p,q,g)
  
• a large prime 2L-1 ltplt2L
• where L 512 to 1024 bits and is a multiple of 64
  
• choose q, a 160 bit prime factor of p-1
• 2159 ltqlt2160
• (p-1)/q is an integer
• choose g h(p-1)/q (mod p)
• where 1lthltp-1, h(p-1)/q (mod p) gt 1
• Users choose private compute public key
• Private key x 0ltxltq
• Public key y gx (mod p)

28
DSA Signature Creation

• To sign a message M the sender
• generates a random signature key k, kltq
• k must be random, be destroyed after use, and
  never be reused
• then computes signature pair
• r (gk(mod p))(mod q)
• s (k-1SHA(M) xr)(mod q)
• sends signature (r,s) with message M

29
DSA Signature Verification

• having received M signature (r,s)
• to verify a signature, recipient computes
• w s-1(mod q)
• u1 (SHA(M)w)(mod q)
• u2 (rw)(mod q)
• v (gu1yu2(mod p)) (mod q)
• if vr then signature is verified
• see book web site for details of proof why

30
Summary

• have considered
• digital signatures
• authentication protocols (mutual one-way)
• digital signature standard

31
Collision

• Can two messages hash to the same value?
• Throw n1 balls guarantees a collision.
• But ?n random balls likely have a collision.
• N 365 Birthday attack

balls
n boxes
32
Chapter 14 Authentication Applications

• We cannot enter into alliance with neighboring
  princes until we are acquainted with their
  designs.
• The Art of War, Sun Tzu

33
Authentication Applications

• Application-level authentication digital
  signatures
• Kerberos a private-key authentication service
• Pronounced as KERR-berr-ross
• http//web.mit.edu/kerberos/www/
• X.509 directory authentication service

34
Kerberos

• Trusted key server system from MIT
• Centralised private-key third-party
  authentication in a distributed network
• Allows users access to services distributed
  through network
• All trust a central authentication server
• No need to trust all workstations
• Two versions in use 4 5

35
Kerberos Requirements

• First published report identified its
  requirements as
• security
• reliability
• transparency
• scalability
• Implemented using an authentication protocol
  based on Needham-Schroeder

36
Kerberos 4 Overview

• A basic third-party authentication scheme
• an Authentication Server (AS)
• A user initially negotiates with AS to identify
  itself
• AS provides a non-corruptible authentication
  credential (ticket-granting ticket TGT)
• A Ticket-Granting server (TGS)
• A user subsequently requests access to other
  services from TGS on basis of the users TGT

37
A simple authentication dialogue

• C-gtAS IDCPCIDV
• AS-gtC Ticket
• C-gtV IDCTicket
• TicketEKvIDCADCIDV
• Cclient, VServer, ASAuthentication Server
• IDCid of user on C, PCpassword of user on C
• ADCnet address of C
• Kvsecret encryption key shared by AS and V

38
A more secure authentication dialogue

• Once per user logon session
• C-gtAS IDCIDtgs
• AS-gtC EKcTickettgs
• Once per type of service
• C-gtTGS IDC IDV Tickettgs
• TGS-gtC TicketV
• Once per service session
• C-gtV IDCTicket V
• TickettgsEKtgsIDCADCIDtgs TS1
  Lifetime1
• TicketvEKvIDCADCIDv TS2 Lifetime2
• TStime stamp

39
Kerberos Version 4

• Authentication Service Exchange to get tgt
• C-gtAS IDCIDtgs TS1
• AS-gtC EKcKc,tgsIDtgs TS2 Lifetime2Ticket
  tgs
• TickettgsEKtgsKc,tgsIDCADCIDtgs TS2
  Lifetime2
• Ticket-Granting Service Exchange to get sgt
• C-gtTGS IDvTickettgsAuthenticatorc
• TGS-gtC EKc,tgsKc,vIDvTSv Ticketv
• TicketvEKyKc,v IDCADCIDv TS4
  Lifetime4
• AuthenticatorcEKc,tgsIDCADCTS3
• Client/Server Authentication Exchange to get
  service
• C-gtV Ticket VAuthenticatorc
• V-gtC EKc,vTS51

40
Kerberos 4 Overview
41
Kerberos Realms

• a Kerberos environment consists of
• a Kerberos server
• a number of clients, all registered with server
• application servers, sharing keys with server
• this is termed a realm
• typically a single administrative domain
• if have multiple realms, their Kerberos servers
  must share keys and trust

42
Kerberos Version 5

• developed in mid 1990s
• provides improvements over v4
• addresses environmental shortcomings
• encryption alg, network protocol, byte order,
  ticket lifetime, authentication forwarding,
  interrealm auth
• and technical deficiencies
• double encryption, non-std mode of use, session
  keys, password attacks
• specified as Internet standard RFC 1510

43
X.509 Authentication Service

• part of CCITT X.500 directory service standards
• http//www.surfnet.nl/innovatie/afgesloten/x500/in
  troducing/glossary.html
• distributed servers maintaining some info database

44
X.509 Authentication Service

• http//www.ietf.org/html.charters/pkix-charter.htm
  l
• Defines framework for authentication services
• directory may store public-key certificates
• with public key of user
• signed by certification authority
• Also defines authentication protocols
• Uses public-key crypto digital signatures
• algorithms not standardised, but RSA recommended

45
X.509 Certificates

• issued by a Certification Authority (CA),
  containing
• version (1, 2, or 3)
• serial number (unique within CA) identifying
  certificate
• signature algorithm identifier
• issuer X.500 name (CA)
• period of validity (from - to dates)
• subject X.500 name (name of owner)
• subject public-key info (algorithm, parameters,
  key)
• issuer unique identifier (v2)
• subject unique identifier (v2)
• extension fields (v3)
• signature (of hash of all fields in certificate)
• notation CAltltAgtgt denotes certificate for A signed
  by CA

46
X.509 Certificates
47
Obtaining a Certificate

• any user with access to CA can get any
  certificate from it
• only the CA can modify a certificate
• because cannot be forged, certificates can be
  placed in a public directory

48
CA Hierarchy

• if both users share a common CA then they are
  assumed to know its public key
• otherwise CA's must form a hierarchy
• use certificates linking members of hierarchy to
  validate other CA's
• each CA has certificates for clients (forward)
  and parent (backward)
• each client trusts parents certificates
• enable verification of any certificate from one
  CA by users of all other CAs in hierarchy

49
CA Hierarchy Use
50
Certificate Revocation

• certificates have a period of validity
• may need to revoke before expiry, eg
• user's private key is compromised
• user is no longer certified by this CA
• CA's certificate is compromised
• CAs maintain list of revoked certificates
• the Certificate Revocation List (CRL)
• users should check certs with CAs CRL

51
Authentication Procedures

• X.509 includes three alternative authentication
  procedures
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures

52
One-Way Authentication

• 1 message ( A-gtB) used to establish
• the identity of A and that message is from A
• message was intended for B
• integrity originality of message
• message must include timestamp, nonce, B's
  identity and is signed by A
• AtA,rA,IDB,sgnData,EKUbKab
• A means A signs the

53
Two-Way Authentication

• 2 messages (A-gtB, B-gtA) which also establishes in
  addition
• the identity of B and that reply is from B
• that reply is intended for A
• integrity originality of reply
• reply includes original nonce from A, also
  timestamp and nonce from B
• AtA,rA,IDB,sgnData,EKUbKab
• BtB,rB,IDA,rA,sgnData,EKUaKba

54
Three-Way Authentication

• 3 messages (A-gtB, B-gtA, A-gtB) which enables above
  authentication without synchronized clocks
• has reply from A back to B containing signed copy
  of nonce from B
• means that timestamps need not be checked or
  relied upon
• AtA,rA,IDB,sgnData,EKUbKab
• BtB,rB,IDA,rA,sgnData,EKUaKba
• ArB

55
X.509 Version 3

• has been recognised that additional information
  is needed in a certificate
• email/URL, policy details, usage constraints
• rather than explicitly naming new fields defined
  a general extension method
• extensions consist of
• extension identifier
• criticality indicator
• extension value

56
Certificate Extensions

• key and policy information
• convey info about subject issuer keys, plus
  indicators of certificate policy
• certificate subject and issuer attributes
• support alternative names, in alternative formats
  for certificate subject and/or issuer
• certificate path constraints
• allow constraints on use of certificates by other
  CAs

57
Summary

• have considered
• Kerberos trusted key server system
• X.509 authentication and certificates