2012 IEEE 23rd International Symposium on Personal, Indoor and Mobile Radio Communications - (PIMRC)
Extending TLS to secure Multihost Applications Exchanges M. Badra1,2, N. Jabeur2, N. Sahli2, and R. Borghol2 1
LIMOS Laboratory, CNRS, France 2 Dhofar University, Oman
Many security protocols have been developed to handle security problems in various circumstances. However, these protocols are often limited to client/server architectures and cannot answer special application and network’s needs such as securing audio/video applications or transactions between several nodes in wireless mesh networks. In this paper, we propose extending the Transport Layer Security (TLS) protocol to securely exchange data between multiple nodes through a single TLS session and to provide thirdparty auditing capability. We propose a formal validation of our extension with the EVA language using Hermes.
I. INTRODUCTION
O
the last years, several security protocols like Transport Layer Security (TLS) [1] and IP Security (IPSec) [4] have been defined and developed in order to authenticate end-communicating entities and to share a session secret key. Some of these protocols are designed to establish host-to-host secure sessions (e.g., TLS) whereas other protocols are dedicated to establish secure sessions from hostto-edge or from edge-to-edge (e.g., IPSec). These protocols could be deployed to establish Virtual Private Networks (VPN) and therefore to secure host-to-edge communications by establishing a single secure session between the host and the network edge. In this paper, we propose to secure communications between multiple hosts/nodes in a distributed wireless mesh networks environment through a single TLS session. We consider two network topologies, namely, the star topology and the mesh network topology. In the first topology (Star Network), we aim at establishing a single TLS session between the central host and the other hosts. This could be applied to schedule online meetings where one may plan a meeting by sending the list of participating members to a central host along with the meeting date and purpose. None of the security protocols previously mentioned allows secure exchange of data between different entities by establishing one single secure session. Indeed, the classical solution consists in establishing an independent secure session between the central host and each of the other hosts. In other words, the central host will share a different session secret key with each of the other hosts. Consequently, each message received by the central host shall be decrypted and then encrypted with a different key before being transferred to another host. In the second topology (Mesh Network), we aim at VER
2 7
3
3 1
5
II. TLS OVERVIEW 1 6
6
establishing a secure session between two hosts (source and destination) and to share the same session secret key with intermediate hosts involved in the communication between the source and the destination. The classical solution consists in establishing a secure session between the source and the destination and then sharing the session secret key with their neighbors. In this regard, each host which holds the session secret key shall securely send it to each of its neighbors. However, hosts receiving the session secret key may not always share the same cryptographic options negotiated by the source and the destination and will not be able to be part of the secure session. Moreover, some hosts will redundantly receive the same information from their different neighbors. Besides these two scenarios, we have identified other situations where end-to-end security protocols are deployed in the presence of one or more intermediate hosts (between two end-communicating hosts) as such the case of TLS in Wireless LAN. Another example is when a legal third entity is willing to analyze encrypted traffic. Off-line interception and analysis of protected traffic are possible when the end-communicating hosts have a copy of the session secret key and a third entity has already received the same copy from at least one of them. Nevertheless, in the case of on-line analysis, we shall define an advanced mechanism to share the same session secret key between the three concerned hosts. This scenario is useful for data traceability, which is very important not only when disputes occur between end-communicating hosts, but also when a legal entity needs to know who is doing what at any given time. The remainder of this paper is organized as follows. In section II, we briefly present TLS and in Section III, we discuss some related works. Then, in Section IV, we describe two scenarios to establish a TLS session in the case of star and mesh networks. In Section V, we propose integrating the proposed extension to the TLS handshake protocol. In section VI, we discuss our extension. Finally, we give some concluding remarks.
4 2
4
5 (a)
(b)
7
TLS [2] is the de facto standard for authenticating wired/wireless communicating entities and for securing those entities transactions. TLS is a transaction security standard that provides end-to-end secure communications between two entities with authentication based on the use of certificates or
Fig. 1. Examples of Star (a) and Mesh (b) Networks.
978-1-4673-2569-1/12/$31.00 ©2012 IEEE
2500
pre-shared keys. It consists of several sub-protocols, specially the Handshake protocol. The Handshake protocol is used to allow peers to agree upon security parameters, authenticate themselves, instantiate negotiated security parameters, and report error conditions to each other. This protocol is used to negotiate the security attributes of a session. Once a connection is authenticated and a secret shared key is established with the TLS Handshake protocol, exchanged data can be protected with cryptographic methods using the keying material derived from the shared secret. Unfortunately, TLS is limited to client/server architectures. During the Handshake phase, the client generates a secret called pre_master_secret, which is sent encrypted using the server public key. Only the server is able to decrypt the pre_master_secret since it is encrypted by its private key. Consequently, TLS cannot be used for Group Key Management (GKM) and distribution without being extended. III. RELATED WORKS Extensive protocols have appeared in the literature to secure group communications. They typically fall into three categories [10]: centralized GKM, decentralized GKM and contributory GKM. For more details on those protocols, please refer to [10]. To our knowledge, none has proposed a solution based on TLS to secure group communications. In [2], the authors suggest using the Tripartite Diffie-Hellman (TDH) algorithm based on bilinear pairings over elliptic curves in order to establish a TLS session between three entities. To integrate TDH in TLS, they extend TLS to negotiate the TDH parameters. Besides its complexity, the proposed solution is limited to a variation of DH key exchange method and cannot, at least in its current version, be used to establish a session secret key between more than three entities. Another problem with this solution is that the entities need synchronization. An alternative to secure communications between three entities (e.g., client, server, access point) using TLS for Wireless LANs is EAP-TLS [3]. In EAP-TLS, a TLS session is established between a client and a server to generate a session secret key. The server then computes a key using the generated session secret key and sends it to the access point. The client and the access point will authenticate themselves using the key sent by the server. However, this solution requires a second authentication protocol to authenticate the client to the third party and vice versa. Moreover, the session secret key generated during the TLS handshake is not used to ensure confidentiality and integrity. In other words, this solution uses TLS only for controlling wireless access. Other existing proposals [8, 9] suffer from the lack of interoperability with the current TLS specifications. IV. THE PROPOSED EXTENSION In this section, we propose extending TLS in order to establish a single TLS session in both Star and Mesh networks.
1) Star Network We consider the configuration depicted in Fig 1.a as an illustrative example of the star network architecture. We also suppose that host 2 (Fig1. a) is willing to establish a TLS session with hosts 3, 4, 5, 6, and7 through host 1 (the central host). Host 2 (acting as a TLS client) initiates the session by sending its request to host 1 (acting as the TLS server) along with the list of other hosts identifiers (the host identifier may be the DNS hostname or the IP Address). Both host 1 and host 2 will negotiate the cryptographic options such as the key exchange method (e.g., RSA) and the encryption (such as RC4) and hash (such as MD5) algorithms. Host 1 will therefore send its RSA public key or its certificate to host 2. Upon receipt of that public key, host 2 will generate a secret and then encrypt it using that public key (all hosts shall have authenticated RSA keys). Next, host 1 initiates a TLS session with each of the other hosts received from host 2 by sending the cryptographic options negotiated with host 2. Here, host 1 is acting as a TLS client whereas the other hosts will be acting as TLS servers. In other terms, each of the other hosts will send its authenticated RSA public key to host 1. Upon receipt of the public key of a given host (host X), host 1 uses it to encrypt the secret generated by host 2 and then sends the result to host X (the owner of the public key used to encrypt the secret). Host X will then use its RSA private key to have the secret in clear text. At this time, all hosts share the same secret; they use it to compute the session secret key and to generate the TLS cryptographic keys; subsequent transactions will be protected under the negotiated cryptographic options and the generated cryptographic keys. After closing the secure session, any two hosts can resume this secure session (resumed handshake in TLS terminology) to securely communicate. 2) Mesh Network We consider the configuration depicted in Fig 1.b as an illustrative example of the Mesh network architecture. We suppose that host 1 (Fig2) is willing to establish a secure session with host 4. Host 1 initially does not have the list of intermediate hosts to reach host 4 and consequently will use one of the Mesh networks routing protocols to set a path reaching host 4. Host 1 sends therefore its request through the first host (direct neighbor) in the path to host 4. In this request, host 1 includes all supported cryptographic options. Upon receipt of host 1’s request, the first intermediate host includes the received cryptographic options as well as those it can support. This intermediate host also includes its identifier and then forwards the request to the next host in the path which leads to host 4. Each host in the path leading to host 4 will do the same atomic operation. Upon receipt of the request, the destination host (host 4) will select one of the cryptographic options suggested by its neighbor and sends it to host 1 along with the list of the identifiers of the hosts which will be involved in the session As well as its own authenticated RSA public key. Except for the destination’s direct neighbor (host 4 or 6 of Fig 1.b), each
2501
host which is part of the path (from host 1 to host 4) which receives the destination response shall replace the RSA public key of the sender with its own RSA public key. As for the destination’s neighbor, it shall add its public key to the destination’s response. For example, after receiving the destination response, host 4 (direct neighbor of the destination) replaces the public key of host 5 with its own public key and forwards it to host 3 along with the destination (host4) public key and the cryptographic option selected by the destination host. Upon receipt of the response, the source (host 1) generates a secret and encrypts it using the public key of the final destination (we name v1 the encryption output). Next, host 1 encrypts the secret with the public key of the first intermediate host (its direct neighbor; here host 2 or host 3) before sending the result along with v1 to that neighbor. Except for the H1
destination’s neighbor, each host of the path from host 1 to host 4 will a) receive the encrypted secret, b) use its private key to decrypt the encrypted secret, c) encrypt the secret using the public key of the next host of the path from host 1 to host 4 and d) send the result along with v1 to the next host of the path from host 1 to host 4. Regarding the destination’s neighbor, it will decrypt the encrypted secret and forward the value v1 to the destination (host 4). Finally, host 4 will use its RSA private key to decrypt v1 and have the secret in clear text. At this stage, all hosts share the same secret; they can use it to compute the session secret key which will be the same for all hosts. Once the hosts generate the session secret key, they may securely send and receive application data over the secure connection.
H2 ClientHello ProtocolVersion SessionID CipherSuites Extension[H1]
ServerHello ProtocolVersion SessionID Selected CipherSuites Extension[H1, H2, H3, H4] Certificate ServerKeyExchange IntermediateCertificate IntermediateServerKeyExchange ServerHelloDone
ClientCertificate ClientKeyExchange E(premastersecret , H4 PubKey ) IntermediateClientKeyExchange E(premastersecret , H2 PubKey )
• • • • •
H3
ClientHello ProtocolVersion SessionID Supported CipherSuites Extension[H1, H2]
ServerHello ProtocolVersion SessionID SelectedCipherSuites Extension[H1, H2, H3, H4] Certificate ServerKeyExchange IntermediateCertificate IntermediateServerKeyExchange ServerHelloDone
ClientCertificate ClientKeyExchange E(premastersecret , H4 PubKey ) IntermediateClientKeyExchange E(premastersecret , H3 PubKey )
H4
ClientHello ProtocolVersion SessionID Supported CipherSuites Extension[H1, H2, H3]
ServerHello ProtocolVersion SessionID Selected CipherSuites Extension[H1, H2, H3, H4] Certificate ServerKeyExchange ServerHelloDone
ClientCertificate ClientKeyExchange E(premastersecret , H4 PubKey )
ClientKeyExchange and IntermediateClientKeyExchange messages convey the value E (premastersecret , H PubKey ), which is the encryption of the premaster secret using H public key . IntermediateServerKeyExchange message includes the authenticated RSA public key of that message’s sender . Supported CipherSuites field includes the cipher suites proposed by H 1 and supported by that field’s sender . ServerKeyExchange and IntermediateServerKeyExchange are is sent only when the sender certificate message (if sent) does not contain enough data to allow the receiver to exchange a premaster secret . The field Extension includes the hosts’ identifiers
Fig. 2. Scenario of four nodes/hosts.
2502
V. OUR EXTENSION INTEGRATION TO TLS TLS provides both generic extension mechanisms for the TLS handshake client and server hellos and specific extensions using these generic mechanisms [1]. In this paper, we specify two extensions to enable our solution integration to TLS. We describe both of them for each of the two topologies previously discussed (Star and Mesh). We also define two new TLS messages to carry parameters which are related to the TLS session. 1) The case of Mesh Network In order to negotiate the extension described above, the source host includes an extension of type “host_identifier” in its client hello. The “extension_data” field of this extension contains "HostIdentifierList" where: struct { IdentifierType identifier_type; select (identifier_type) { case host_id: HostIdentifier; } identifier; } HostIdentifier; enum { host_id(0), (255) } IdentifierType; opaque HostIdentifier; struct { HostIdentifier host_iden; } HostIdentifierList; If the destination host is aware of the extension but not wishing to use it, it will gracefully revert to an ordinary TLS handshake or will stop the negotiation. Initially, the list sent by the source contains the identifiers of the destionation hostname. A host that receives a client hello containing the "host_identifier" extension shall verify if it supports that extension and then updates the list by including its hostname. Otherwise, the host sends an alert to the list sender and stops the session. TLS specifies a list of cipher suites, each of these ciphers defines a key exchange algorithm, a bulk encryption algorithm (including the secret key length) and a MAC algorithm [1]. In our extension, the source can include several TLS cipher suites in its client hello. If an itermediate host does not support at least one cipher suite among the list included in a request, or if the received TLS version is not supported, the host shall stop the session. The destination host may also include an extension of type "host_identifier" in the server hello. The "extension_data" field of this extension contains the list of identifiers of the hosts involved in the TLS session. When the extension defined here is negotiated, the intermediate hosts will not generate any random value and only the random value generated by the destination is used during the key generation and computation. Apart from the source, each of the other hosts will use the
server_key_exchange message defined by TLS [1] to convey the destination public key to its neigbor. To send its public key to its neighbor, each intermediate host will use a new message called “intermediate_server_key_exchange” message. These two messages have the same structure described in [1]. However, the intermediate host has to includes its certificate to the “intermediate_server_key_exchange” message. Upon receipt of the destination public key, the source sends an encrypted premaster secret using the destination public key; the result is conveyed using the client_key_exchange message. To send its authenticated RSA public key to its neighbor, each intermediate host -except the destination’s neighbor- sends a “intermediate_client_key_exchange” message. These above two messages have the same structure described in [1]. However, the intermediate host has to include its certificate to the “intermediate_client_key_exchange” message. Only the source and the destination hosts will generate the TLS finished message values, as described in [1]. Since the destination may not receive the same content generated by the sender and conveyed in the extensions defined here, the following data are omitted from the finished computation: the extensions defined here, the cipher suites, and the intermediate client and server key exchange messages. 2) The case of Star Network In the case of Star networks, the host initiating the session includes the extension “host_identifier”. The initiating host inserts in the extension_data the list of host identifiers to be contacted by the central host. Our extension includes the field gmt_unix_time1. This field is empty if the initiating host is willing to immediately start a secure communication with the other hosts, in which case the central host initiates a TLS session with each of the hosts found in the received extension. If the initiating host is willing to ask the central host to start the secure communication at a given date/time, it shall explicitly include that in the field gmt_unix_time1, which conveys the time and the date in the standard UNIX 32-bit format. struct { HostIdentifier host_iden; uint32 gmt_unix_time1; } HostIdentifierList; When the TLS session is established between the initiating and the central host, the latter will launch a TLS session with each of the hosts specified by the initiating host. The central host includes in its hello message the same list of host identifiers sent by the initiating host, along with the date. Once the TLS session is established between the initiating and the central host, a session identifier is generated to identify the TLS session. The central host uses the same TLS session identifier as a session identifier for every TLS session established with any of the hosts specified by the initiating host. Using the same session identifier allows any two given hosts to resume the TLS session later. The central host and the other hosts will continue the TLS Handshake as described in Section IV.B.
2503
VI. VI. DISCUSSION AND RESULTS The primary advantage of our extension is its deployment easiness as no changes need to be made to the application layer protocols. The extension design is completely backwards compatible with the existing TLS implementations since it does not require any major changes to the TLS machine-state. In fact, TLS entities can establish a TLS session using the extension defined here. Thus, TLS entities that support that extension can communicate with other TLS entities that do not, and vice versa. The proposed extension inherits most of the security properties currently provided by TLS, in particular the authentication/confidentiality/ integrity and the client’s identity protection [12]. Moreover, it provides third-party auditing capability for TLS transactions without bringing any change to the applications on either side. This is very useful to resolve all kinds of disputes that may arise between hosts or users and to help legal third parties to have control on some of their clients’ behaviors and to know who is doing what at a given time. The proposed extension provides an end-to-end secure channel in a way that only the authenticated hosts have the encrypted messages in clear text. The intermediate, the sender and the destination hosts can use smartcards to securely store the TLS security parameters, as described in [11]. The performance cost to the hosts is essentially equivalent to an ordinary TLS session. Using the proposed extension, the source host will execute only one extra RSA asymmetric encryption with comparison to an ordinary TLS session. However, the intermediate hosts will not decrypt and then encrypt the received application data as it is the case when an ordinary TLS session is established between each two neighbors. Hosts implementing the proposed extension will decrypt the application data for a specific goal (e.g., auditing) but will not encrypt it again since it is already encrypted using the same key- by the host that generated the data. To formally validate our proposed extension, we use a model checking tool called Hermes [5, 6]. Hermes computes an invariant of the intruder knowledge to check whether the defined secrets within a protocol may be revealed or not. The result is obtained without any restriction on the number of parallel sessions, the number of participants, or the size of exchanged messages. We illustrate the Mesh network scenario as a negotiation between three Principals A, B and C that represent the source, the intermediate, and the destination hosts, respectively. Our goal is to establish a TLS session between A and B and to generate a session secret key (Ka) that will be securely transmitted to C. We can divide the protocol specification described above into five parts. In the first part (Fig.3, line 1-10), Principals and variables (called algo and key) are explicitly declared. It also contains the definition of two constructors, PK and SK that represent respectively the public and private key of principals. The X.509 certificates of A, B and C concatenate the identity and the public key of each principal under a signature. The signature is done using the private key SK(CA)
of a trusted certificate Authority (CA). The second part (11-17) specifies the initial knowledge of each principal. It indicates also that some variables could be defined as public values under the ‘everybody knows’ syntax. In the third part (18-31) comes a sequence of messages that are exchanged between Principals. A message in the sequence is expressed in the form A B: M, meaning that entity A sends the message M to entity B. Typically; cryptographic algorithms with special representation are required to construct the messages that are exchanged. For example, {M}_SK(H) means that the message M is signed with the private Key of host H but {M}_K means that M is encrypted with the secret key K. Our protocol is represented with 12 steps (step 1 to 12) providing protections against replay attacks, message authentication, TLS session negotiation and dual entity authentication. The first step represents the distribution of certificate. In the first three messages, the entities A, B and C negotiate their support of our extension. C presents to B its X.509 certificates (certC) and the delegated attribute certificate (Acert). B presents to A its X.509 certificates (certB), the certificate of its neighbor (certC) and the delegated attribute certificate (Acert). Then, A generates the pre_maste_secret (Ka) and separately encrypts it with B and C’s public keys. At this point, the three entities can set a TLS session between them. Now, A presents its identity to B by sending its certificate with a signature on all exchanged data. B forwards the message to C. If C accepts this authentication method, it encrypts the message accept using the negotiated encryption key and sends the encrypted value to B which in its turn forwards it to A. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
A, B,C,CA: principal alg : asym_algo ext: extension basetype key Ka: key keypair^alg SK, PK (principal) shr (principal,principal) : number secret alias certA = { CA, A, PK(A) }_SK(CA)^alg alias certB = { CA, B, PK(B) }_SK(CA)^alg alias certC = { CA, C, PK(C) }_SK(CA)^alg alias Acert = {C,B}_SK(C)^alg // Attribute certificate everybody knows alg A knows A, B, CA, SK(A), PK(A), PK(CA), certA B knows A, B, C, CA, SK(B), PK(A), PK(B), PK(C), PK(CA), certB, certC, certA, Acert C knows B, C, CA, SK(C), PK(C), PK(B), PK(CA), certC, certB, Acert, CA knows CA, PK(CA), SK(CA), B, certB, C, certC, A, certA { 1. CA Æ B: certB 2. CA ÆA: certA 3. A Æ B : extension 4. B Æ C : extension 5. C Æ B : certC, Acert 6. B Æ A : certC, certB, Acert 7. A Æ B : {Ka}_(PK (B))^alg, {Ka}_(PK (C))^alg 8. A Æ B : {Ka}_(PK (C))^alg 9. A Æ B : {A,certA,{A,certA, Acert,B,C}_(SK(A))^alg}_Ka 10. B Æ C : {A,certA,{A,certA, Acert,B,C}_(SK(A))^alg}_Ka 11. C ÆB : {accept}_Ka 12. B ÆA : {accept}_Ka } s. session A=A, B=B, C=C, CA=CA assume secret (SK(B)@s.B), secret (SK(A)@s.A), secret (SK(C)@s.C), secret (SK(CA)@s.CA) Fig. 3. The security specification of our extension in Hermes.
2504
The fourth part (32) considers an unbounded number of sessions in parallel, and the final part (33-35) provides the secrecy hypothesis that is exploited in the Hermes’s reasoning [5]. It defines keys which are unknown to the intruder and which can be used to safely encrypt messages. “secret(
[email protected])” means that the key K in session s should be treated as a secret from H’s point of view. Using the Online Hermes’s tool [5], our specification was correctly compiled and verified regarding secrecy properties. As output, Hermes provides the sequence of rules leading to each new secret or bad pattern. The following table summarizes the result obtained for our protocol. In this table, “GoodPatterns” means that all messages encrypted with one of the three secrets (Ka, shr, and SK) can be securely exchanged. No attack was identified with “BadPatterns”.
[10] P. Adusumilli, et. al., “DGKD: Distributed Group Key Distribution with Authentication Capability”, Proceedings of the 2005 IEEE Workshop on Information Assurance and Security United States Military Academy, West Point, NY, 2005. [11] P. Urien, M. Badra, and M. Dandjinou, “EAP-TLS smartcards, from dream to reality”, Proc. 4th IEEE Workshop on Applications and Services in Wireless Networks, Boston, Massachusetts, USA, 2004. [12] Badra M, Urien P. “Adding identity protection to EAP-TLS smart cards”, Proceedings of Wireless Communications and Networking Conference, WCNC 2007, Hong Kong, China, 2007.
VII. CONCLUSION Nowadays, with the distributed applications and the presence of different actors in the domain of multimedia and audio-visual, there is a great demand to provide security mechanism to protect exchanges, required by an application, between multiple entities that can belong to the same network or different networks. The existing security protocols are not suitable as they cannot offer a flexible and extensible security solution that answers these application’s needs. In this paper, we extend TLS to support different types of authentications and to share a single secure session between several applications or various network nodes. The proposed extension provides third-party auditing capability for TLS transactions without bringing any change to the applications on either side. Currently, an experimental implementation of that extension using OpenSSL is in progress. ACKNOWLEDGMENT This research has received Research Project Grant Funding from the Research Council of the Sultanate of Oman Research Grant Agreement No [ORG DU ICT 10 003]. REFERENCES [1] [2] [3] [4] [5] [6]
[7] [8]
[9]
T. Dierks and C. Allen, “The TLS Protocol Version 1.2”, IETF, RFC 5246, August 2008. P. Urien, “TLS Tripartite Diffie-Hellman Key Exchange”, IETF draft (work in progress), July 2010. B. Aboba and D. Simon, “PPP EAP TLS Authentication Protocol”, IETF, RFC 2716, October 1999. C. Kaufman, “Internet Key Exchange (IKEv2) Protocol”, IETF, RFC4306, December 2005. Hermes, available at: w-verimag.imag.fr/~Liana.Bozga/eva/hermes.php L. Bozga, Y. Lakhnech, and M. Périn, “HERMES: An automatic tool for verification of secrecy in security protocols,” In Warren A. Hunt Jr. and Fabio Somenzi, editors, Computer Aided Verification, 15th International Conference, CAV 2003, Proceedings, volume 2725 of Lecture Notes in Computer Science. Springer, 2003. L. Bozga, et al., “L’outil de vérification HERMES,” Technical Report EVA-6-v1, Verimag, Grenoble, France, May 2002. Y. Song, V. Leung, K. Bznosov, “Supporting End-to-End security across proxies with multiple channel SSL”, Proceedings of IFIP World Computer Conference (WCC’2004), Toulouse, France. G. Kambourakis, et al., “Using SSL/TLS in authentication and key agreement procedures of future mobile networks”, 4th International Workshop on Mobile and Wireless Communications Network, 2002.
2505
