1. Solutions for Secure and Trustworthy Authentication Ramesh Kesanupalli Ramesh_Kesanupalli@phoenix.com

2. Agenda  Overview  Industry Challenges  SPEKE  Industry implementation  Other lines of research

3. Overview  Device Security Enterprises and Service Providers cannot achieve sufficient levels of end point security  Network Security Absence of device identity magnifies network vulnerability  Content Security Constantly increasing number of identity theft is done through “phishing” and “pharming” attacks

4. Industry Challenges  People use passwords in all security protocols  Most password-based protocols have been susceptible to hacks  Protocols like 802.1x EAP, IPSEC v2, Radius are looking at stronger authentication mechanisms  Industry requires a more secure and cost effective password mechanism  Most Enterprises still concerned about wireless data security  Wireless Access for Enterprise Applications is still unsolved task  Phishing Attacks are major concern  Identity Theft

5. What is SPEKE?  SPEKE: Simple Password-authenticated Exponential Key Exchange  A Zero Knowledge Password Proof (ZKPP) protocol  A simple password at both ends results in mutual authentication and a shared session key No prior secrets or root certificates  Standardized in IEEE 1363: “Password-Based Public-Key Cryptography”

6. Password Security Issues  Vulnerabilities Unprotected Password Open to dictionary, replay or off-line attack Stored password Crackable Man in the Middle A 3 rd party impersonates the client or server  Countermeasures Forcing frequent changes Requiring mixed characters (uPP3r!) Using “accessories” (such as tokens or SmartCards) Using tunneled methods such as SSL or IPSec with Digital Certificates Counter measures often defeat the goal of convenience or add great expense

7. SPEKE uses ZKPP  Prove that you know a secret key without revealing what it is Password is not sent over the connection Secret is validated with large, pseudo-random binary number  Protects against known vulnerabilities Can’t be sniffed Not vulnerable to replay Resists to “man in the middle” type attacks  Safer than CHAP, SSL, IPSec/IKE and other methods (even Kerberos) in password-only configuration

8. Benefits of SPEKE  Solves an existing problem Better authentication and session keys Compliant with emerging WPA, 802.1x EAP standard Prevents dictionary & other network attacks Better server authentication – protects against Phishing attacks  Simplicity for end users A simple password is made strong Don’t need inconvenient countermeasures Strength without infrastructure (no PKI required)  Technical features Advanced cryptography No stored password on client Mutual authentication Integrated key exchange

9. How SPEKE Protocol Works SPEKE server Output shared key 1 Algorithm will swap public keys of chosen length SPEKE Client Each derives shared password-authenticated key Output shared key Enter password 2 3

10. 3 Server Enter password Password App. server Encrypt session App. client Run ZKPP Scheme Client Shared key... Shared key Enterprise SPEKE-enabled Session

11. Protection against Phishing Attacks  A rogue web site that does not know the correct password will be immediately detected  If the web site tries to guess an incorrect password and fails, no information is leaked – the rogue web site cannot use this information

12. SPEKE Industry Implementation  Entrust Entrust True Pass - remotely retrieves user’s private key for web-browser PKI-enabled applications, roaming user application  Funk Software 802.1x EAP-SPEKE – strong password based authentication for RADIUS systems  Interlink Networks 802.1x EAP-SPEKE – strong password based authentication for RADIUS systems  Research In Motion Enterprise Server - provision keys for a generic BlackBerry device (device enrollment)

13. SPEKE Applications  Provisioning credentials Private key retrieval, “roaming” protocols Secure enrollment Protection against Phishing attacks  Connection authentication 802.1x & IPSEC v2 EAP wireless session establishment 802.1x EAP wired authentication

14. Secure Protocol is not Enough  Other lines of research from Phoenix Technologies Stronger root of trust at the core – Firmware-level cryptographic engine Protected execution environments (x86 processors) – System Management Mode Caller validation – inability for rogue programs to call the API Secure and trusted pre-OS execution environment Strong pre-boot authentication using biometrics and smart cards/tokens

15. Phoenix Security Framework Core System Software Power-on Application OS Kernel Application ‘Ring 3’ Application privilege ‘Ring 0’ OS privilege System Management Mode (Highest privilege on the CPU) Security Driver ‘SMM’ CSS privilege Caller Validation Device Key in Secure Silicon

16. Thanks!