SPEKE Simple Passwordauthenticated Exponential Key Exchange

1
SPEKE Simple Password-authenticated Exponential
Key Exchange

Robert Mol Phoenix Technologies
2
Agenda

• Overview
• Industry Challenges
• SPEKE
• Industry implementation
• SPEKE Roadmap
• SPEKE and SACRED
• SPEKE Licensing

3
Overview

• Device Security
• Enterprises and Service Providers cannot achieve
  sufficient levels of end point security
• Network Security
• Password based protocols and Absence of device
  identity magnifies network vulnerability
• Content Security
• Enterprise Data security
• Digital content protection and rights management

4
Industry Challenges

• Most protocols are still password based
• Existing solutions like Tokens, smart cards etc
  are not cost effective and not very convenient
• Phishing and Pharming are now real threats
• A Critical need for mutual authentication
• Identity Theft
• Through user credential harvesting
• 2 Factor Authentication is becoming a necessity
• Most Enterprises still concerned about wireless
  data security

5
What is SPEKE?

• SPEKE Simple Password-authenticated Exponential
  Key Exchange
• A Peer to Peer Zero Knowledge Password Proof
  (ZKPP) protocol
• A simple password at both ends results in mutual
  authentication and a shared session key
• Standardized in IEEE 1363 Password-Based
  Public-Key Cryptography

6
Benefits of SPEKE

• Mutual Authentication without password exchange
• Resists to man in the middle type attacks
• Prevents dictionary other network attacks
• Not vulnerable to replay
• Resists Phishing via server authentication
• No Password stored on the client
• Very Light Weight component on Client and Server
• Ability to have additional intelligence on the
  client
• Cross functional across devices, PCs, Mobile
  Phones, PDAs etc
• No need for additional hardware of Tokens,
  Certificates etc
• Extremely cost effective for financial
  Institution and Consumer applications

7
How SPEKE Protocol Works
Enter password
1
SPEKE server
Algorithm will swap public keys of chosen length

• SPEKE Client

2
Each derives shared password-authenticated key
3
Any Java, J2ME, Emb C client
Output shared key
Output shared key
8
SPEKE-enabled Session
Enter password
Password
SPEKE protocol

• Client

Server
User Provisioning, Service Provisioning,
Enterprise Data etc..
Shared key
Shared key
App server
Encrypted session
App client
Any Java, J2ME, Emb C client
9
SPEKE Industry Implementation

• Entrust
• Entrust True Pass - remotely retrieves users
  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)

10
SPEKE Roadmap

• Current SPEKE SDK
• ANSI C based simple API
• GSS (Generic Security Services) Compliant
• Supports Windows and Unix
• Web Authentication Module
• Plug-ins for Microsoft IE and IIS
• Demo for PC clients ready (06/30/05)
• Java API
• Maximum portability
• New API available for evaluation (07/15/05)
• J2ME Support and API 09/30/2005
• For Mobile Devices

11
SPEKE and SACRED

• SPEKE defined as a one of the authentication
  methods for Securely Available Credentials
  (SACRED) RFC3760, April 2004 among other strong
  password protocols (Section 4.2.1)
• SPEKE provides strong mutual authentication of
  SACRED client and SACRED server
• Shared (derived) strong symmetric key provides
  secure communication for credential download
  process

12
Licensing Terms

• Available on the IETF website
• https//datatracker.ietf.org/public/ipr_detail_sho
  w.cgi?ipr_id587
• To the extent employees of Phoenix Technologies
  Ltd. make a contribution which is incorporated in
  an adopted IETF Standard
• Phoenix will, upon written request, offer
  non-exclusive licenses on fair, reasonable and
  non-discriminatory terms to prospective licensees
  (such terms may include a reciprocal grant back
  form the prospective licensees) under such patent
  claims for the implementation of such IETF
  Standard.

13
For more details please emailkeith_hartley_at_pho
enix.com Thank you