Solutions for Secure and

Trustworthy Authentication

Ramesh Kesanupalli

Ramesh_Kesanupalli@phoenix.com

Agenda

Overview

Industry Challenges

SPEKE

Industry implementation

Other lines of research

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

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

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”

Password Security IssuesVulnerabilities

• Unprotected PasswordOpen to dictionary, replay or off-line attack

• Stored passwordCrackable

• Man in the MiddleA 3rd 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

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

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

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

3

Server

Enter passwordPassword

App. serverEncrypt sessionApp. client

Run ZKPP Scheme

Client

Shared key

. . .

Shared key

Enterprise SPEKE-enabled Session

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

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)

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

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

Phoenix Security Framework

Core System Software

Power-on

Application

OS Kernel

Application Application ‘Ring 3’Applicationprivilege

‘Ring 0’OSprivilege

System Management Mode(Highest privilege on the CPU)

SecurityDriver

‘SMM’CSSprivilege

Caller Validation

Device Key in Secure Silicon

Thanks!