Digital signatures, DSS and authentication protocols

1
Digital signatures, DSS and authentication
protocols
2
Digital Signatures

• Message authentication protects two parties from
  a third party, but not against each other!
• The receiver B can forge a message and claim that
  it came from A.
• If previous is possible, then A can always deny
  having sent a message received by B, claiming it
  as forged by B.
• Thus in situation when there is no complete trust
  between the parties a digital signature is
  needed.
• A digital signature must have the following
  properties
• It must be able to verify the author and the date
  and the time of the signature
• It must be able to verify the contents at the
  time of the signature.
• The signature must be verifiable by a third party
  to resolve disputes

3
Digital Signatures

• Based on the previous properties, we can state
  the reauirements for a digital signature
• The signature must be a function of the whole
  message being signed
• The signature must use some information unique to
  the sender to prevent both forgery and denial
• It must be easy to produce a signature
• It must be easy to recognize and verify a
  signature
• It must be computationally infeasible to forge a
  digital signature
• by constructing a new message for existing
  signature
• by constructing a fraudulent signature for a
  given message
• It must be practical to retain a copy of a
  digital signature.
• A secure hash-function used in a way shoown in
  fig. 8.5c or 8.5d satisfies these requirements.
• The approaches for the digital signature function
  fall into two categories, direct and arbitrated.
  

4
Digital Signatures - direct

• Only the two communicating parties are involved.
• It is assumed that the destinaton knows the
  public key of the source.
• A digital signature can be formed either by
  encryptin the whole message (fig. 8.1c) or a hash
  code (fig 8.5c) with the senders private key.
• Confidentiality is provided by further encrypting
  the entire message and the signature with either
  receivers public key (fig 8.1d) or a common
  secret key (fig 8.5d).
• Direct digital signature schemes all have a
  weakness The validity of the scheme depends on
  the secrecy of the senders private key.
• if a sender later wants to deny a message, he can
  claim that the secrecy of the private key was
  compromized (stolen, lost...) and that somebody
  else used it to forge the signature.
• also the key might actually be stolen from X at
  time T. The opponent can then send a message
  signed with Xs signature and with a time stamp
  earlier than T.
• Administrative controls can weaken these threats
  but not eliminate them.
• for instance every signed message can be required
  to have a time stamp, immediate reporting of
  compromized keys to central authotity can be
  required.

5
Digital Signatures - arbitrated

• A trusted system, an arbiter, is used to address
  the problem of direct digital signatures
• There are many arbitrated digital signature
  schemes. The general operation is as follows
• every signed message from sender X to receiver Y
  goes first to arbiter A
• A checks the origin and contents of the message
• A adds a timestamp and sends it to Y with an
  indication that the message has been verified by
  the arbiter.
• In order for this scheme to work, all parties
  must have a great deal of trust on the
  arbitration mechanism.
• 10.1a conventional encryption is used
• A is able to read the messages, and so are
  eavesdroppers
• In case of dispute, Y, claiming to have received
  M from X send the following message to A
  EKayIDXM EKaxIDX H(M)
• It is assumed that X and A share a secret key Kax
  and Y and A share Kay.

6
(No Transcript)
7
Digital Signatures - arbitrated

• 10.1b arbitration is provided as before, but also
  confidentiality
• It is assumed that X and Y share a secret key
  Kxy..
• A operates only on encrypted message, but can
  still prevent fraud from either party.
• There still remains a threat A can form an
  alliance with the sender to deny a message or
  with a receiver to construct a fraud message.
  Thus schemes a and b both sides must have a high
  degree of trust in A.
• In 10.1c these problems are solved by a public
  key scheme
• No information is shared among the parties before
  the communication, preventing alliances to
  defraud.
• No incorrectly dated messages can be sent, even
  if KRx is compromised ( as long as KRx is not).
• The content of the message is secret to A and
  anyone else.

8
Digital Signature Standard (DSS)

• DSS is a NIST FIPS PUB 186 standard.
• DSS uses SHA-1 to construct a digital signature
  technique, the Digital Signature Algorithm (DSA)
• Proposed in 1991, revisions in 1993 and 1996.
• DSA is besed on discrete logarithms according to
  ElGamal cryptographic scheme.
• DSS is provides only the digital signature
  function.
• DSS can not be used for encryption
• In DSS the hash code is provided as input to a
  signature function, along with a secret random
  number k.
• The global public key components are two large
  primes p and q and the a chosen value g. The
  global public key is (p,q,g).
• The user has also a private key x and a related
  public key y.
• In addition to these, the message hash code H(M)
  and a secret randomly generated integer k unique
  to each message are needed to create a signature.

9
(No Transcript)
10
Digital Signature Standard (DSS)

• The signature consists of two values, s that is a
  function of the message, and r that does not
  depend on the message.
• The test of the signature is on the value r,
  which is a function of the random nubmer k and
  the global key. Using the message, users public
  key and the global public key the receiver can
  recover r.
• The reason for this complicated scheme is that
  all computationally demanding calculations are
  independent of the message contents, and thus can
  be calculated once beforehand for a larege set of
  messages.

11
(No Transcript)
12
Authentication protocols

• The basic techiques for authenticaton discussed
  with hash-functions and MACs, and the digital
  signature, are used as such in many apllications.
  However, more complex protocols are increasinly
  required in many applications.
• We examine such authentication protocols, based
  on either conventional or public key
  cryptography, on the general areas of mutual
  authentication and one-way authentication.

13
Authentication protocols mutual authentication

• Mutual authentication protocols enable the
  communicating parties to satisfy themselves
  mutually about each others identity, and
  subsequently exchange session keys. ( we examined
  mutual key exchange earlier, but without the
  emphasis on authentication).
• Two central requirements of authenticated key
  echange are
• Confidentiality
• Timeliness
• Confidentiality is needed to countermeasure
  masquerade and to prevent compromise of the
  session keys.
• essential identification information and the
  session keys must be encrypted
• this requires the prior existence of secret or
  public keys for this purpose
• Timeliness is required to countermeasure any form
  of replay attack, in the form of message replays.
  The replays could allow the opponent to
  impersonate another party or to compromise a
  session key. At minimum replay attacks can
  disrupt the authentication protocol.

14
Authentication protocols mutual authentication

• Replay attacks can take the following forms
• Simple replay the opponent simply copies a
  message and resends it later.
• Repetition that can be logged An opponent
  replays a timestamped message within the valid
  time-window.
• Repetition that can not be detected The original
  message is supressed and only the replay message
  arrives.
• Backward replay without modification a replay
  back to the message sender, possible if
  convetional encryption is used.
• A straightforward way of coping with replay
  attacks is to attache a sequence number into the
  messages used in authentication exchange. A
  message is accepted only if the sequence number
  is in proper order.
• There is an overhead for each party to keep track
  of the last sequence number used with each
  claimant. Because of this, the following two
  general appraches are used instead
• Timestamps
• Challenge/response

15
Authentication protocols mutual authentication

• Timeliness
• A party accepts a message as fresh only if the
  message contains a timestamp that is close enough
  of the current time, according to As judgement.
  This requires some form of clock syncronization.
• Any timestamp based protocol must use a time
  window sufficiently large to accommodate network
  delays and clock desyncronization, yet
  sufficiently small to minimize replay attacks.
• Use with connection-oriented applications should
  be done with precaution.
• Challenge/response
• Party A, expaecting a fresh message from B, first
  sends a nonce (challence) to B and requires that
  the subsequent message(response) from B contains
  the correct nonce.
• Not suitable for connetionless applications. The
  required handshake before the connectionless
  transmission negates the chief characteristic of
  connectionless transmission and is thus
  unbearable overhead. These applications should
  rely on a secure time server and timestamp
  approach.

16
Authentication protocols mutual
authenticationconventional encryption approaches

• A similar two level hierarchy using a trusted KDC
  (Key Distribution Centre) as discussed earlier
  forms the basis for all protocols.
• Each party shares a master key with the KDC.
• KDC is responsible for generating the session
  keys used for a short period of time in
  communication between the parties.
• KDC distributes the session keys encrypted with
  master keys.
• An example of a such scheme is Kerberos.
• We start with the key distribution scheme
  presented in fig. 5.9., find the possible threats
  and improve gradually the scheme.
• This scheme can be stated as follows
• A ? KDC IDA IDB N1
• KDC? A EKaKs IDB N1 EKbKs IDA
• A?B EKbKs IDA
• B?A EKsN2
• A?B EKsf(N2)

17
(No Transcript)
18
Authentication protocols mutual
authenticationconventional encryption approaches

• Steps 4. and 5. counter a simple replay attack
  where the opponent replays the message 3 to
  disrupt operations at B.
• There is another vuolnerability suppose that the
  opponent X has been able to compromise an old
  session key. Now X is able to impersonate A and
  fool B to use the old key by simply replaying old
  step 3. If B does not check against used keys
  there is no way B can detect the attack and X
  will be authenticated an A in steps 4. and 5.
• This weakness is contered by adding a timestamp
  to messages in steps 2. and 3. to assure A and B
  that the session key has just been created.
• A ? KDC IDA IDB
• KDC? A EKaKs IDB T N1 EKbKs IDA
  T
• A?B EKbKs IDA T
• B?A EKsN2
• A?B EKsf(N2)
• The nonces in 1. and 2. are not needed any more.
• This fixes the problem, but there is still a
  concenr about suppress replay attack applicable
  if the clocks get unsyncronized. In this attack
  the senders clock is ahead of the receivers, and
  an opponent replays a message when its timestamp
  becomes valid.

19
Authentication protocols mutual
authenticationconventional encryption approaches

• Now the protocol is further revised to
  contermeasure these problems. The idea is that
  the receiver will only check the validity of
  self-generated timestamps, thus eliminating the
  clock syncronization problem.
• The new protocol is as follows
• A ? B IDA NA
• B? KDC IDB Nb EKbIDA Na Tb
• KDC?A EKaKs IDB Na Tb EKbIDA Ks
  Tb Nb
• A?B EKbIDA Ks Tb EKs Nb
• The nonce Na will be returned to A in an
  encrypted message containing the session key thus
  assuring A of its currency.
• B alerts KDC for a session key. The message
  includes a nonce Nb that will be returned to B in
  an ancrypted message containing the session key
  thus assuring B of its currency. The message also
  includes a block encrypted with secret key shared
  by B and KDC. based on this block KDC can issue
  credentials to A the block specifiea the inteded
  recepient and expiration time of the credentials.
• The KDC returns Na (which it learned from B) to A
  in an encrypted block containing also the session
  key, its expiration time, verification of Bs
  identity. Also included is a ticket for B to be
  used in subsequent authenticaitons.

20
Authentication protocols mutual
authenticationconventional encryption approaches

• A transmits the ticket to B together with Bs
  nonce Nb encrypted with session key. The ticket
  provides B with the session key, and the fact
  that the nonce was encrypted with the session key
  autenthicates that the message came from A and is
  not a replay.
• This protocol leaves A in the posession of a key
  that can be used for subsequent authentication to
  B avoiding the need to contact KDC frequently.
  Suppose that A and B used the protocol and then
  ended the session. Now within the time limit of
  the ticket, A desires a new session. The
  following protocol is used
• A ? B EKbIDA Ks Tb Na
• B? A Nb EKsNa
• A?B EKsNb
• B checks the currency of the session key from a
  self-generated expiration timestamp, so no
  syncronization is needed.
• The nonces constitute a normal handshaking
  against replays.

21
Authentication protocols mutual
authenticationpublic-key encryption approaches

• In public-key protocols an authetication server
  (AS) is used to provide public-key cerificates
  (discussed previously in the context of key
  distribution). The other possibility, that both
  parties are aware of each others public keys is
  not always practical (Fig. 6.15.)
• A compact protocol using timestamps agaisn
  replays is
• A ? AS IDA IDB
• AS? A EKRasIDA KUa T EKRasIDB KUb
  T
• A?B EKRasIDA KUa T EKRasIDB KUb T
  EKUbEKRaKS T
• A generates the session key, so it is not exposed
  to AS. The role of AS is merely to provide the
  public-key cerificates. The timestamps protect
  against replays of older compromized keys.
• The problem of this protocol is that it requires
  clock-syncronization.

22
Authentication protocols mutual
authenticationpublic-key encryption approaches

• Another protocol using nonces instead of
  timestamps is as follows (note that now the
  session key is generated by the authority, thus
  the use of KDC)
• A ? KDC IDA IDB
• KDC? A EKRauthIDB KUb
• A?B EKUbNa IDA
• B? KDC IDA IDB EKUauthNa
• KDC? B EKRauthIDA KUa EKUbEKRauthIDB
  Ks Na
• B?A EKUaEKRauthIDB Ks Na Nb
• A?B EKs Nb
• This appears as a secure protocol taking into
  account various attacks. Still the developers of
  teh protocol were later able to spot a flawn the
  nonce Na was considered to be unique to verivy
  the timeliness of the message in step 6. However,
  it is not necessarily unique among all nonces
  generated by all parties. Thus the connection
  request of A in step 5. must be identified by a
  pair Na IDA.

23
Authentication protocols mutual
authenticationpublic-key encryption approaches

• To fix the problem vwe have the final protocol
• A ? KDC IDA IDB
• KDC? A EKRauthIDB KUb
• A?B EKUbNa IDA
• B? KDC IDA IDB EKUauthNa
• KDC? B EKRauthIDA KUa EKUbEKRauthIDA
  IDB Ks Na
• B?A EKUaEKRauthIDA IDB Ks Na Nb
• A?B EKs Nb
• The fact that published protocols have often been
  revised by the authors highlights the difficulty
  of getting things right at the first time in the
  area of authentication.
• Authetication protocols in use are no simpler
  than these presented.

24
Authentication protocols one-way
authenticationconventional encryption approaches

• One-way authentication is needed in all
  applications where the sender and receiver are
  not online at the same time. The most important
  application is of course e-mail.
• One possible conventional protocol can be
  achieved by refining the KDC strategy in fig.
  5.9.
• A ? KDC IDA IDB N1
• KDC? A EKaKs IDB N1 EKbKs IDA
• A?B EKbKs IDA EKsM
• This guarantees confidentiality. It also gives a
  level of authentication that the sender is A.
  However, this protocol does not protect against
  replays. In principle timestamps could be added,
  but potential delays in one-way communication
  would require very large time windows, thus
  leaving plenty of time for replay attacks.
• The solutions for a one-way authentication are
  found on the public-key side.

25
Authentication protocols one-way
authenticationpublic-key encryption approaches

• Public key approaches suitable for the encryption
  of e-mail have already been presented
  confidentiality as in fig. 8.1b, authentication
  as in fig. 8.1c or both in fig. 8.1d.
• in these approaches however the recepient knows
  the senders public key and that the sender knowe
  recepients public key
• also these involve encrypting a potentionally
  long message with inefficient public key
  algorithms.
• If confidentiality is the primary concern, then
  the following is more efficient (the message is
  encrypted with conventional one time session key)
• A?B EKUbKs EKsM
• If authentication is the primary concern, then a
  digital signature may suffice, illustrated in
  fig. 8.5c.
• A?B EKRaH(M) M
• This quarantees that A can not deny having sent
  the message. This is however opent to another
  kind of fraud an opponent can change the
  signature for his own, and then claim having sent
  the message (i.e. in case where the sender gets
  some credit)

26
Authentication protocols one-way
authenticationpublic-key encryption approaches

• To counter such a scheme, both the message and
  the signature can be further encrypted with the
  recipients public key
• A?B EKUb EKRaH(M) M
• The two last schemes require that the receiver
  knows the senders public key and is convinced
  that it is timely. A way to provide this
  assurance is the digital certificate (introduced
  earlier in lectures).
• A?B M EKRaH(M) EKRasTIDAKUa
• The certificate is encrypted with the authoritys
  private key (granted by the authority). The
  recipient of the message uses the certificate to
  obtain the senders public key and verify its
  authenticity, and the uses the public key to
  verify the message itself.
• If confidentiaity is required the entire message
  can be encrypted with a one time secret session
  key transmitted as encrypted with receivers
  public key. This approach is widely used in
  e-mail security (PGP, S/MIME) and will be
  explored later in the lectures.