Abstract
WAP is a set of protocols that optimizes standard TCP/IP/HTTP/HTML protocols, for use under the low bandwidth, high latency conditions often found in wireless networks. But, end-to-end security is not supported unless a WAP gateway is operated by the content provider. We propose ITLS mechanism to solve the WAP security problem. The goal of ITLS is to prohibit the WAP gateway from having the plain text message assuming the gateway doesn’t belong to the content provider. In ITLS, the security partner of a Web server is not a gateway but a client, the client encrypts twice times for the Web server and the gateway in the order named. To support these functions, IniCertificate and IntClientKeyExchange message types are added in ITLS handshake protocol, application data encryption and decryption rules are modified. It is one drawback that ITLS enabled mobile devices might have many loads than WTLS because of encryption and decryption twice times.
1. Introduction
Internet services and applications for mobile devices are increasing rapidly. In order to deliver these services and applications over the Internet in a secure, scalable and manageable way, new architectures and protocols are being designed. The WAP (Wireless Application Protocol) is a result of continuous work to define an industry-wide specification. M-Commerce (Mobile-Commerce) is being spurred by the mobile phone industry’s widespread support of the Wireless Application Protocol. The protocol stack defined in WAP 1.0 optimizes standard TCP/IP/HTTP/HTML protocols, for use under the low bandwidth, high latency conditions often found in wireless networks. The improvements made in the WAP protocol stack lead to significant savings in wireless bandwidth. Figure 1
compares the number of packets needed to process a stock quote query from a desktop browser using HTTP1.0 with the same query from a WAP browser. The WAP protocol uses less than half the number of packets that the standard HTTP/TCP/IP stack uses to deliver the same content. This improvement is essential to best utilize the limited wireless bandwidth available [1].
Figure 1. WAP protocols conserve wireless bandwidth
The WAP gateway is a bridge between the WTLS and TLS security protocols. In the data exchange between TLS and WTLS protocols, the message transmitted between the handset and the Web server is unencrypted for a very brief moment inside the WAP gateway. Even though the interval time the message remains unencrypted is very short, end-to-end security is not supported. It is very clear that who can process the message is only a sender or a recipient.
In this paper, we propose end-to-end security model, which is called ITLS (Integrated TLS). It doesn’t need any change in TLS part, because TLS is the existing standard in Internet. But WTLS must be
Integrated Transport Layer Security
: End-to-End Security Model between WTLS and TLS
Eun-Kyeong Kwon, Yong-Gu Cho, Ki-Joon Chae
Kaywon School of Art and Design, Youngdong University, Ewha Womans University
modified to integrate seamlessly wireless Internet security with TLS. The goal of ITLS is to prohibit the WAP gateway from having the plain text message assuming the gateway doesn’t belong to the content provider. In chapter 2, Internet security issues are described. In chapter 3, WAP security problem having no end-to-end security is commented. In chapter 4, ITLS model concept and specification is proposed compared to WTLS or TLS specification. And ITLS analyses are described. Finally we conclude on ITLS in chapter 5.
2. Internet Security
There are four different concerns that a security system can address: privacy, integrity, authenticity and non-repudiation. Privacy ensures that only the sender and the intended recipient of an encrypted message can read the contents of that message. Integrity ensures the detection of any change in the context of a message between the time it is sent and the time it is received. Authentication ensures that all parties in a communication are who they claim to be. Non-repudiation provides a method to guarantee that a party to a transaction cannot falsely claim that they did not participate in that transaction.
A first step to understanding how the WAP security model works is to review how TLS security makes e-commerce secure over the Internet. TLS use public key cryptography, bulk encryption algorithms and shared secret key exchange techniques to provide privacy over the Internet [2]. TLS uses public key cryptography to exchange a shared secret key for bulk encryption at the beginning of a secure Internet conversation. To provide integrity, TLS uses hashing algorithms that create a small mathematical fingerprint of a message. Digital certificates are used to provide an authenticated way to distribute public and private keys. Server certificates and client certificates include the certificate holder’s identity and public key, and other information used to authenticate the certificate. The certificate is itself encrypted with the private key of a certificate authority. Applications can request a digital signature from a client, which requests that the user specifically authorize a transaction. The authorization is then encrypted utilizing the user’s private key from their client certificate. This digital signature provides non-repudiation [3].
Public Key Infrastructure (PKI) solutions help content providers and clients manage and maintain
their digital certificates so that it is secure and easy to organize. PKI contains three common functional components: the certificate authority, a repository for keys, certificates and certificate revocation lists on an LDAP-enabled directory service, and a management function.
3. WAP Security Problem
The WAP gateway is a bridge between the WTLS and TLS security protocols like Figure 2. The need for translation between TLS and WTLS is incurred by the very nature of wireless communication: low bandwidth transmissions with high latency. WTLS processes security algorithms faster by minimizing protocol overhead and enables more data compression than traditional TLS solutions. The translation between TLS and WTLS takes milliseconds and occurs in the memory of the WAP gateway, allowing for a virtual, secure connection between the two protocols. Suppliers of WAP gateway take every measure possible to keep the WAP gateway itself secure by for example using a process of decryption / re-encryption that is security conscious and optimised for speed so that the unencrypted content of a message is erased from the volatile internal memory of the WAP gateway as quickly as possible. WTLS is based on Internet standard security protocol TLS 1.0, which in turn is based on SSL 3.0. WTLS goes beyond TLS1.0 by incorporating new features such as datagram support, optimised handshake and dynamic key refreshing [3].
As the market for highly secure applications increases, a more flexible and extensible solution of end-to-end secure content will be needed. In the data exchange between TLS and WTLS protocols, the message transmitted between the handset and the Web server is unencrypted for a very brief moment inside the WAP gateway. Even though the interval time the message remains unencrypted is very short, who has an administrator account can attempt to view the unencrypted message. Suppliers of the WAP gateway have no authority by which they can see the unencrypted message. It is very clear that who can process the message is only a sender or a recipient.
To solve this problem, existing end-to-end security schema promote installing a WAP gateway at a content provider or in an enterprise, which places a burden on the content provider to have a different configuration on their gateway for each network and SMSC (Short Message Service Center)- combination.
This creates a number of difficulties for content providers, subscribers and wireless network operators. A well-designed enterprise WAP solution should insulate the content site from implementation details of the wireless network so that applications remain network- and SMSC independent. And it integrates seamlessly with network WAP gateway solutions [3].
4. Proposed End-to-End Security Model :
ITLS
The goal of ITLS is to integrate transparently wireless Internet security with TLS as follows. The WAP gateway must not have the plain text
even though the time is very short, because the gateway is not a sender nor a receiver nor a CA (Certificate Authority)
Suppliers of the WAP gateway must belong to service providers or network providers. Content providers operating Web servers must be independent on service providers.
In WTLS, a client and a gateway become to share one secret key, a gateway and a Web server do the other secret key during a WTLS or TLS secure session. The concept of ITLS is to change the owner of the secret key, shortly speaking. In ITLS, a client and a gateway become to share one secret key – no change by this time -, a client and a Web server do other secret key during one session. The security partner of a Web server is not a gateway but a client. Figure 2 shows this concept.
Figure 2. Security solution used in ITLS
4.1. ITLS Handshake Protocol
Any change of TLS part is not needed, handshake protocol and record protocol of WTLS are modified in simple manner.
A WTLS gateway decrypts the cipher text from a client using one secret key, encrypts the plain text for a server using the other secret key. The former is the secret key of a client and a gateway, the latter is one of a gateway and a server. On the other hand, in ITLS the client encrypts twice times for the Web server and the gateway in the order named. The gateway decrypts the cipher text from the client and sends it to the server without encryption. But the message transmitted from the gateway is also a cipher text because the message is encrypted by the client not the gateway unlike WTLS. In reverse, the gateway doesn’t decrypts the cipher text sent by the server, only encrypts and sends it to the client. The client decrypts it using a secret key for the gateway, and decrypts again using a secret key for the server.
To apply this mechanism, new handshake flows are displayed in Figure 3. A client must know the public key of a server for secure sending the pre-master key between a client and a server if key exchange protocol is RSA. ITLS handshake protocol adds IntCertificate message right after Certificate message, which is the certificate of a server, adds
IntKeyExchange message right after
ClientKeyExchange message, which includes the pre-master key for the secret key between a client and a server. In a gateway, to relay Certificate to
IntCertificate and IntKeyExchaneg to
ClientKeyExchange is needed, which is displayed as thin arrows in Figure 3. And Hash_Handshake is added to compute finished message in client.
To describe ITLS handshake protocol in detail, following notation rules are used.
Pubx: x’s public key
Prix: x’s private key
E(K, M) : encryption of M using key K D(K, M) : decryption of M using key K SKx,y: the shared secret key between x and y
HMAC(K, M) : the secure hash expression of M using the shared secret key K
The followings are components for describing modification parts compared to WTLS, and are ITLS handshake protocol description using predefined components.
Pubc: Client’s public key
Pric: Client’s private key
Pubgw: GW’s public key from Certificate
Prigw: GW’s private key from Certificate
Pubs: Server’s public key from IntCertificate
Pris: Server’s private key from IntCertificate
SKc,gw : the pre-master secret key between a client
and a gateway from ClientKeyExchange
SKc,s: the pre-master secret key between a client and
a server from IntClientKeyExchange
SKgw,s: the pre-master secret key between a gateway
and a server, which is equal to SKc,s
Additional operation of a client in ITLS Receiving and keeping IntCertificate
IntClientKeyExchange (E(Pubs, SKc,s), others) –
Note that ClientKeyExchage (E(Pubgw, SKc,gw),
others) is different from IntKeyExchange. Applied modification of a gateway in ITLS
ClientKeyExchange (R, others) in which R is E(Pubs, SKc,s) of IntClientKeyExchange .
No change of a server in ITLS
Followings are more detailed description about ITLS full handshake in Figure 3. For example,
j/ z/ joG jQG jr lQG pjr lQG j} QG jjz/ jjzG G G G G G m/ zoG jQG zr lQG jyQG zok zoG jQG pjQG zr lQG jyQG zok/ joG G G G G G G G G G G jQG jr lQG j} QG jjzG m/ jjzG G G G G G m/ ~hwGnV~/ ! "! "# ! !$! % !$! ! " !" ! "# ! ! "! "# ! ! " !" ! $/ /
ClientHelloc,gis ClientHello message from a client to
a gateway. Underlined messages mean that they are newly added, italic messages mean that they are modified in ITLS. Our own symbols are introduced as follows. M |- N where M and N are messages means that N can be computed from M. (M, N) represents the pairing of M and N which might be implemented by concatenation. [M, N] means that M and N are restructured or reordered.
ClientHelloc,g |- ClientHellog,s
random-number[32]g,s=
(random-number[16]c,g, padding[16])
session-idg,s=session-idc,g
cipher-suitesg,s= [client-key-idsc,g, cipher-suitesc,g]
compression-methodg,s= compression-methodsc,g ServerHellos,g |- ServerHellog,c random-number[32]g,c= random-number[32]s,g client-key-idg,c= cipher-suite[keyExchange]s,g cipher-suiteg,c=cipher-suite[MAC,BulkEncryption] s,g Certificates,g|- IntCertificateg,c ServerKeyExchanges,g|- ServerKeyExchangeg,c IntClientKeyExchangec,g|- ClientKeyExchangeg,s EncryptedPreMasterSecret[48]g,s= RSAEncryptedSecret[48]c,g HashHandshake = H(handshake_messageg,s) Finishedc,g|- Finishedg,s Verify_datag,s= verify_datac,g[12..23] Finishedc,g=verify_data[0..23]c,g Verify_data[0..11]c,g=PRF(master_secretc,g, finished_label, H(handshake_messagec,g)) Verify_data[12..23]c,g=PRF(master_secretc,s, finished_label, HashHandshake) Finisheds,g|-Finishedg,c Verify_data[0..11]g,c= PRF(master_secretc,g, finished_label, H(handshake_messagec,g)) Verify_data[12..23]g,c= Verify_data[0..11]s,g
4.2. ITLS Record Protocol
Record protocol uses several keys, which are included in security parameters from handshake protocol. Record protocol modification related to keys is as follows.
Additional information of a client in ITLS
Server’s certificate including server’s public key Pre-master secret key between a client and a server
Applied modification of a gateway in ITLS
Pre-master secret key between a gateway and a
server = Pre-master secret key between a client and a server
No change of a server in ITLS
The followings are additional components for describing record protocol. Table 1 is ITLS application data encryption and decryption expression for describing record protocol modification using predefined components, and shows easily the relation between messages in Figure 4. Puls(+) means concatenation in Table 1.
MSx,y: MAC secret key between x and y including
two values which are write and read key
EKx,y : encryption secret key between x and y
including two values which are write and read key SMo: original fragment (plain text) from a client
SMe : encrypted fragment (cipher text) of SMo and
decrypted fragment of SMe2for a client and a server
SMe2: encrypted fragment of SMe for a client and a
gateway
RMo: original fragment (plain text) from a server
RMe : encrypted fragment (cipher text) of RMo and
decrypted fragment of RMe2for a client and a server
RMe2: encrypted fragment of RMe for a client and a
gateway
Table 1. Application data encryption and decryption
Type Client -> Server
client SMe=E(EKc,s,(SMo+HMAC(MSc,s,SMo)))
SMe2=E(EKc,gw,(SMe+HMAC(MSc,gw, SMe))) ytG ytYG yt ytG ztG ztG ztYG ztGj/ z/ G G G n / G G G G G G G G G k QYG G G G l QYG G G G
gate-way
SMe=D(EKc,gw, SMe2)
server SMo=D(EKc,s, SMe)
Type Server -> Client
server RMe=E(EKc,s,(RMo+HMAC(MSc,s,RMo))
) gate-way RMe2=E(EKc,gw,(RMe+HMAC(MSc,gw, RMe))) client RMe=D(EKc,gw, RMe2) RMo=D(EKc,s, RMe) 4.3. ITLS Analyses
Predictable concerns in ITLS implementation are described as follows. The first is that mobile devices might have many loads than WTLS because of encryption and decryption twice time. Statistical amount of overload is not accounted until now. Table 2 shows sample performance comparison in PalmPilot with 16Mhz, Motorola DragonBall Chip(68K family) [4]. Like Table 2, it might not be critical because of increasing power or memory of mobile devices rapidly. In second, even though the message sent by a server has errors like hacking or fraud, an ITLS enabled gateway can not recognise it, since the gateway doesn’t decrypt the message. The message including errors is sent to a client. This problem is trivial because at last the problem is known to the client, the client will try to solve the problem : to request the message again or to stop the session or to inform the upper layer simply. In third, additional consideration in design of the WAP gateway is necessary so that two sessions, which are one of the client and the gateway and the other of the gateway and the server, are interoperated in real-time manner. Generally there are many types of gateway that is one between OSI and TCP/IP or MHS X.400 and propriety messaging system, the gateway internal design is not included in standards. Those materials has to be referenced [5][6][7].
Table 2. Timing measurements for cryptographic primitives on the PalmPilot
Algorithm Time Comment
DES encryption SHA-1 4.9ms/block 2.7ms/block 1) 2)
512RSA key generation 512RSA sign generation 512RSA sign verification 512RSA sign verification
3.4 minutes 7028ms 438ms 1376ms e=3 e=65535
163ECC-DSA key generation 163ECC-DSA sign generation 163ECC-DSA sign verification
597ms 776ms 2448ms
1) 4900ms for 1000 encryptions 2) 2780 for a 1000 long hash chain
To extend ITLS is possible as follows. In handshake protocol to authenticate for each other also can be substituted by a client or a server not a gateway. ITLS’s key point is to provide privacy and integrity in record protocol, only the security partner – who shares a secret key – is changed. To try end-to-end authenticity, all function partners have to be changed to a client or a server from a gateway. Then the gateway responsibility will decrease, many side effects must be solved.
5. Conclusion
Now the industry is poised to take its next big leap forward into the wireless world. As the market for highly secure applications increases, a more flexible and extensible solution of end-to-end secure content will be needed. We proposed and described end-to-end security model that is called ITLS (Integrated TLS) above chapters. The goal of ITLS is to prohibit the WAP gateway from having the plain text message assuming the gateway doesn’t belong to the content provider.
We can predict some concerns in ITLS implementation as follows. The first is that mobile devices might have many loads than WTLS because of encryption and decryption twice time. In second, even though the message sent by a server has errors like hacking or fraud, an ITLS enabled gateway can not recognise it, since the gateway doesn’t decrypt the message. Those are remaining issues to be simulated statistically.
6. Reference
[1] “The Wireless Application Protocol, Wireless Internet Today”, Unwired Planet, Inc., Feb. 1999. [2] T. Dierks, C. Allen, “The TLS Protocol Version 1.0”, RFC2246, Jan. 1999.
[3] “Understanding Security on the Wireless Internet”, Phone.com, Jan. 2000./ /
[4] Neil Daswani and Dan Bonch, “Experimenting with Electronic Commerce on PalmPilot”, In proceedings of Financial Cryptography ’99, 1999.
[5] Rikard Kjellberg, “Ellipsus Communication Server Architecture Issue <1.0>”, Ellipsus, May 2000.
[6] “WAP gateway Corporate Version White paper”, S.E.S.A. Software and System AG.
[7] “WAP Security Toolkit [WST], A Baltimore Technologies White Paper”, Baltimoretm.
[8] B. Schneier, Applied Cryptography, 2nded, Wiley,
New York, 1995.
[9] D. Stinson, Cryptography Theory and Practice, CRC Press, Boca Raton, 1995.
[10] H. Krawczyk , M. Bellare , R. Canetti ,
“HMAC: Keyed-Hashing for Message
Authentication”, RFC2104, Feb. 1997.
[11] R. Rivest , “The MD5 Message-Digest Algorithm”, RFC1321, Apr. 1992.
[12] WAP Forum, “Wireless Application Protocol Architecture Specification, version 1.2”, WAP Forum,
Apr. 1998, available at
http://www.wapforum.org/tech/.
[13] WAP Forum, “Wireless Transport Layer Security Specification, version 1.2”, Nov. 1999. [14] Martin Christinat, Markus Lsler, “WTLS – The security layer in the WAP stack”, keyon, Jun. 2000. [15] Tobias Eidem, “The effect of the WAP gateway on a WAP network”, Royal Institute of Technology, 1999.
