ISA 662 Information System Security

1
ISA 662 Information System Security

• Key Management

2
Overview

• Session and Interchange Keys
• Key Exchange
• Key Generation
• Key Infrastructure
• Storing and Revoking Keys
• Digital Signatures

3
Notation

• Zk message Z enciphered by key k
• ZW concatenation of messages Z and W
• kA,T a (secret) key shared by A and T
• kA As (public or private) key
• r1, r2 nonces (nonrepeating random numbers)
• Example
• X ? Y Z W kX,Y
• A ? T Z kA W r1 kA,T

4
Session Key and Interchange Key

• Always encrypt message with a one-time use key
• Alice wants to send a message m to Bob
• Alice generates a random cryptographic key ks and
  uses it to encipher m
• ks is to be used for this message only
• Called a session key
• She enciphers ks with Bobs public key kB
• kB is used to encipher all session keys (that
  Alice uses to communicate with Bob)
• Called an interchange key
• Could also be a secret key shared by Alice and
  Bob
• Alice sends mks ks kB

5
Why?

• To limit the amount of traffic enciphered with
  the same key
• Standard practice, to decrease the amount of
  ciphertext an attacker can obtain
• Compared to encrypting all messages with
  interchange key
• Prevents some attacks
• Forward search attack
• Question 8 of your midterm exam
• Secret key cryptosystem not vulnerable to forward
  search attack
• Establish a one-time use secret key via
  public-key cryptosystem

6
Overview

• Session and Interchange Keys
• Key Exchange
• Key Generation
• Key Infrastructure
• Storing and Revoking Keys
• Digital Signatures

7
Key Exchange Protocols

• Goal Alice and Bob want to establish a shared
  key
• Key cannot be sent in clear
• Attacker can be listening
• Alice and Bob trust some third party
• Always true (who do you trust in a public-key
  cryptosystem?)
• Protocols publicly known
• Security by obscurity is a bad idea
• Anything transmitted is assumed known to attacker

8
Classical Key Exchange

• Bootstrap problem how do Alice, Bob begin?
• If you trust nobody at all, you can never
  establish trust
• Assume both Alice and Bob trust Cathy
• Alice and Cathy share secret key kA,C
• Bob and Cathy share secret key kB,C
• Use this to exchange shared key ks

9
Simple Protocol
request for session key to Bob kA,C
Alice
Cathy
715
ks kA,C ks kB,C
Alice
Cathy
720
Okay, Alice. This is your session key ks
And tell Bob I got him a session key ks
ks kB,C
Alice
Bob
725
Hey, Bob, Cathy wants me to forward you a session
key ks with which we can talk
message ks
Alice
Bob
730
Hey, Bob, heres the message
10
Replay Attack

• Alice knows she is talking to Bob Why?
• But, Bob is now sure who he is talking to
• Eve records the last message, and later replays
  it to Bob
• Bob re-uses the session key (none keeps history
  of keys)
• Eve then replays messages encrypted with that key

ks kB,C
Eve
735
Bob
He must be Alice again
Hey, Bob, Cathy wants me to forward you a session
key ks with which we can talk
message ks
740
Eve
Bob
He must be Alice again
Hey, Bob, heres the message
11
Replay Attack (Contd)

• Why is replaying (a valid) message a problem?
• Think about this scenario
• By SOD principle, Alice takes deposit and Bob
  credits the corresponding account
• Alice sends Bob a message Eve just deposited
  50k
• Eve replays it
• Protocols must defense against such replay attack
• Adds considerable complexity
• Basic idea is challenge-response
• Eve Hey, bob, this is Alice
• Bob Hmm, then you must have Alices key
• Bob (Bob generates r1 ) Now encrypt this!
• Eve

12
Needham-Schroeder
Alice Bob r1
Alice
Cathy
Hey, Cathy, I need to talk to Bob.
13
Alices Point of View

• Second message
• Encrypted with a key kA,C that only Alice and
  Cathy know, so only Cathy can create the message
• Containing a challenge r1, so the message is not
  a replay
• Third message
• Encrypted with a key kB,C that only Bob and Cathy
  know, so only Bob can read it and extract the
  session key

Alice Bob r1 ks Alice ks
kB,C kA,C
Alice
Cathy
14
Bobs Point of View

• Third message
• Encrypted with a key that only Bob and Cathy
  know, so the message can only be created by Cathy
• The name Alice is in the message, so Cathy says
  the session key is to be used while talking to
  Alice
• Fourth and fifth message
• Determine if it is a replay from someone other
  than Alice

15
Denning-Sacco Modification

• What if after some time, Eve obtains the session
  key ks?
• More likely to be compromised than kA,C or kB,C
• Eve replays the third message

Alice ks kB,C
Eve
Bob
Hey, Bob, this is Alice (replay)
r2 ks
Eve
Bob
Youre Alice? So you must have ks. Prove it!
r2 1 ks
Eve
Bob
Heres the proof that I have ks
16
Denning-Sacco Modification (Contd)

• Solution use time stamp T to detect replay
• Weakness clocks must be synchronized

Alice Bob r1
Alice
Cathy
Alice Bob r1 ks Alice T ks
kB,C kA,C
Alice
Cathy
735
Alice T ks kB,C
Alice
Bob
736
r2 ks
Alice
Bob
r2 1 ks
Alice
Bob
17
Otway-Rees Protocol

• Key-idea always challenges
• n is both a session identifier and a challenge
• n in clear (e.g., in 4th msg) provides no
  security! Typo?

n Alice Bob r1 n Alice Bob
kA,C
Alice
Bob
Alice challenges Bob via r1
n Alice Bob r1 n Alice Bob
kA,C r2 n Alice Bob kB,C
Cathy
Bob
Cathy verifies Bobs response via n
Bob challenges Cathy
n r1 ks kA,C r2 ks kB,C
Cathy
Bob
Bob verifies Cathys response via r2
n r1 ks kA,C
Alice
Bob
Alice verifies Bobs response via r1
18
Kerberos

• Authentication system
• Based on Needham-Schroeder with Denning-Sacco
  modification
• Central server plays role of trusted third party
  (Cathy)
• Ticket
• Issuer vouches for identity of requester of
  service
• Similar to Bob sending r1 ks kA,C to
  Alice on behalf of Cathy
• Authenticator
• Identifies sender

19
Overview

• Authentication - user u authenticates to Kerberos
  server
• Obtains ticket Tu,TGS for ticket granting service
  (TGS)
• Only at time of logon
• Request for service - user u wants to use service
  s
• User sends authenticator Au, ticket Tu,TGS to TGS
  server
• TGS server sends user a ticket Tu,s to use
  service
• User sends Au, Tu,s to service provider
• Service provider grants services

20
Ticket and Authenticator

• Example ticket issued to user u for service s
• Tu,s s u us address valid time
  ku,s ks
• A voucher issued for user u to be authenticated
  by server s, with a session key ku,s
• Example authenticator user u generates for
  service s
• Au,s u generation time ku,s
• An authentication request to be sent by user u to
  server s

21
Protocol
user TGS
user
Cathy
ku,TGS ku Tu,TGS
user
Cathy
service Au,TGS Tu,TGS
user
TGS
user ku,s ku,TGS Tu,s
user
TGS
Au,s Tu,s
user
service
22
Public Key Key Exchange

• Here interchange keys known
• eA, eB Alice and Bobs public keys known to all
• dA, dB Alice and Bobs private keys known only to
  owner
• Simple protocol
• ks is desired session key
• Answer to midterm question 8(d)

ks eB
Alice
Bob
23
Problem and Solution

• Vulnerable to forgery or replay
• Because eB known to anyone, Bob has no assurance
  that Alice sent message
• Simple fix uses Alices private key
• ks is desired session key
• One of yous answer to midterm 8(d) although we
  consider only the forward search attack
• What if the public key is forged?

ks dA eB
Alice
Bob
24
Man-in-the-Middle Attack
send Bobs public key
Eve intercepts request
Alice
Cathy
send Bobs public key
Cathy
Eve
eB
Cathy
Eve
eE
Eve
Alice
ks eE
Eve intercepts message
Bob
Alice
ks eB
Bob
Eve
To solve this, key must be bound to identity
key infrastructure
25
Overview

• Session and Interchange Keys
• Key Exchange
• Key Generation
• Key Infrastructure
• Storing and Revoking Keys
• Digital Signatures

26
Key Generation

• Goal generate keys that are difficult to guess
• Problem statement given a set of K potential
  keys, choose one randomly
• Equivalent to generating a random number between
  0 and K1 inclusive

27
What is Random?

• Sequence of cryptographically random numbers a
  sequence of numbers n1, n2, such that for any
  integer k gt 0, an observer cannot predict nk even
  if all of n1, , nk1 are known
• Best physical source of randomness
• Random pulses
• Electromagnetic phenomena
• Characteristics of computing environment such as
  disk latency
• Ambient background noise

28
What is Pseudorandom?

• Sequence of cryptographically pseudorandom
  numbers sequence of numbers intended to simulate
  a sequence of cryptographically random numbers
  but generated by an algorithm
• Very difficult to do this well
• Linear congruential generators nk (ank1 b)
  mod n broken
• Polynomial congruential generators nk (ajnk1j
  a1nk1 a0) mod n broken too
• Here, broken means next number in sequence can
  be determined

29
Best Pseudorandom Numbers

• Strong mixing function function of 2 or more
  inputs with each bit of output depending on some
  nonlinear function of all input bits
• Examples DES, MD5, SHA-1
• Use on UNIX-based systems
• (date ps gaux) md5
• where ps gaux lists all information about all
  processes on system

30
Overview

• Session and Interchange Keys
• Key Exchange
• Key Generation
• Key Infrastructure
• Storing and Revoking Keys
• Digital Signatures

31
Key Infrastructure

• Goal bind identity to public key
• To thwart the man-in-the-middle attack
• To provide a reliable channel

Plain- text
Plain- text
Encryption Algorithm
Decryption Algorithm
Ciphertext
INSECURE CHANNEL
A
B
B's Public Key
B's Private Key
RELIABLE CHANNEL
B's Public Key
32
Certificates

• A token (message) containing
• Identity of principal (e.g., Alice)
• His/her public key
• Timestamp (when issued)
• Other information (perhaps identity of issuer)
• signed by trusted authority (here, Cathy)
• CA eA Alice T dC

33
The Role of Trust

• Bob gets Alices certificate
• If he knows (and trusts) Cathys public key, he
  can decipher the certificate
• When was certificate issued?
• Is the principal Alice?
• Now Bob has Alices public key
• Problem Bob needs (to trust) Cathys public key
  to validate certificate
• Problem pushed up a level
• Two approaches Merkles tree, signature chains

34
Merkles Tree Scheme

• Keep certificates in a file
• Define hashes recursively
• h is hash function
• Ci is certificate i
• Signature on h(1,4) known to all
• Changing any Ci changes the signature

h(1,4)
h(1,2) h(3,4)
h(1,1) h(2,2) h(3,3) h(4,4)
C1 C2 C3 C4
h(1,4)h(1,2)?h(3,4)
35
Validation

• The signature can be verified with any Ci
• To validate C1
• Compute h(1, 1)
• Obtain h(2, 2)
• Compute h(1, 2)
• Obtain h(3, 4)
• Compute h(1,4), signature
• Compare to known signature
• Only need to know hashes of child nodes on path

h(1,4)
h(1,2) h(3,4)
h(1,1) h(2,2) h(3,3) h(4,4)
C1 C2 C3 C4
36
Problem

• Changing any certificate changes the signature
• Not practical in most circumstances
• Too many certificates and users
• Users and certificates distributed over widely
  separated systems

37
X.509 Certificate Chains

• Some certificate components in X.509v3
• Version
• Serial number
• Signature algorithm identifier hash algorithm
• Issuers name uniquely identifies issuer
• Interval of validity
• Subjects name uniquely identifies subject
• Subjects public key
• Signature enciphered hash

38
X.509 Certificate Validation

• Obtain issuers public key
• Decipher signature
• Gives hash of certificate
• Recompute hash from certificate and compare
• If they differ, theres a problem
• Check interval of validity
• This confirms that certificate is current

39
Issuers

• Certification Authority (CA) entity that issues
  certificates
• Multiple issuers pose validation problem
• Alices CA is Cathy Bobs CA is Dan how can
  Alice validate Bobs certificate?
• Have Cathy and Dan cross-certify
• Each issues certificate for the other
• Why does Alice trust Cathy?
• Root CA built-in (e.g., IE)

40
Validation and Cross-Certifying

• Certificates
• CathyltltAlicegtgt
• CathyltltDangtgt
• DanltltBobgt
• (DanltltCathygtgt)
• Alice validates Bobs certificate
• Alice obtains CathyltltDangtgt
• Alice uses (known) public key of Cathy to
  validate CathyltltDangtgt
• Alice uses CathyltltDangtgt to validate DanltltBobgtgt

41
PGP Chains

• OpenPGP certificates structured into packets
• One public key packet
• Zero or more signature packets
• Public key packet
• Version (3 or 4 3 compatible with all versions
  of PGP, 4 not compatible with older versions of
  PGP)
• Creation time
• Validity period (not present in version 3)
• Public key algorithm, associated parameters
• Public key

42
Signing

• Single certificate may have multiple signatures
• Notion of trust embedded in each signature
• Range from untrusted to ultimate trust
• Signer defines meaning of trust level (no
  standards!)
• All version 4 keys signed by subject
• Called self-signing

43
Validating Certificates

• Alice needs to validate Bobs OpenPGP cert
• Does not know Fred, Giselle, or Ellen
• Alice gets Giselles cert
• Knows Henry slightly, but his signature is at
  casual level of trust
• Alice gets Ellens cert
• Knows Jack, so uses his cert to validate Ellens,
  then hers to validate Bobs

Arrows show signatures Self signatures not shown
Jack
Henry
Ellen
Irene
Giselle
Fred
Bob
Are you sure this will work in real world?
44
Overview

• Session and Interchange Keys
• Key Exchange
• Key Generation
• Key Infrastructure
• Storing and Revoking Keys
• Digital Signatures

45
Storing Keys

• Depending on OS security?
• In multi-user or networked systems attackers may
  defeat OS access control mechanisms
• Encrypt files containing keys
• Malware can monitor keystrokes to capture keys
• Use physical devices like smart card
• Smart card does encryption/decryption
• Keys never enter system
• Card can be stolen combined with password

46
Key Escrow

• Encryption Dilemma
• Publics need for secure communication
• Governments need for lawful access to
  information
• Key escrow system allows authorized third party
  to recover key (from ciphertext)
• Business recovery of backup keys
• Law enforcement recovery of keys that authorized
  parties require access to
• Goal provide key escrow without weakening
  cryptosystem
• Very controversial

47
Clipper Chip

• In 1993, Clinton administration proposed the
  clipper chip key escrow initiative
• Objectives
• Make strong encryption technology widely
  available
• Built-in decryption capability for law
  enforcement agencies
• Clipper chip has the essential key escrow
  property It ensures that the key needed to
  decrypt the data is bound to the ciphertext
• Key-recovery requires cooperation of one or more
  trusted party

48
Clipper Chip (Contd)

• Encryption requires clipper chip
• Clipper chip is temper proof and uses a
  secret-key encryption algorithm, called Skipjack
• Skipjack was designed by NSA and is classified
  until 1998
• It uses 80 bit keys (24 bits longer than DES)

49
Key Escrow in Clipper Chip

• Each clipper chip has a unique K and a unique
  32-bit ID
• For each key K, two numbers K1 and K2 are
  determined as follows
• K1 is an 80 bit random number
• K2 K ? ?K1
• K1 and K2 (with the unique chip ID) are given to
  independent federal agencies
• In the initial proposal, National Institute of
  Standards and Technology (NIST) and Dept of
  Treasury were to be the escrow agents

50
Key Recovery in Clipper Chip

• Bob talks to Alice via clipper chip-equipped
  devices
• The devices generate a session key and send to
  clipper chip, which uses the key to
  encrypt/decrypt
• Before encrypting, the chip transmits a string of
  bits called the law enforcement access field
  (LEAF)
• LEAF is computed as follows
• Session key is first encrypted using the
  chip-unique K
• Result together with the chip ID are then
  encrypted using a family key F common to all
  chips
• Note that access to F allows recovery of the chip
  ID, but not the session key since it is encrypted
  using the chip-unique key

51
Key Revocation

• Certificates invalidated before expiration
• Usually due to compromised key
• May be due to change in circumstance (e.g.,
  someone leaving company)
• Problems
• Need to ensure the entity revoking certificate is
  authorized to do so
• Revocation information circulates to everyone
  fast enough
• Network delays, infrastructure problems may delay
  information

52
CRLs

• Certificate revocation list lists certificates
  that are revoked
• X.509 only certificate issuer can revoke
  certificate
• Added to CRL
• PGP signers can revoke signatures owners can
  revoke certificates, or allow others to do so

53
Overview

• Session and Interchange Keys
• Key Exchange
• Key Generation
• Key Infrastructure
• Storing and Revoking Keys
• Digital Signatures

54
Digital Signature

• Construct that authenticated origin, contents of
  message in a manner provable to a disinterested
  third party (judge)
• Sender cannot deny having sent message (service
  is nonrepudiation)
• Limited to technical proofs
• Legal proofs, etc., probably required not dealt
  with here

55
Common Error

• Classical Alice, Bob share key k
• Alice sends m m kA,B to Bob
• This is not a digital signature, because a third
  party cannot determine whether Alice or Bob
  generated message

56
Public Key Digital Signatures

• Alices keys are dAlice, eAlice
• Alice sends Bob
• m m dAlice
• In case of dispute, judge computes
• m dAlice eAlice
• and if it is m, Alice signed message
• Shes the only one who knows dAlice!

57
RSA Digital Signatures

• Need to be careful
• Never sign documents directly, but sign its hash
• Mathematical properties can be turned against
  signer
• Sign then encrypt instead of the other way around
• Changing public keys causes forgery

58
Attack 1

• Example Alice, Bob communicating
• Alice nA 95, eA 59, dA 11
• Bob nB 77, eB 53, dB 17
• 26 contracts, numbered 00 to 25
• Alice has Bob sign 05 (overtime) and 17 (more
  overtime)
• c mdB mod nB 0517 mod 77 3
• c mdB mod nB 1717 mod 77 19
• Alice computes 05?17 mod 77 08 (raising salary)
  corresponding signature is 03?19 mod 77 57
  claims Bob signed 08 (raising salary)
• Judge computes ceB mod nB 5753 mod 77 08
• Signature validated Bob is toast

59
Attack 2 Bobs Revenge

• Bob, Alice agree to sign contract 06 (OT
  raising salary)
• Alice enciphers, then signs
• (meB mod 77)dA mod nA (0653 mod 77)11 mod 95
  63
• Bob now changes his public key
• Computes r such that 13r mod 77 6 say, r 59
• Computes r?eB mod ?(nB) 59?53 mod 60 7
• Replace public key eB with 7, private key dB 43
• Bob claims contract was 13 (OT half salary).
  Judge computes
• (6359 mod 95)43 mod 77 13
• Verified now Alice is toast

60
El Gamal Digital Signature

• Relies on discrete log problem
• Choose p prime, g, d lt p compute y gd mod p
• Public key (y, g, p) private key d
• To sign contract m
• Choose k relatively prime to p1, and not yet
  used
• Compute a gk mod p
• Find b such that m (da kb) mod p1
• Signature is (a, b)
• To validate, check that
• yaab mod p gm mod p

61
Example

• Alice chooses p 29, g 3, d 6
• y 36 mod 29 4
• Alice wants to send Bob signed contract 23
• Chooses k 5 (relatively prime to 28)
• This gives a gk mod p 35 mod 29 11
• Then solving 23 (6?11 5b) mod 28 gives b 25
• Alice sends message 23 and signature (11, 25)
• Bob verifies signature gm mod p 323 mod 29 8
  and yaab mod p 4111125 mod 29 8
• They match, so Alice signed

62
Key Points

• Key management critical to effective use of
  cryptosystems
• Keys need infrastructure to bind holders, allow
  revoking
• Key escrowing complicates infrastructure
• Digital signatures provide integrity of origin
  and content