Codes & Ciphers Ltd 12 Duncan Road Richmond, Surrey TW9 2JD Information Security Group Royal Holloway, University of London Egham, Surrey TW20 0EX Impersonation Attacks Fred Piper

Crete Outline Information security User recognition –Use of passwords/PINs/cryptogrphic keys –Use of ‘tokens’ Phishing Protection against man-in-the-middle attacks Multi factor or multi channel? The use of mobile phones as a ‘token’ for user recognition?

Crete What is Information Security? Some features include: Confidentiality – Protecting information from unauthorised disclosure Integrity – Protecting information from unauthorised modification, and ensuring that information can be relied upon and is accurate and complete Availability – Ensuring information is available to authorised users when they need it

Crete Defences and Attacks Defences: Introduce security mechanism to protect data –Technical –Procedural –Contractual Introduce strong authentication mechanism Attacks: Break the technical security mechanism Impersonate an authorised entity by breaking procedural mechanism

Crete User Recognition (1) 3 factors: 1) Something you know (Password/PIN/Cryptographic Key) 2) Something you own (Token) 3) Personal characteristic (Biometrics) NOTE: Usually one-way authentication Tokens and biometrics often require ‘readers’ ‘Danger’ of false ‘readers’ Cost issues

Crete User Recognition (2) Many systems rely on more than 1 factor For multi-factor systems compromise of 1 factor should not enable impersonation The PIN/magnetic stripe card for ATM networks is an example of a 2-factor system where each individual factor is ‘weak’

Crete Something You Know Password PIN Cryptographic key Obvious observations: –A PIN is a password with limited alphabet –A cryptographic key may be regarded as a (secret) password which the user may use but probably not know –Policies for the management of PINs and Passwords are inconsistent

Crete Password Policy It is often recommended that: Users should adopt a large alphabet (at least alpha- numeric with upper and lower case letters) Passwords should be long (at least 8 characters?) Passwords should be randomly generated Passwords should be different for each system Passwords should be changed frequently Passwords should not be written down

Crete PINs Personal identification number Usually 4 digits (sometimes 6) –Reason: users will not be able to remember longer PINs! NOTE: This is inconsistent with general password policy. Undoubtedly a weak password

Crete Cryptographic Keys It is the use of a cryptographic key, rather than revealing its value, that identifies a user

Crete Cipher System Cryptogram c Encryption Key Encryption Algorithm Message m Decryption Algorithm Decryption Key Message m Interceptor Key establishment channel (secure)

Crete Two Types of Cipher System Conventional or Symmetric –Decryption Key easily obtained from Encryption Key Public or Asymmetric –Computationally infeasible to determine Decryption Key from Encryption Key

Crete Keys as Identifiers Asymmetric System –Use of the private key acts as an identifier to ‘everyone’ Symmetric System –Use of a key identifies users only to those (trusted) people who share that key NOTE: If an asymmetric system is used, an impersonator may either 1. obtain the use of the user’s private key 2. substitute their public key for that of the user

Crete Authentication Using Smart Tokens Static Password Tokens –Owner authenticates himself to token –Token identified owner to system Dynamic Password Tokens –Token generates new password –(Owner activates token with PIN) –Owner enters ID plus dynamic password –System knows which dynamic password to accept Challenge-Response Tokens –System generates challenges –Owner activates token with PIN and enters challenge –Token generates response (probably challenge encrypted with key that is unique to token) –System knows which response to accept

Crete Dynamic Passwords User’s password changes frequently (possibly at each log-in) Change influenced by at least one of: Secret information known to user Intelligent device which is unique to user

Crete Challenge/Response for Dynamic Password Given an unpredictable challenge, user’s token produces a response which is: Appropriate to the challenge Dependent on a user’s token Dependent on user’s knowledge

Crete The Challenge / Response Principle for hand-held token Key Random number ChallengePIN-Controlled A A Response A - encrypt or OWF Y/N = ? HOST USER

Crete Impersonation Attacks 1-way authentication –Steal and/or copy token –Guess or ‘observe’ password/PIN/cryptographic key –Con the user into divulging password/PIN eg phishing –Gain access to device using key 2-way authentication –Man-in-the-middle

Crete Phishing Attacks (1) Social engineering Attacker discovers secret ‘information known’ Banking customers have been ‘prime’ targets via messages and fake websites

Crete Phishing Attacks (2) Countermeasures User education/awareness Use of 2 or 3 factor systems so that compromise of 1 factor has limited impact

Crete Identification over the Internet Many applications use 2-factor systems that allow ‘card not present’ transactions Effectively a physical token is replaced by a virtual token which is nothing more than a card number This is a 1-factor system In Singapore the FA mandates use of genuine 2-factor authentication In UK banks are starting to issue customers with Chip and PIN ‘readers’

Crete Phishing Browsers starting to try to detect fake websites –Google Safe Browsing for Firefox browser –Microsoft’s Internet Explorer 7 Anti-Phishing War Group (APWG) –Forum to discuss phishing issues and share best practices –

Crete Phishing Attacks Summary Enable attacks to discover secret ‘information known’ ‘Best’ countermeasure is user education/awareness Effectiveness of attack decreases for 2 or 3 factor systems Use of conventional 2 or 3 factors often expensive and needs special hardware Introduction of ‘one-time’ PINs such as ITANs for some German e-banking systems helps

Crete D-H Man-in-the-Middle Attack B Fraudster F The Fraudster has agreed keys with both A and B A and B believe they have agreed a common key A F’s public key B’s public key A’s public key

Crete Protection Against Man-in-the-Middle Attack Rely on TTP to establish key management infrastructure (eg PKI) Use second (independent) communications channel to confirm key between A and B (Over) Simple Example: –D-H protocol establishes 1024 shared bits –AES key is 128 bits from agreed positions –Users exchange different 32-bit sequences from the 1024 bits over second (possibly insecure) channel

Crete OOB (Out of Band) Authentication Requirement A user claims an identity over a computer network Host wants to use a second channel to confirm it is the genuine user Neither party is willing to pay for ‘extra hardware’

Crete Use of Two Channels Prior to PK crypto, most cryptographic systems needed a second (secure) channel for initial key establishment One motivation for introduction of PK crypto

Crete OOB Communications Symmetric cryptography –Use secure second channel to enable secure communications over an insecure primary channel Authentication –Use second (possibly insecure) channel to confirm that the communications over the primary channel are secure NOTE: In this context an insecure channel is one where interception is possible.

Crete Communications How does ‘token’ communicate with host: One channel or two channel system? One-way or two-way authentication? What is the interface? –The user? –A reader that is part of the network? –Other?

Crete Mobile Phones There is a move towards systems where the mobile phone is ‘something you own’ No reader required No extra cost (in the sense that most people have them) Use their own channel Security implications?

Crete Question Are there situations where using the mobile phone as a token in a 2-factor system and using a second communication channel can decrease the chance of successful impersonation attacks?