WIRELESS SECURITY

Author: CellExchange, Boston Creation Date: October 1, 2000 Last Updated: October 4, 2000 Control Number: CX00201 Version: 1.1

Copy Number _____

1. Document Control

1.1 Change Record

Date Author Version Change Reference

1-Oct-00 CellExchange Inc. 1 No previous document 4-Oct-00 CellExchange Inc. 1.1

1.2 Reviewers

Name Position

Walid Negm Vice President of Product Management Jenko Hwong Director of Technology Issam Zeinoun Development Manager

ii Security.doc Confidential 10/04/00

Contents

1. Document Control...... ii 1.1 Change Record...... ii

1.2 Reviewers ...... ii

2. Introduction to Wireless Security ...... 1 2.1 Overview...... 1

2.2 Security Issues ...... 1

2.3 WAP Security Model...... 1

3. WTLS...... 3 3.1 WTLS features...... 3

3.2 WTLS issues...... 4

3.3 Attacking WTLS...... 4

4. Summary...... 6

5. Appendix...... 7 5.1 WTLS security mechanism:...... 7

5.2 WTLS Handshake Protocol ...... 7

5.3 Record layer...... 8

5.4 Alert protocol...... 8

6. References...... 10

iii Wireless Security.doc Confidential 10/04/00

2. Introduction to Wireless Security

2.1 Overview A wireless internet application is subject to following constraints: Low Bandwidth, High Latency, Session Dropouts, CPU, Memory, Battery Life, Limited User Interface etc.

WAP has been designed to function within the constraints in which mobile wireless devices must operate. WAP is intended to operate over any of the different wireless transmission technologies, such as Cellular Digital Packet Data (CDPD), Code Division Multiple Access (CDMA) and Global System for Mobile (GSM).

A Security Layer is needed because: • Available security in bearer networks applies only to the OTA (Over The Air) channel. • Roaming Feature: More possibilities to intercept and alter data transfer.

Standards such as GSM and CDPD provide but they are not supposed to be robust e.g. A5/1 and A5/2 for GSM. Most of the current secure transactions over wireless networks such as stock trading are implemented using the cellular CDPD or GSM networks to encrypt traffic.

2.2 Security Issues There are four issues that a security solution must address: Privacy: Only the sender and recipient can read the contents of a message. Integrity: Content should not be altered between the time it is sent and received. : All parties in a communication are who they claim to be. Non-repudiation: A party to a transaction cannot falsely claim that they didn’t participate in a particular transaction.

At a higher level, security can be broadly categorized into two categories: : Ensures privacy, integrity non-repudiation and possibly authentication (by means of Digital certificates). Application Level Security: Can address authentication using User ID / Password combination. Application level logs to monitor client activity.

In wired Internet, these concerns are addressed by SSL. In the wireless world, WTLS (Wireless ) is the security layer in the WAP stack (the equivalent of SSL in the wired world). WTLS is an optional layer that sits just above the WDP layer and transparently encrypts/decrypts messages.

2.3 WAP Security Model A WAP gateway is a virtual gatekeeper between the worlds of WTLS and SSL. The WAP security model relies upon WTLS (Wireless Transport Layer Security) and SSL (Secured Sockets Layer)

1 Wireless Security.doc Confidential 10/04/00

Flow of information:

Wireless DeviceàWireless NetworkàWAP GatewayàInternet NetworkàContent Server

2 Wireless Security.doc Confidential 10/04/00

3. WTLS

A wireless phone communicates with the WAP Gateway over a wireless network using WTLS. A WAP client must connect to a different port for secure connections. A Gateway provider should allow only secure connections. The WAP Gateway then communicates with the Web server via the Internet using SSL.

3.1 WTLS features • Privacy, Data Integrity, Authentication • Datagram Support • Optimized handshake • Dynamic key refreshing

Implementation classes: WTLS implementations may have support for various features:

Feature Class 1 Class 2 Class 3 Public-key exchange M M M Server certificates O M M Client Certificates O O M Shared-secret handshake O O O Compression - O O Encryption M M M MAC M M M interface - O O ** M – mandatory, O – optional

3 Wireless Security.doc Confidential 10/04/00

3.2 WTLS issues No end-to-end security with the web server • All data is available in plain in the WAP gateway during the translation between SSL and WTLS. • Client authentication is only available to the WAP gateway. Especially client authentication does not provide any additional level of security for the content provider. The WAP gateway is the only entity that can verify the client using client certificates. The content provider’s web server must therefore ultimately trust the WAP gateway. No minimal set of cipher suites defined • No guaranteed common set of algorithms between client and WAP gateway. Key-exchange attacks • Key exchange, encryption and MAC algorithm are negotiated independently. This leads to very high flexibility, which allows nonsense combinations. There has been a known attack on XOR-MAC, a proprietary message authentication code algorithm. WTLS must implement reliability • Security unrelated elements in the WTLS layer • The location of the WTLS layer in the WAP stack requires security unrelated actions in the implementations such as handling of duplicates, retransmissions if no response is received within a certain time frame. WTLS is not a mandatory layer in the WAP stack Client authentication • Required for Implementation class 3. SIM (WIM) cards that hold the personal credentials, as the private key and certificate are personal data are needed. • Digital Signatures may be required for non-repudiation. Client devices • WTLS optional software is not easily upgraded. No additional software can be installed. Mostly WTLS Class 1 clients available - Class 1 only supports anonymous handshakes CBC (Cipher Block Chaining) calculated for each record • Sequence numbers guarantee order of records

3.3 Attacking WTLS Attacks to gain access to the exchanged data

Man-in-the-middle attack as at least one anonymous key exchange is mandatory in WTLS

Denial of service (DoS) attacks • Do not allow access to exchanged data • Prevent users from accessing a service • Interrupt existing secure connections Spoofing of UDP packets • Only resolvable at the dial-in server.

4 Wireless Security.doc Confidential 10/04/00

• High risk when a WAP gateway is accessible from the Internet - Using IP spoofing, an attacker can always send a ClientHello message disguised as coming, for example, from a connection from the dial-in server. New initial ClientHello on an existing connection • Close alerts of the client may not reach the server, connection state is unknown Clear text alerts and known checksums • The checksum of e.g. the change cipher spec message is known. By flooding the WAP gateway (or the client) with fake alerts, it is almost impossible to establish a secure connection.

5 Wireless Security.doc Confidential 10/04/00

4. Summary

• WTLS provides an equally high security level as TLS if appropriate algorithms are used • No end-to-end security unless the secure WAP Gateway is operated by the content provider • Enhancement made to TLS lead to an incompatible protocol with some issues • Attacks are possible depending on the implementation and environment • DoS attacks against WTLS are very easy

6 Wireless Security.doc Confidential 10/04/00

5. Appendix

5.1 WTLS security mechanism: The kernel of WTLS security is the WIM (Wireless Identity Module). The WIM performs optimized cryptography during handshake, especially for client authentication, and forges long-term, secure WTLS connections.

Three Layers: • Handshake protocol - manages secure connections, provides client and server authentication and is used to exchange keys. • Record layer - The record protocol takes messages to be transmitted, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Data received is decrypted, verified, and decompressed, then delivered to higher-level clients. • Alert protocol - Reports error conditions and handles alerts.

5.2 WTLS Handshake Protocol The WTLS Handshake Protocol involves the following steps: • Exchange hello messages to agree on algorithms, exchange random values. • Exchange the necessary cryptographic parameters to allow the client and server to agree on a pre-master secret. • Exchange certificates and cryptographic information to allow the client and server to authenticate themselves. • Generate a master secret from the pre-master secret and exchanged random values. • Provide security parameters to the record layer. • Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.

Key Exchange Algorithms: • Anonymous: based upon RSA, Diffie-Hellman and EC Diffie-Hellman key exchange • With Authentication: RSA key exchange with RSA based certificates and EC Diffie-Hellman key exchange with ECDSA certificates. • Others: Shared secret, no key exchange.

PKI has two types of certificates: WTLS mini-certificates (mandatory) and X.509 certificates.

Abbreviated handshake To resume a previously established secure connection. • Client provides session ID of the previous secure session to be resumed • Server accepts to re-establish the secure connection

7 Wireless Security.doc Confidential 10/04/00

Optimized handshake Optimized handshake is achieved by dynamic key refreshing. Dynamic key refreshing allows encryption keys to be updated on a regular and configurable basis during a secure session. This provides a higher level of security and also considerable bandwidth savings. • Server gets client certificate from certificate distribution service or own source • EC Diffie-Hellman parameters provided in the certificates allow calculating pre- master-secret

5.3 Record layer • Unlike in TLS, the record layer does not fragment information blocks. It is assumed that the transport layer takes care of the necessary fragmentation and reassembly. • Explicit sequence numbering must be used with a datagram transport protocol, meaning that records can be lost, duplicated, or received out of order. • The receiver must keep books about received records in order to discard duplicated records. This can be implemented using a sliding window.

The Record layer is responsible for: Data compression • Currently no compression is supported Data integrity • Calculates/verifies message authentication code • HMAC based: SHA-1, MD5 • XOR based: SHA-1 Privacy • Encrypts/decrypts data using bulk ciphers • Bulk cipher algorithms: RC5, DES, 3DES, IDEA

5.4 Alert protocol • Upon transmission or receipt of a fatal alert message, both parties immediately close the secure connection. • Servers and clients are required to forget any session identifiers, keys, and secrets associated with a failed secure connection. • Upon transmission or receipt of a critical alert message, both parties immediately close the secure connection but may preserve the session identifiers and use that for establishing new secure connections. • A MAC error is only a warning and not an error. If the MAC verification fails, the received record is discarded but the secure connection is kept open to prevent from denial of service attacks.

8 Wireless Security.doc Confidential 10/04/00

Alerts can be classified as: Closure alerts • Connection/session closed Error alerts • Fatal error - close secure connection, invalidate session id • Critical error - close secure connection Warning – e.g. MAC error.

9 Wireless Security.doc Confidential 10/04/00

6. References

WAP WTLS specification: http://www1.wapforum.org/tech/documents/WAP-163-WTLS-19991105-a.pdf

Phone.com white paper on Security http://www.phone.com/pub/Security_WP.pdf

Presentation on WTLS http://www.keyon.ch/en/publications/infosec_wtls_keyon.pdf http://www.tml.hut.fi/Opinnot/Tik-110.501/1999/papers/wtls/wtls.html

Developer websites: www.Phone.com www.nokia.com www.anywhereyougo.com

Security provider’s web sites: www.certicom.com www.verisign.com www.rsasecurity.com www.baltimore.com www.entrust.com

Web Security: A Step-by-Step Reference Guide by Lincoln D. Stein, Addison Wesley

10 Wireless Security.doc Confidential 10/04/00