Integrated Transport Layer Security : End-to-End Security Model between WTLS and TLS

Transcription

1 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 ekkwon@mercury.kaywon.ac.kr 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 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 from having the plain text message assuming the doesn t belong to the content provider. In ITLS, the security partner of a Web server is not a but a client, the client encrypts twice times for the Web server and the 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. 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]. 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 Figure 1. WAP protocols conserve wireless bandwidth The WAP 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. Even though the interval time the message remains unencrypted is very short, end-toend 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

2 modified to integrate seamlessly wireless Internet security with TLS. The goal of ITLS is to prohibit the WAP from having the plain text message assuming the 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 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 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, allowing for a virtual, secure connection between the two protocols. Suppliers of WAP take every measure possible to keep the WAP 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 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. 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 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 at a content provider or in an enterprise, which places a burden on the content provider to have a different configuration on their for each network and SMSC (Short Message Service Center)- combination.

3 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 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 must not have the plain text even though the time is very short, because the is not a sender nor a receiver nor a CA (Certificate Authority) Suppliers of the WAP 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 become to share one secret key, a 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 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 but a client. Figure2showsthisconcept. 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 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, the latter is one of a and a server. On the other hand, in ITLS the client encrypts twice times for the Web server and the in the order named. The decrypts the cipher text from the client and sends it to the server without encryption. But the message transmitted from the is also a cipher text because the message is encrypted by the client not the unlike WTLS. In reverse, the 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, 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 premaster 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, 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. Pub x : x s public key Pri x :x sprivatekey E(K, M) : encryption of M using key K D(K, M) : decryption of M using key K SK x,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.

4 Pub c : Client s public key Pri c : Client s private key Pub gw : GW s public key from Certificate Pri gw : GW s private key from Certificate Pub s : Server s public key from IntCertificate Pri s : Server s private key from IntCertificate SK c,gw : the pre-master secret key between a client and a from ClientKeyExchange SK c,s : the pre-master secret key between a client and a server from IntClientKeyExchange SK gw,s : the pre-master secret key between a and a server, which is equal to SKc,s Additional operation of a client in ITLS Receiving and keeping IntCertificate IntClientKeyExchange (E(Pub s,sk c,s ), others) Note that ClientKeyExchage (E(Pub gw, SK c,gw ), others) is different from IntKeyExchange. Applied modification of a in ITLS ClientKeyExchange (R, others) in which R is E(Pub s,sk c,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 Œ Œ š G yˆ œ Œ G zœšš G j Œ Œ šg { œš Œ Œ šg j Œ šœ ŒšG j Œšš Œ šg zœ œœ ŠŒ œ Œ G rœ Œ Œš G j Œ / j Œ oœ G zœ Œ oœ G p zœ Œ rœ lÿš ˆ ŽŒQG jœ Šˆ ŒyŒ œœš QG zœ Œ oœ k Œ/ ~hwgnv~/ j Œ oœ GGGGGGGGGGG zœ Œ / zœ Œ oœ G zœ Œ rœ lÿš ˆ ŽŒQG jœ Šˆ ŒyŒ œœš QG zœ Œ oœ k Œ j Œ Œ š G yˆ œ Œ G zœšš G j Œ šœ ŒšG j Œšš Œ šg j Œ rœ lÿš ˆ ŽŒQG p j Œ rœ lÿš ˆ ŽŒQG jœ Šˆ Œ}Œ QG j ˆ ŽŒj Œ z ŒŠ/ oˆš oˆ š ˆ Œ/ j Œ rœ lÿš ˆ ŽŒQG jœ Šˆ Œ}Œ QG j ˆ ŽŒj Œ z ŒŠG j ˆ ŽŒj Œ z ŒŠGGGGGG j ˆ ŽŒj Œ z ŒŠGGGGGG Figure 3. The ITLS full handshake

5 ClientHello c, g is ClientHello message from a client to a. 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. ClientHello c, g - ClientHello g, s random-number[32] g,s = (random-number[16] c,g, padding[16]) session-id g, s =session-id c, g cipher-suites g, s = [client-key-ids c, g, cipher-suites c, g ] compression-method g, s = compression-methods c, g ServerHello s, g - ServerHello g, c random-number[32] g, c = random-number[32] s, g client-key-id g, c = cipher-suite[keyexchange] s, g cipher-suite g, c =cipher-suite[mac,bulkencryption] s, g Certificate s, g - IntCertificate g, c ServerKeyExchange s, g - ServerKeyExchange g, c IntClientKeyExchange c, g - ClientKeyExchange g, s EncryptedPreMasterSecret[48] g, s = RSAEncryptedSecret[48] c, g HashHandshake = H(handshake_message g, s ) Finished c, g - Finished g, s Verify_data g, s = verify_data c, g [12..23] Finished c, g =verify_data[0..23] c, g Verify_data[0..11] c, g =PRF(master_secret c, g, finished_label, H(handshake_message c, g )) Verify_data[12..23] c, g =PRF(master_secret c, s, finished_label, HashHandshake) Finished s, g -Finished g, c Verify_data[0..11] g, c = PRF(master_secret c, g, finished_label, H(handshake_message c,g )) Verify_data[12..23] g, c = Verify_data[0..11] s, g 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. MS x,y : MAC secret key between x and y including two values which are write and read key EK x,y : encryption secret key between x and y including two values which are write and read key SM o :originalfragment(plaintext)fromaclient SM e : encrypted fragment (cipher text) of SM o and decrypted fragment of SM e2 for a client and a server SM e2 : encrypted fragment of SM e for a client and a RM o : original fragment (plain text) from a server RM e : encrypted fragment (cipher text) of RM o and decrypted fragment of RM e2 for a client and a server RM e2 : encrypted fragment of RM e for a client and a j Œ / zt G l Š QYG GGG zt ŒYG nˆ Œžˆ / ŒŠ G G G zt ŒG yt ŒYG zœ Œ / zt G ŒŠ G GG yt G Œ Š G G G 4.2. ITLS Record Protocol yt G yt Œ Œ Š G GG 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 in ITLS Pre-master secret key between a and a kœš QYG GGG Figure 4. ITLS application data flow/ Table 1. Application data encryption and decryption Type Client -> Server client SM e =E(EK c,s,(sm o +HMAC(MS c,s,sm o ))) SM e2 =E(EK c,gw,(sm e +HMAC(MS c,gw, SM e )))

6 Type Server -> Client server RM e =E(EK c,s,(rm o +HMAC(MS c,s,rm o )) ) SM e =D(EK c,gw,sm e2 ) server SM o =D(EK c,s,sm e ) client RM e =D(EK c,gw,rm e2 ) RM o =D(EK c,s,rm e ) RM e2 =E(EK c,gw,(rm e +HMAC(MS c,gw, RM e ))) 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 can not recognise it, since the doesn t decryptthemessage.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 is necessary so that two sessions, which are one of the client and the and the other of the and the server, are interoperated in real-time manner. Generally there are many types of that is one between OSI and TCP/IP or MHS X.400 and propriety messaging system, the 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= ECC-DSA key generation 163ECC-DSA sign generation 163ECC-DSA sign verification 1) 4900ms for 1000 encryptions 2) 2780 for a 1000 long hash chain 597ms 776ms 2448ms 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. 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 endto-end authenticity, all function partners have to be changed to a client or a server from a. Then the 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-toend security model that is called ITLS (Integrated TLS) above chapters. The goal of ITLS is to prohibit the WAP from having the plain text message assuming the 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 can not recognise it, since the 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 [2] T. Dierks, C. Allen, The TLS Protocol Version 1.0, RFC2246, Jan [3] Understanding Security on the Wireless Internet, Phone.com, Jan / / [4] Neil Daswani and Dan Bonch, Experimenting with Electronic Commerce on PalmPilot, In proceedings of Financial Cryptography 99, 1999.

7 [5] Rikard Kjellberg, Ellipsus Communication Server Architecture Issue <1.0>, Ellipsus, May [6] WAP Corporate Version White paper, S.E.S.A. Software and System AG. [7] WAP Security Toolkit [WST], A Baltimore Technologies White Paper, Baltimore tm. [8] B. Schneier, Applied Cryptography, 2 nd ed, Wiley, New York, [9] D. Stinson, Cryptography Theory and Practice, CRC Press, Boca Raton, [10] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing for Message Authentication, RFC2104, Feb [11] R. Rivest, The MD5 Message-Digest Algorithm, RFC1321, Apr [12] WAP Forum, Wireless Application Protocol Architecture Specification, version 1.2, WAPForum, Apr. 1998, available at [13] WAP Forum, Wireless Transport Layer Security Specification, version 1.2, Nov [14] Martin Christinat, Markus Lsler, WTLS The security layer in the WAP stack, keyon, Jun [15] Tobias Eidem, The effect of the WAP on a WAP network, Royal Institute of Technology, 1999.