Transcript Major Differences - Designing Systems for Internet Commerce

Proposal for WAP-IETF cooperation on a wireless friendly
TLS
Tim Wright,
Vodafone and chair WAP Security
Group
[email protected]
Contents
• Introduction to WAP, WTLS and other WAP
security functions
• Differences between WTLS and TLS
• WAP-NG
• WSG part in WAP-NG
• A wireless friendly TLS?
WAP
• Formed by Ericsson, Motorola, Nokia,
phone.com
• Opened up (“Opened up?”) in Spring 1998
• Wireless friendly versions of html, http,
TCP/IP for delivery of “Internet content and
services” to wireless clients
Stack
WSP (carrying WML and WMLScript)
WTP
WTLS
WDP
Bearer
WTLS
• Wireless friendly version of TLS
• Several differences designed to:
– optimise bandwidth use
– accommodate unreliable link
– reduce client code size and processor
requirements
Other WAP security features
• WAP Identity Module (WIM)
– specification of interface to tamper-resistant
device for storage of crypto parameters
• signText
– WMLScript function for signature generation
• Profile of X.509 for client certs
– based on RFC 2459
• WPKI
– client and server cert request, root download
Major differences between
WTLS and TLS
•
•
•
•
•
•
Datagram support
No fragmentation
Key refresh for long-lived connections
Optimized handshaking
Shared-secret handshake
Compact certificate (WTLSCertificate)
• Shorter parameters
• Cipher suite negotiation
• Algorithms
Datagram Support
• Mandatory use of explicit sequence
numbers
• Concatenation of successive handshake
messages in one direction into one transport
SDU
• Extra conditions for handshake to deal with
lost messages
No fragmentation
• Assumed not needed as optimisations will
mean application data is less than 16K
• Reduces WTLS code size
Key Refresh for long lived
connections
• ClientHello and ServerHello include setting
of key refresh rate
• Recalculation of key_block every n records,
n=2k, k is uint 8
• Allows key refresh without handshake
Optimised handshaking
• Server can retrieve client cert from own
sources after Client Hello, if client sends
public key id (hash) or cert URL, and do
abbreviated handshake
• Client indicates the roots it has in
ClientHello (trusted_key_ids), so that server
can send appropriate certs
Shared Secret Handshake
• Pre-master secret is a shared secret
previously loaded into client and server
Handshake is as for (W)TLS abbreviated
handshake (Hello’s, ChangeCipherSpec’s
and Finished’s only)
• Allows implicit authentication and
confidentiality/integrity, with risk of
extraction of secret from terminal
Compact certificate
• “WTLSCert” defined in specification
• Designed for authentication of WAP
gateway only
• No extensions
• length - 450 bytes compared to around 750
for X.509
Format
struct {
uint8 certificate_version;
SignatureAlgorithm signature_algorithm;
Identifier issuer;
uint32 valid_not_before;
uint32 valid_not_after;
Identifier subject;
PublicKeyType public_key_type;
ParameterSpecifier parameter_specifier;
PublicKey public_key;
} ToBeSignedCertificate;
Shorter parameters
• Truncated (40 and 80 bit versions) of SHA1 and MD5 allowed
• Pre-master secret is only 20 bytes, not 48
• Client and Server Random’s only 16 bytes,
not 32
• Session ID is 8 bytes, not 32
Cipher suite negotiation
• Key exchange/authentication algorithm
negotiated separately from cipher and MAC
• Allows negotiation of strong authentication
with weak encryption where legislation
requires
• Allow theoretical possibility of NULL key
exchange with strong ciphering and MAC
Algorithms - anonymous
handshake
• RSA_ANON, with 512 and 768 bit limited
versions
• DH_ANON, with 512 and 768 bit limited
versions
• ECDH_ANON, with 113 and 131 bit
limited versions
Algorithms - server/client
authentication
• RSA, with 512 and 768 bit limited versions
• No temporary keys
• ECDH_ECDSA
– 4 basic curves, 4 non-basic
Algorithms - MAC
• SHA-1, MD5 and 40/80 bit truncations
allowed
• Only one used
• “XOR MAC” - divide the message into 5
bit blocks and XOR together
– designed for low end devices
– warnings in specification against use
– attack publicised (Saarinen, Wagner)
Algorithms - encryption
• RC5-32/16/16 is recommended for client
and server
– 56 and 40 bit versions, use shorter key, pad to
128 bit and use RC5-32/16/16
• Others
– DES, 3DES, IDEA
– None of these in production handsets
Attacks
• XOR MAC
• Possibility of negotiating NULL key
exchange gives middleperson attack
• Possibility of low entropy IV allows
intruder possibility of guessing key if can
control channel
• Redirection attacks as for TLS
WAP Next Generation (NG)
• WAP NG is the great leap back to Internet
compliant specs
• http, html, TLS, TCP/IP to the handset
• But wireless friendly versions of these
protocols
– initially with PEP’s
• WSG task is TLS to the handset
WSG plans re TLS
• Wireless profile of TLS 1.0, including:
– Profile of client and server X.509
– Specified ciphersuites
– Guidelines on TLS options
• Specification of use of WIM for TLS
• Development within WSG and IETF of
wireless-friendly TLS 1.1?
Changes required?
• Possibilities (early thoughts, and TBD):
–
–
–
–
Algorithms - ECC & RC5?
Client certificate URL
Client to indicate trusted roots in Hello
NOT necessarily datagram support and WTLS
certs
Timescales
• WAP NG specs to be ready summer 2001
(though WG’s have some flexibility)
• TLS standardisation timescales?
– waiting on RFC 2459 progress
– time for some minor changes for wireless to
TLS 1.0?
Next Steps
• WSG to determine changes necessary/”nice
to have” for wireless friendly TLS
• TLS to determine what can be squeezed into
TLS 1.0 and what needs new version
• Make changes to TLS 1.0
• Begin work on TLS 1.1 as required