Presentation on theme: "Intro To Secure Comm. Exercise 3. Problem The following scenario is suggested for establishing session keys Alice and Bob share a secret (key phrase/password)"— Presentation transcript:
Intro To Secure Comm. Exercise 3
Problem The following scenario is suggested for establishing session keys Alice and Bob share a secret (key phrase/password) Alice generates Session key K and send E P (K) to Bob Bob receives E P (K), deciphers and uses K as the new session key. What are the threats to the model? Is this solution secure against an eavesdropper?
Solution The solution is problematic when a password is used. Passwords are susceptible to dictionary attack. The eavesdropper may discover p and thus the session key k (and may discover any other session keys) Suggest a better protocol
Solution Alice Generates pub A and priv A. Alice sends E P (pub A ) to Bob Bob deciphers and sends to Alice Pub A (k) Alice sends to Bob E k (challengeA) Bob responds E k (challengeA||challengeB) Alice responds (challengeB) What cryptographic method is E?
Solution The cryptographic method is a MAC Why not simply use an encryption method?
Problem Some designs attempt to provide message authentication by sending the encryption of the message concatenated with its hash (or simply with an error detection code). Namely, they send Encrypt(Message||Hash(Message)), and hope that in so doing, they achieve encryption and authentication together. Show that this design is insecure (an attacker can modify a message and it would still be considered authentic). Hint: this is easy to show, when using one-time-pad or OFB mode encryption.
Solution Assuming OTP is used and ADV knows some information about the message. ADV knows the algorithm, so knows which hash function is used. Knowing so, he can figure out the key encrypting the message (known plain text). Since he knows the message and hash of the message, he can figure out the key encrypting the hash. ADV can now calculate new message and new hash for the message and replace them.
Solution ADV’s playout: k m =m c m (revealing the key of m) k h(m) =h(m) c h(m) Forge: m’ k m ||h(m’) k h(m) This is a poor MAC because it isn’t even immune to KMA.
Problem Often CAs are single entities which provide user registraion/identification certificate creation What may be the problems associated with that model?
Solution CA may be single point of failure CA may not be able to supply the demand CA may be easier to corrupt/perform DOS
Registration Authority CA combines two functions: Validate identity of source of public key Sign public key with attributes (identity, others) CA secret key required only to sign cert Identify by separate registration authority Exercise: motivate by analyzing threat!
RA – Registration Authority Also called LRA – Local RA Goal: Off-load some work of CA to LRAs Support all or some of: Identification User key generation/distribution passwords/shared secrets and/or public/private keys Interface to CA Key/certificate management Revocation initiation Key recovery
CA – Certification Authority Issuer/Signer of the certificate Binds public key w/ identity+attributes Enterprise CA Individual as CA (PGP) Web of trust “Global” or “Universal” CAs VeriSign, Equifax, Entrust, CyberTrust, Identrus, … Trust is the key word
Problem Define the threats to the above model What type of threats/ADV can harm the solution?
Solution External Attackers Operators Viruses controlling CA pc’s
Alice (subject) Alice proves her identity And provides P A Alice, P A Sign(Priv CA,(Alice,P A )) Secure Hardware Operator Enter PIN or smartcard
Problem What may be the problem of the secured hardware box?
Solution Lack of UI at the hardware Trojan may send bogus certificates than what the operator approved Hardware only certifies one certificate per smartcard (good thing) but wrong certificate may still be used.
A better solution Integrate UI with secure hardware Secure log to go over issues/suspected certificates What if found a “corrupted” certificate? May revoke it by publishing CRL