Overhead of Using Secure Wireless
Content
F. Almenares et al.: Overhead of using Secure Wireless Communications in Mobile Computing
335
Overhead of using Secure Wireless Communications in Mobile Computing
Florina Almenares, Patricia Arias, Jr., Andrés Marín, Daniel Díaz-Sánchez, and Rosa Sánchez, Jr., Member, IEEE
Abstract — Secure wireless communications are fundamental in any interaction in order to avoid security and privacy breaches, especially from mobile devices. The use of this kind of communications is far more frequent and the number of users increases day after day. This paper shows and analyzes the support, performance and consumption of cryptographic algorithms and cipher suites in terms of time and energy when secure communications (i.e., using SSL) are established according to different security levels. This study has been performed in distinct operating systems, and using different browsers and libraries1. Index Terms — Secure wireless communications, SSL/TLS, Handheld devices, Energy and time performance.
I. INTRODUCTION Security of communications is a fundamental issue when two entities interact, in order to prevent breaches about security and privacy, such as eavesdropping, interceptions, manipulations or whatever other attacks. These concerns become even more sensitive in wireless communications through handheld devices (e.g., smart phones, tablets, consoles, netbooks, etc.). Wireless communications increase day after day, because of people are far more dependent on this technology than before (see Fig. 1). The figure depicts the upward trend of mobile phones as devices to access to Internet, up to the point of almost duplicating in 2015 the number of the users existing in 2011worldwide according to the user projection. In 2013 the number of users would become comparable. Nowadays, more than two thirds, i.e., 69%, of all Internet users surveyed access with mobile phone every day, according to a study of consumers in Europe, Latin America, and South Africa [2]. The consumers use multiple devices to connect to the Web: smart phones 61%, netbooks 37%, and tablets 22%. This reflects that they use their handheld devices in all spheres of their life (e.g., social, personal, business, etc.).
1 This work was supported in part by the State of Madrid (Spain) under the Spanish Ministry of Science and Innovation under the project CONSEQUENCE (TEC2010-20572-C02-01). Florina Almenares is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Patricia Arias, Jr., is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Andrés Marín is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Daniel Díaz-Sánchez is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Rosa Sánchez, Jr., was with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]).
This is possible because handheld devices are more and more powerful allowing to do most things people do on a desktop. Due to the mobility, these devices are more and more interconnected, participating in diverse networks or collaborative services, running corporate applications, and generating constant activity. Nevertheless, mobile device security follows being an open problem, because they are exposed to suffer same attacks than on desktop with a less security support and new challenges provided by the environment. The support for secure communications -in handheld devicesconsists only of some protocols at the application level based on Transport Layer Security (TLS) [3] or Secure Sockets Layer (SSL), such as HTTPS [4] for browsing Web, IMAPS (Internet Message Access Protocol over SSL) [5] for receiving emails, etc., currently. For this reason, the cost of using secure communications to the application level with X.509 certificates has been exhaustively studied. It takes into account that TLS/SSL requires underlying cryptographic algorithms to key exchange or agreement, cipher, and authentication. Thus, the main objectives of such study have been to determine: 1) security level provided by symmetric (e.g., DES, AES, etc.), and asymmetric (e.g., RSA, DSA, and Elliptic Curve Cryptography) algorithms together with hash functions that are supported on handheld devices, 2) efficiency of each algorithm, including ciphering, signing, and verification due to the importance in the transmission of encrypted data and integrity, and 3) overhead added by HTTPS communications in different web browsers by comparing data transfers using different cipher suites.
Fig. 1. Upward evolution about access to Internet from handheld devices, becoming greater than desktop Internet users [1]. The graph depicts Global Mobile vs. Desktop Internet User Projection from 2007 to 2015: How fast is mobile internet growing?
Contributed Paper Manuscript received 04/01/13 Current version published 06/12/13 Electronic version published 06/12/13.
0098 3063/13/$20.00 © 2013 IEEE
336
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013
Two different operating systems have been used: Linux and non-Linux based OS. Both native and non-native (i.e., OpenSSL-based and Java) libraries in the non-Linux based system have been compared. Likewise, native browser based on Webkit and commercial browsers have been used to compare measurements, because the support and performance is different. The measurements have been taken in terms of time and energy consumption, because energy is another very important factor for handheld devices, apart from response time. Long battery life duration is still a huge challenge in wireless devices; therefore, several works propose to preserve it [6][7]. There are some studies about performance of security [8][11]. These studies motivate very well the importance of this kind of research. They have been oriented to analyze only the performance of cryptographic algorithms [8], security protocols using OpenSSL library [9] or in embedded systems [10], or energy consumption over different networks [11]. But a study including different ciphers, data sizes, libraries and browsers that are commonly used is not available. Almenares et al have briefly presented a part of this study, including only some global results on HTTPS connections in accordance with different cipher suites [12]. This article shows performance of cryptographic algorithms (i.e., symmetric and asymmetric together with hash functions) recommended in SSL connections to guarantee most security level, and depicts more results about secure connections with different data sizes and operating systems. The rest of this article is organized as follows. Section II contains related work and open challenges. Section III describes the details of the study performed regarding energy consumption and time. Then, Section IV details the results obtained from symmetric algorithms used to encrypt data and asymmetric algorithms together with hash functions to sign and verification in SSL. The results are expressed mainly in terms of time. Likewise, Section IV describes briefly the certificate support. Section V contains the test performed for secure transactions according to different cipher suites and data sizes, in distinct browsers. The results are expressed in terms of energy consumption and compared with the time consumption. Finally, some discussion and conclusions are given in Section VI. II. RELATED WORK AND CHALLENGES There are few studies oriented to analyze the performance of cryptographic algorithms [8] and security protocols [9][11]. Rifà-Pous et al [8] is a recent work, which is focused on cryptographic algorithms and hash functions, so they do not include the communication cost. The results are equivalent to the measurements showed in this paper, although they use a lower processor and therefore the values change. They present the amount of overhead that security algorithms can introduce in a system, and highlight the consumption of running cryptographic algorithms when the batteries are low charged is around 16% higher than when they are full.
Potlapally et al [9] use the OpenSSL library to show the energy requirements of SSL execution in battery-powered embedded systems. They take energy consumption measurements using a software tool of GUI-based data acquisition, which runs on a PC and is directly connected to the handheld device through its serial port. The energy measurements are coherent to the measurements showed in this article regards as time for cryptographic algorithms. In addition, they break down the overhead by each stage of the SSL protocol using data from 1KB to 1MB in a detailed and complete way. Finally, they show the performance using four (4) different cipher suites: ECC-3DES-SHA, ECC-AES-MD5, ECC-BLOWFISH-MD5, and RSA-RC5-SHA1. The cipher suites based on ECC (Elliptic Curve Cryptography) were not standardized until May 2006 [13]; therefore, OpenSSL officially included such cipher suites from version 1.0. In this way, the Browser Security Handbook project [14] aims to offer information about security-relevant properties of several mobile browsers. They analyze the security support in different four (4) browsers, of which three ones support cipher suites based on ECC. But, performance measurements have not been carried out yet. Gupta et al [10] analyze the power consumption of an SSL handshake and bulk data transfer using a tiny Web server, called Sizzle, which supports HTTPS. They have implemented this server in a mote-like device. They also compare the performance of underlying cryptographic algorithms using RSA and ECC from server’s perspective. Balasubramanian et al [11] measure the performance regarding energy consumption over different networks (i.e. 3G, GSM, and Wi-Fi), with the aim of optimizing the use of the network interfaces and battery saving. They demonstrate once more the high tail energy overhead incurred by 3G and GSM (Global System for Mobile Communications) connections. The optimization is made modelling the energy consumed by network activity for each technology. So they propose a protocol based on pre-fetching, called TailEnder, which can be used by applications by means of an API (Application Programming Interface). Finally, Vallina-Rodríguez et al [15] present a survey that analyzes different software techniques of energy management in smart phones at six different levels: energy-aware operating systems (OS), efficient resource management, users’ interaction patterns, wireless interfaces and sensors management, and integration mobile devices with cloud computing services. III. ENERGY CONSUMPTION AND TIME ANALYSIS DESCRIPTION An experimental set of tests has been performed, using two smart phones with processor based on RISC (Reduced Instruction Set Computer) architecture with 264MHz, and battery capacity 950mAh, and a handheld device (i.e., Internet Tablet) with also a RISC-based processor with 330MHz, and battery capacity 1500mAh.
F. Almenares et al.: Overhead of using Secure Wireless Communications in Mobile Computing
337
Firstly, the study starts testing cryptographic algorithms (i.e., encryption and signing), and certificate management, because these are the underlying support for secure transactions. For that, cryptographic libraries have been used to develop specific modules that allow testing the functionality required such as is shown in Section IV. Two different suites of algorithms and protocols have been used: native algorithms implemented by proprietary operating systems, Java, and OpenSSL-based library because the trend in operative systems for handheld devices is to use systems based on Linux kernel. Secondly, secure communications, through download of pages from an Apache server, have been tested, using different data sizes and cipher suites. In this set of test, the handheld device acts as a HTTPS client. Two browsers have been used: a) the browser installed by default in operating system, and b) any available browser for the system. The browser installed is based on the industry-leading open source WebKit browser engine. This browser can render any (X)HTML Web page in addition to WML and XHTMLMobile Profile content. The second browser installed is based on Presto engine. On the one hand, the download of a page from the server using different ciphers for establishment of the secure communication has been evaluated. On the other hand, the set of ciphers supported by the server has been tested in order to analyze the efficiency and overhead imposed by different data sizes (i.e., 1KB, 10KB, 100KB, and 1MB), compared with transmission without encoding. The device and server were connected through a Wi-Fi network, which was created only for them. So, the measures obtained are free of external noise. Both time and softwarebased energy consumption measures have been obtained such as is explained in Section V. The energy consumption has been measured by software, through using applications developed for that. In general, these applications running on background takes much less than 1% of CPU load. The application obtains power consumed in watts. This value is an instantaneous value each 1 or 5 seconds. The measured power (or current) consumption of 0.05W (or 14mA) is 0.07W (or 20mA) in reality. Thus, the model provided by the software to measure energy consumption has been used. Such model means how much battery energy (mA) your job has consumed in a determined time (mJoules). It is worth mention that energy measurements have been performed and repeated under equal conditions of battery charge for minimizing the error rate. IV. TIME AND ENERGY AWARE SECURITY This section shows the consumption of cryptographic algorithms -that provide a high or medium security level according to NIST [16]- involved in the cipher suites for SSL communications. Although FORTEZZA security system is also considered by NIST to provide a medium security level, it
has not been included in the comparative, because it is not supported by mobile devices. A. Symmetric algorithms The symmetric algorithms recommended in SSL communications for encryption are AES (Advanced Encryption Standard), DES (Data Encryption Standard), 3DES, IDEA (International Data Encryption Algorithm), RC2 (Rivest Cipher 2), and RC4, in their mode CBC (Cipher-Block Chaining). The performance in CBC mode is very similar to CFB (cipher feedback) and OFB (output feedback), and greater than ECB (electronic codebook). The complete list with key sizes and security level is shown in Table I. The comparative only include the algorithms that are supported by all the different systems analyzed: Linux (or Linux-based), Java Mobile Edition (JME) Security and Trust Services API (JSR 177) [17] and non-Linux based OS, excepting AES because it is the only one algorithm that provides a high security level and it is supported by OpenSSL despite not be included in a concrete version of the library used. Thus, IDEA and RC4 are not showed in the measurements, because IDEA is only supported by OpenSSLbased library, and RC4 is not supported in the non-Linux based OS and JSR 177. Nevertheless, the RC4 performance has been the smallest measure (i.e., 23.51ms) in the case of Linux OS.
TABLE I
SYMMETRIC ALGORITHMS FOR ENCRYPTION IN SSLV3
Algorithm AES 3DES DES IDEA RC2 RC4
Key sizes (bits) 256, 192, 128 168 192 128 128 128
Security level High Medium Medium Medium Medium Medium
This table shows the key sizes recommended for each symmetric algorithm and the security level provided by encryption algorithms in accordance with the key length according to NIST [16].
Fig. 2 shows the performance time (in milliseconds) in operations of data encryption. The length of the data used is 10KB to show measurements, but the conclusions are the same for greater data size, 1MB. In this figure, it is possible to see the performance of AES is lesser than (i.e., about 25 milliseconds in native OSs) or similar to other algorithms. In addition, the key size is not relevant, because the performance is very similar, excepting in Java ME. Even, in JME the performance for key size of 192 bits is lesser than 128 bits. AES is quicker, relatively simple to implement and requires little memory. Finally, it worth to mention JME has been the slowest of all the platforms, duplicating, at least, the time in all cases. Regarding 3DES, it is most costly than others in all cases, followed by RC2 in both native operating systems. Then, DES and AES performances are comparable. So the use of AES is favourable in terms of security level and execution performance.
338
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013
Fig. 2. Performance time of each symmetric algorithm using CBC mode in different platforms. The algorithms show the key size. The time is expressed in msec.
Fig. 3. Performance time in seconds of hash functions belonging to the family of cryptographic functions SHA with RSA verification, a key length of 1024, and data size of 100KB.
In regards as energy consumption, the behaviour is the same to the time consumption. 3DES is the most costly, being lesser in OpenSSL-based library than in the non-Linux based operating system; about 71.5mJ facing towards 729mJ respectively. B. Asymmetric Algorithms Asymmetric algorithms include RSA (Rivest, Shamir and Adleman), DSA (Digital Signature Algorithm), and ECDSA (Elliptic Curve Digital Signature Algorithm). In this case the measurements have been taken in sign and verification on Linux, because in non-Linux OS the access to API is restricted and using other libraries is similar. RSA and DSA have been tested with different key sizes: 1024, 2048 and 4096 bits. ECDSA, in turn, has been tested with keys size of 160, 192 and 256 bits. RSA uses different hash functions; in this case, the results showed use SHA and MD5, by being functions more used in SSL, especially SHA. The duration is very similar in both case and even with other hash functions. Even, there can say the behaviour of several hash functions is linear; a meaningful difference is not perceived when data size is small. However, when data volume increases (i.e., from 100KB), then, the difference in time is especially perceived for distinct families of SHA functions, that is, using SHA-2 (i.e., SHA224, SHA256, SHA384, and SHA512). Such as can is depicted in Fig. 3, there is a significant difference among the SHA-2 functions, because the temporal cost (expressed in seconds) becomes increased in a factor of 2.9 for SHA224 and SHA256 and up to a factor of 6 for SHA512 and SHA384 with respect to SHA1, with a key size of 1024 to sign. In verification, the behaviour of SHA family functions is similar, but in this case the maximum factor, that is, between SHA1 and SHA512 is of 3.2 approximately. DSA, in its turn, uses DSS (Digital Signature Standard) as hash function. In Fig. 4, charts (a) and (b) show the time in seconds used for sign and verification in both RSA and DSA, respectively, in accordance with different key sizes. The results show once again that RSA is faster verifying than signing, whereas DSA is faster signing than verifying, especially in the case of small data and keys.
Likewise, for key size of 4096, RSA and DSA increase its performance ratio in a meaningful way. The temporal cost of passing 2048 to 4096 is multiplied by a factor of 7 approximately in the case of sign, and 4 times for the verification in RSA. As long as DSA, the factor is 3 approximately in both cases.
(a) (b) Fig. 4. Performance time of RSA and DSA for sign (a) and verification (b) with different hash functions, according to the key sizes.
This behaviour is kept if both them are compared, RSA is faster verifying than DSA, whereas DSA is faster signing than RSA (see Fig. 5). In the charts (a) and (b), there can be seen DSA is twice faster than RSA to carry out signatures, whereas RSA is sixteen (16) times faster than DSA for verification. One common issue between RSA and DSA lies in the recommendations about key length for providing the same security assurance, bigger than 1024 bits (i.e., 2048) from 2010 by NIST [18], and European ECRYPT II Project [19]. Despite this, the time to generate keys in DSA is huge greater than the time used to generate keys in RSA. Thus, the main disadvantage of DSA is the time used in the key generation as is explained later.
(a) (b) Fig. 5. The difference in the performance time between RSA and DSA respect to sign (a) and verification (b), respectively, on average.
F. Almenares et al.: Overhead of using Secure Wireless Communications in Mobile Computing
339
Finally, ECDSA performance is so similar to DSA. In the same way, it is faster sign than verify, and the time (in seconds) spent is high when data are bigger and keys are longer. The meaningful difference lies in time spent to generate keys such as can be seen in Table II. DSA is the slowest with a relevant magnitude order among the three algorithms. DSA spends, at least, 7 times more than the time used by RSA to generate keys of the same length. ECDSA is the best algorithm in this sense, because of key sizes are smaller and efficient. In all the cases for ECDSA the time is a lot lesser than 1 second.
TABLE II
KEY GENERATION TIME
Algorithm
Key sizes (bits) 1024 2048 4096 512 1024 2048 4096 160 192 256
Time (s) 3.078093214 33.99207942 366.1998620 5.243404385 22.23015594 370.8107643 3353.931850 0.06464195 0.08208847 0.12192440
OS; therefore, it can be concluded JME browsers make calls to the system, using the underlying support offered by the OS. The first conclusions regarding support that can be pulled out from the table are: DSS is the unique protocol for authentication supported by browsers installed in non-Linux OS. Diffie-Hellman (DH) key exchange is only supported by native browsers. For maximum security, RSA or DSA authentication with ephemeral Diffie-Hellman key agreement is recommended (e.g., DHE-RSA-AES256SHA, DHE-DSS-AES128-SHA, etc.), because these cipher suites provide perfect forward secrecy, and can support large keys for long-term confidentiality [16]. A cipher suite using RC2 is only supported by Prestobased browser.
TABLE III
CIPHER SUITES SUPPORTED BY BROWSERS IN MOBILE DEVICES
RSA
Cipher suite ADH-AES256-SHA DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA AES256-SHA ADH-AES128-SHA DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA AES128-SHA ADH-DES-CBC3-SHA ADH-DES-CBC-SHA EXP-ADH-DES-CBC-SHA ADH-RC4-MD5 EXP-ADH-RC4-MD5 EDH-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EDH-DSS-DES-CBC3-SHA EDH-DSS-DES-CBC-SHA EXP-EDH-DSS-DES-CBC-SHA DES-CBC3-SHA DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC2-CBC-MD5 RC4-SHA RC4-MD5 EXP-RC4-MD5 DES-CBC3-MD5 DES-CBC-MD5 EXP-RC2-CBC-MD5 RC2-CBC-MD5 EXP-RC4-MD5 RC4-MD5
Supported browser NB-NL NB-L All NB-NL NB-L All NB-NL, NB-L NB-NL NB-NL NB-NL NB-NL All All NB-NL, PB PB All All NB-NL, PB -
DSA
ECDSA
Time used to generate key pairs in RSA, DSA and ECDSA. The time is expressed in seconds in accordance with the different key sizes.
C. Certificate Management All the platforms support X.509 certificates version 3 [20], with keys from 512 to 4096 bits. It is favourable, because it allows testing a bigger number of cipher suites. Browsers have access to the certificate store, where some certificates from well-known commercial Certification Authorities (CAs) are previously installed. In most cases, the interface to users manage certificates is restricted. The browsers have the control of managing personal certificates when they are required from a server. V. COST OF SECURE COMMUNICATIONS For secure communications, the measurements have been carried out for each of the cipher suites available in the native WebKit-based browser installed in the smart phone and others browsers, and varying the size of the Web page. The first point was to know the support in the different browsers. It is to say that from the 32 cipher suites available in the openSSLv0.98g used for setting up the secure server, only a subset of 13 cipher suites were supported by the native browser in non-Linux OS (NB-NL), 8 cipher suites by the native browser in Linux OS (NB-L), and 9 cipher suites by the non-native Presto-based browser (PB) in the best case. The list detailed is shown in Table III. There can be noted that cipher suites using ECC algorithms are not supported by this version of the OpenSSL. Browsers developed in Java ME are not included because the support is the same than native browsers installed in the
This table shows the support of cipher suites in the different browsers for mobile devices. NB-NL: Native Browser in Non-Linux OS, NB-L: Native Browser in Linux OS, PB: Presto-based Browser, -: None, All: all browsers.
340
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013
In addition, as conclusions about all browsers can be mentioned the following: All browsers support at least a cipher suite using AES cipher with RSA key exchange and authentication; therefore, they are able to provide a high security level. Although could not provide recommended maximum security, because only native browser installed in Linux OS are supporting both DH key exchange and RSA authentication. All browsers support cipher suites using DES, 3DES, or RC4 ciphers with RSA key exchange and authentication; therefore, they are able to provide a medium security level. The energy consumption (in Joules) of these cipher suites according to the data size can be seen in Fig. 6. The time consumption is similar until data of 100KB but with data greater the relation energy versus time is not directly proportional; for instance, energy consumed by RC4-MD5 cipher suite is bigger than energy consumed by DES-CBCSHA cipher suite; however, the time used by DES-CBC-SHA is greater than time used by RC4-MD5.
Fig. 7. Energy consumption (in Joules) in establishing a SSL connection to transfer a Web page with different data sizes between the smart phone’s native browser and a secure server, using a processor with 264MHz.
In addition, in both charts can be observed that both magnitudes increase linearly with the size of the transferred page. The variations between the different cipher suites are more significant for bigger file sizes, especially in regard to energy consumption. With small data size (i.e., up to 100KB) the difference between measurements is inappreciable.
Fig. 6. Energy consumption (in Joules) of a SSL connection by each cipher suite to transfer a Web page with different data sizes between a smart phone’s native browser and a secure server, using a processor with 264MHz.
Fig. 8. Time consumption (in seconds) when establishing a SSL connection to transfer a Web page with different data sizes between the smart phone’s native browser and a secure server, using a processor with 264MHz.
In this way, Fig. 7 and Fig. 8 represent the consumption in terms of energy and time, respectively, for the establishment of a SSL connection according the test bed explained previously in Section III. The measurements in the native browser based on WebKit are only showed, because linear upward trend is the same in all cases. Nevertheless, in the Presto-based browser, the execution time is 30% faster, although it supports lesser ciphers suite. In addition, Presto-based browser does not support SSL client authentication through digital certificates, therefore, this is an important limitation when it comes time to implement security steps. SSL client authentication could be performed using other mechanism with less security level such as login and password, for example.
The correlation between time and energy consumption can be analyzed better in the chart of the Fig. 9. The evolution for a specific case has been analyzed: with the greatest data size, 1MB, because it is possible to better appreciate such correlation. From the graph, there can be observed that algorithm consuming more energy it is not the same algorithm that consumes more time, EXP-EDH-RSA-DES-CBC-SHA. In the case of AES-256 cipher suite is the second one in energy consumption and the fourth one in the time consumption. The cipher suites using RC4 for key exchange are the lightest as regards time, but EXP-DES-CBC-SHA and DES-CBC-SHA are the lightest as regards energy consumption. Thus, there is not a direct general correlation between the performance in time of an algorithm and the associated energy consumption,
F. Almenares et al.: Overhead of using Secure Wireless Communications in Mobile Computing
341
i.e., the slowest cipher suite is not necessary the most expensive in terms of energy. The cost of energy depends on the operations underlying the particular cipher suite and thus evolves differently with time. So from the graph in Fig. 7, Table IV summarizes the energy consumption overhead for the best and worst cipher suites (i.e., the cheapest and the more expensive from the point of view of energy consumption) with respect to the case where no security is applied, using a file size of 1MB. In both cases, the security level provided is medium. The overhead for a high security level is 18% approximately in average (i.e., using cipher suites with AES256 and 128). The cipher suites in Table IV are the ones with lowest and highest energy consumption versus time ratio in Fig. 8, which justifies the overhead results for big data size. The consumption without cipher suite represents HTTP connections with Wi-Fi; therefore, there is no overhead in this case.
be seen that the overhead is between 5% and 17% for the same data size (i.e., 1MB) with a faster processor; meanwhile the overhead is between 7% and 71% for very small data size, 1KB. In this case, the equivalent cipher suites without export encryption algorithms, EDH-RSA-DES-CBC-SHA, is also the most costly cipher suite, and DES-CBC-SHA is the lightest one.
Fig. 10. The overhead added by cipher suites for SSL connections in Linux OS. The overhead is showed for each cipher suite supported according to different data sizes, using a processor with 330MHz.
For a high security level, the AES overhead is 9% in average for file size of 1MB and 21% for file size of 1KB. This last overhead is not meaningful with respect to the other cipher suites.
Fig. 9. Energy consumption (in Joules) versus time consumption (in seconds) in establishing a SSL connection to transfer a Web page with 1MB of size, using a processor with 264MHz.
VI. CONCLUSION AND FUTURE WORK In this paper results obtained from a study about support and efficiency of secure connections have been showed, i.e., using HTTP over TLS, and cryptographic algorithms associated with this. According to the results presented there can be concluded that although native browsers do not always provide the better performance, they provide more security support to applications using HTTPS. They are prepared to offer the maximum security level according to the NIST recommendations, using RSA or DSA authentication with ephemeral DH key agreement with AES as encryption algorithm. Besides, such browsers do not send all the user’s certificates stored in the device when client-side authentication is required. On the other side, Presto-based browser supports lesser ciphers in most cases, and allows sending all users’ certificates. Regarding overhead added by the security algorithms, this reaches about 17% in the worst case for big data size (i.e., 1MB), whereas it can reaches a 71% in the worst case for small data size (i.e., 1KB), taking as reference the faster processor. In the case of requiring a high security level, then, the overhead added would be 9% that could be considered low in return for benefits obtained with big data size, or 21% for
As mentioned previously, the overhead presented in the table is relative, it would be simply in case of 1MB data size, but for small data size the overhead could be even of 71%.
TABLE IV
ENERGY OVERHEAD FOR THE BEST AND WORST CIPHER SUITES
Cipher suite No cipher suite EXP-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA
Energy Consumption
Overhead
37,2205909 J 39,9790813 J 46,1130985 J
0% 7,41% 23,89%
The overhead added by cipher suites in SSL connections. The table shows the best and the worst case for file size of 1 MB, using a processor with 264MHz.
Fig. 10 shows the overhead added by cipher suites according to different data sizes. In this case, the measurements have been performed in a mobile device with the processor with 330MHz. Thus, the number of cipher suites is lesser, because the support is different. Nevertheless, the results are equivalent to the results showed previously. In the chart of Fig. 10, it can
342
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013 [16] C. Chernick, C. Edington, J. Matthew and R. Rosenthal (eds.), “Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations”, NIST Special Publication Rep. 800-52, 2005. [17] Java Community Process (JCP), “JSR 177: Security and Trust Services API for J2ME,” Aug. 2007. [18] E. Barker, W. Barker, W. Burr, W. Polk, M. Smid, “Recommendation for Key Management, Part 1: General”, NIST Tech. Rep., SP 800-57, Jul. 2012. [19] N. Smart (ed.), “Yearly Report on Algorithms and Key sizes (20112012),” Project Tech. Rep., D.SPA.20 Rev.1.0, ICT-2007-216676 ECRYPT II, Sep. 2012. [20] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” IETF Tech. Rep., RFC 5280, May 2008. BIOGRAPHIES Florina Almenárez Mendoza, (M’07) received her Ph.D. degree from the University Carlos III of Madrid (Spain) in 2006 and is currently an associate professor at UC3M. She received an award-winning as Magna CumLaude in her Computer Engineering degree. Her research interests include trust management, identity federation, security in ubiquitous computing, and SIM-based applications. She leads the research activities of the PerLab group in advanced trust models, security architectures for open and dynamic spaces, and identity management. Patricia Arias Cabarcos, received her Telecom. Eng. degree from Univ. Carlos III of Madrid in 2008 and she obtained the MSc degree in Telematics in 2009. Currently, she is pursuing a PhD at the Department of Telematics Engineering in the Univ. Carlos III of Madrid, working within the Pervasive Computing research group. Her research focuses on the problem of identity management in open and dynamic environments, with special attention to risk analysis and the underlying trust models. Andrés Marín López, (M’07) received a Telecom. Eng. degree and PhD from the Technical Univ. of Madrid in 1992 and 1996 respectively. He lectures in Computer Networks and Ubiquitous Computing in the Univ. Carlos III de Madrid, as an associate professor. His research interests include ubiquitous computing: limited devices, trust, security services, and security in NGN. Daniel Díaz-Sánchez, (M’07) received a Telecom. Eng. degree from Univ. Carlos III de Madrid in 2002. He graduated as Master Telematic Engineering (2004) and obtained his PhD (2008) from Univ. Carlos III of Madrid. He works as researcher and teacher at Universidad Carlos III. His research topic is distributed authentication, authorization and content protection activities. Rosa Sánchez Guerrero, received a Telecom. Eng. degree from Univ. Carlos III de Madrid in 2009 and she obtained the MSc degree in Telematics in 2011. Currently, she works as researcher at the Department of Telematics Eng. in the Univ. Carlos III of Madrid, working within the Pervasive Computing research group. Her research topics include the problem of identity management, security and privacy in healthcare.
small data size, whose consideration would be made in function of data being exchanged. Other testbed including cipher suites based on ECC are being performed, because this support was not extended, but it is currently greater each time. ACKNOWLEDGMENT Authors would like to thank to the students David Maroto, Rocío Blanco López, and Elma de la Fuente for their collaboration in performing measurements for different operating systems. REFERENCES
[1] [2] [3] [4] [5] [6] H. Richmond, “The Growth of Mobile Marketing and Tagging,” Microsoft Tag Rep., Mar. 2011. Accenture Consulting, “Mobile Web Watch Survey 2012: Mobile Internet --Spawning New Growth Opportunities in the Convergence Area,” Rep., Jul. 2012. T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol, Version 1.2,” IETF Tech. Rep., RFC 5246, Aug. 2008. E. Rescorla, “HTTP over TLS,” IETF Tech. Rep., RFC 2818, May 2000. C. Newman, “Using TLS with IMAP, POP3, and ACAP,” IETF Tech. Rep., RFC 2595, Jun. 1999. L. Shilong, H. Xi, C. Li, Z. Ze, and L. Dong, “Design and implementation of an ASIC-based sensor device for WSN applications,” IEEE Trans. Consumer Electron., vol. 55, no. 4, pp. 1959-1967, Nov. 2009, doi: 10.1109/TCE.2009.5373756. K. Mooseop, J. Hongil, K. Youngsae, P. Jiman, and P. Youngsoo, “Design and implementation of mobile trusted module for trusted mobile computing,” IEEE Trans. Consumer Electron., vol. 56, no. 1, pp. 134-140, Feb. 2010, doi: 10.1109/TCE.2010.5439136. H. Rifà-Pous, and J. Herrera-Joancomartí, “Computational and Energy Costs of Cryptographic Algorithms on Handheld Devices,” Future Internet, vol. 3, no. 4, pp. 31-48, Feb. 2011. N.R. Potlapally, S. Ravi, A. Raghunathan and N.K. Jha, “A Study of the Energy Consumption Characteristics of Cryptographic Algorithms and Security Protocols”, IEEE Trans. on Mobile Comput., vol. 5, no. 2, pp. 128-143, Feb. 2006. V. Gupta and M. Wurm, “The Energy Cost of SSL in Deeply Embedded Systems,” Sun Tech. Rep., 2008. N. Balasubramanian, A. Balasubramanian, and A. Venkataramani, “Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Applications,” in Proc. of the 9th ACM SIGCOMM Conf. on Internet Measurement (IMC '09), ACM Press, New York, NY, USA, pp. 280-293, Nov. 2009. F. Almenares, P. Arias, A. Marín, D. Díaz-Sánchez, and R. Sánchez, “How Costly are Secure Transactions on Handheld Devices?,” in Proc. of the IEEE Conf. on Consumer Electronics (ICCE), Jan. 2013. S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”, IETF Tech. Rep., RFC 4492, Network WG, May 2006. Cloud and Web Service Security Lab (ClaWSLab), “Browser Security Handbook”, Research Project Rep., 2011. N. Vallina-Rodríguez and J. Crowcroft, “Energy Management Techniques in Modern Mobile Handsets”, in IEEE Commun. Surveys & Tutorials, vol. 15, no. 1, Jan-Mar 2013.
[7]
[8] [9]
[10] [11]
[12]
[13]
[14] [15]
335
Overhead of using Secure Wireless Communications in Mobile Computing
Florina Almenares, Patricia Arias, Jr., Andrés Marín, Daniel Díaz-Sánchez, and Rosa Sánchez, Jr., Member, IEEE
Abstract — Secure wireless communications are fundamental in any interaction in order to avoid security and privacy breaches, especially from mobile devices. The use of this kind of communications is far more frequent and the number of users increases day after day. This paper shows and analyzes the support, performance and consumption of cryptographic algorithms and cipher suites in terms of time and energy when secure communications (i.e., using SSL) are established according to different security levels. This study has been performed in distinct operating systems, and using different browsers and libraries1. Index Terms — Secure wireless communications, SSL/TLS, Handheld devices, Energy and time performance.
I. INTRODUCTION Security of communications is a fundamental issue when two entities interact, in order to prevent breaches about security and privacy, such as eavesdropping, interceptions, manipulations or whatever other attacks. These concerns become even more sensitive in wireless communications through handheld devices (e.g., smart phones, tablets, consoles, netbooks, etc.). Wireless communications increase day after day, because of people are far more dependent on this technology than before (see Fig. 1). The figure depicts the upward trend of mobile phones as devices to access to Internet, up to the point of almost duplicating in 2015 the number of the users existing in 2011worldwide according to the user projection. In 2013 the number of users would become comparable. Nowadays, more than two thirds, i.e., 69%, of all Internet users surveyed access with mobile phone every day, according to a study of consumers in Europe, Latin America, and South Africa [2]. The consumers use multiple devices to connect to the Web: smart phones 61%, netbooks 37%, and tablets 22%. This reflects that they use their handheld devices in all spheres of their life (e.g., social, personal, business, etc.).
1 This work was supported in part by the State of Madrid (Spain) under the Spanish Ministry of Science and Innovation under the project CONSEQUENCE (TEC2010-20572-C02-01). Florina Almenares is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Patricia Arias, Jr., is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Andrés Marín is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Daniel Díaz-Sánchez is with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]). Rosa Sánchez, Jr., was with the Telematic Eng. Department, Carlos III University, 28911, Leganés, Madrid, SPAIN (e-mail: [email protected]).
This is possible because handheld devices are more and more powerful allowing to do most things people do on a desktop. Due to the mobility, these devices are more and more interconnected, participating in diverse networks or collaborative services, running corporate applications, and generating constant activity. Nevertheless, mobile device security follows being an open problem, because they are exposed to suffer same attacks than on desktop with a less security support and new challenges provided by the environment. The support for secure communications -in handheld devicesconsists only of some protocols at the application level based on Transport Layer Security (TLS) [3] or Secure Sockets Layer (SSL), such as HTTPS [4] for browsing Web, IMAPS (Internet Message Access Protocol over SSL) [5] for receiving emails, etc., currently. For this reason, the cost of using secure communications to the application level with X.509 certificates has been exhaustively studied. It takes into account that TLS/SSL requires underlying cryptographic algorithms to key exchange or agreement, cipher, and authentication. Thus, the main objectives of such study have been to determine: 1) security level provided by symmetric (e.g., DES, AES, etc.), and asymmetric (e.g., RSA, DSA, and Elliptic Curve Cryptography) algorithms together with hash functions that are supported on handheld devices, 2) efficiency of each algorithm, including ciphering, signing, and verification due to the importance in the transmission of encrypted data and integrity, and 3) overhead added by HTTPS communications in different web browsers by comparing data transfers using different cipher suites.
Fig. 1. Upward evolution about access to Internet from handheld devices, becoming greater than desktop Internet users [1]. The graph depicts Global Mobile vs. Desktop Internet User Projection from 2007 to 2015: How fast is mobile internet growing?
Contributed Paper Manuscript received 04/01/13 Current version published 06/12/13 Electronic version published 06/12/13.
0098 3063/13/$20.00 © 2013 IEEE
336
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013
Two different operating systems have been used: Linux and non-Linux based OS. Both native and non-native (i.e., OpenSSL-based and Java) libraries in the non-Linux based system have been compared. Likewise, native browser based on Webkit and commercial browsers have been used to compare measurements, because the support and performance is different. The measurements have been taken in terms of time and energy consumption, because energy is another very important factor for handheld devices, apart from response time. Long battery life duration is still a huge challenge in wireless devices; therefore, several works propose to preserve it [6][7]. There are some studies about performance of security [8][11]. These studies motivate very well the importance of this kind of research. They have been oriented to analyze only the performance of cryptographic algorithms [8], security protocols using OpenSSL library [9] or in embedded systems [10], or energy consumption over different networks [11]. But a study including different ciphers, data sizes, libraries and browsers that are commonly used is not available. Almenares et al have briefly presented a part of this study, including only some global results on HTTPS connections in accordance with different cipher suites [12]. This article shows performance of cryptographic algorithms (i.e., symmetric and asymmetric together with hash functions) recommended in SSL connections to guarantee most security level, and depicts more results about secure connections with different data sizes and operating systems. The rest of this article is organized as follows. Section II contains related work and open challenges. Section III describes the details of the study performed regarding energy consumption and time. Then, Section IV details the results obtained from symmetric algorithms used to encrypt data and asymmetric algorithms together with hash functions to sign and verification in SSL. The results are expressed mainly in terms of time. Likewise, Section IV describes briefly the certificate support. Section V contains the test performed for secure transactions according to different cipher suites and data sizes, in distinct browsers. The results are expressed in terms of energy consumption and compared with the time consumption. Finally, some discussion and conclusions are given in Section VI. II. RELATED WORK AND CHALLENGES There are few studies oriented to analyze the performance of cryptographic algorithms [8] and security protocols [9][11]. Rifà-Pous et al [8] is a recent work, which is focused on cryptographic algorithms and hash functions, so they do not include the communication cost. The results are equivalent to the measurements showed in this paper, although they use a lower processor and therefore the values change. They present the amount of overhead that security algorithms can introduce in a system, and highlight the consumption of running cryptographic algorithms when the batteries are low charged is around 16% higher than when they are full.
Potlapally et al [9] use the OpenSSL library to show the energy requirements of SSL execution in battery-powered embedded systems. They take energy consumption measurements using a software tool of GUI-based data acquisition, which runs on a PC and is directly connected to the handheld device through its serial port. The energy measurements are coherent to the measurements showed in this article regards as time for cryptographic algorithms. In addition, they break down the overhead by each stage of the SSL protocol using data from 1KB to 1MB in a detailed and complete way. Finally, they show the performance using four (4) different cipher suites: ECC-3DES-SHA, ECC-AES-MD5, ECC-BLOWFISH-MD5, and RSA-RC5-SHA1. The cipher suites based on ECC (Elliptic Curve Cryptography) were not standardized until May 2006 [13]; therefore, OpenSSL officially included such cipher suites from version 1.0. In this way, the Browser Security Handbook project [14] aims to offer information about security-relevant properties of several mobile browsers. They analyze the security support in different four (4) browsers, of which three ones support cipher suites based on ECC. But, performance measurements have not been carried out yet. Gupta et al [10] analyze the power consumption of an SSL handshake and bulk data transfer using a tiny Web server, called Sizzle, which supports HTTPS. They have implemented this server in a mote-like device. They also compare the performance of underlying cryptographic algorithms using RSA and ECC from server’s perspective. Balasubramanian et al [11] measure the performance regarding energy consumption over different networks (i.e. 3G, GSM, and Wi-Fi), with the aim of optimizing the use of the network interfaces and battery saving. They demonstrate once more the high tail energy overhead incurred by 3G and GSM (Global System for Mobile Communications) connections. The optimization is made modelling the energy consumed by network activity for each technology. So they propose a protocol based on pre-fetching, called TailEnder, which can be used by applications by means of an API (Application Programming Interface). Finally, Vallina-Rodríguez et al [15] present a survey that analyzes different software techniques of energy management in smart phones at six different levels: energy-aware operating systems (OS), efficient resource management, users’ interaction patterns, wireless interfaces and sensors management, and integration mobile devices with cloud computing services. III. ENERGY CONSUMPTION AND TIME ANALYSIS DESCRIPTION An experimental set of tests has been performed, using two smart phones with processor based on RISC (Reduced Instruction Set Computer) architecture with 264MHz, and battery capacity 950mAh, and a handheld device (i.e., Internet Tablet) with also a RISC-based processor with 330MHz, and battery capacity 1500mAh.
F. Almenares et al.: Overhead of using Secure Wireless Communications in Mobile Computing
337
Firstly, the study starts testing cryptographic algorithms (i.e., encryption and signing), and certificate management, because these are the underlying support for secure transactions. For that, cryptographic libraries have been used to develop specific modules that allow testing the functionality required such as is shown in Section IV. Two different suites of algorithms and protocols have been used: native algorithms implemented by proprietary operating systems, Java, and OpenSSL-based library because the trend in operative systems for handheld devices is to use systems based on Linux kernel. Secondly, secure communications, through download of pages from an Apache server, have been tested, using different data sizes and cipher suites. In this set of test, the handheld device acts as a HTTPS client. Two browsers have been used: a) the browser installed by default in operating system, and b) any available browser for the system. The browser installed is based on the industry-leading open source WebKit browser engine. This browser can render any (X)HTML Web page in addition to WML and XHTMLMobile Profile content. The second browser installed is based on Presto engine. On the one hand, the download of a page from the server using different ciphers for establishment of the secure communication has been evaluated. On the other hand, the set of ciphers supported by the server has been tested in order to analyze the efficiency and overhead imposed by different data sizes (i.e., 1KB, 10KB, 100KB, and 1MB), compared with transmission without encoding. The device and server were connected through a Wi-Fi network, which was created only for them. So, the measures obtained are free of external noise. Both time and softwarebased energy consumption measures have been obtained such as is explained in Section V. The energy consumption has been measured by software, through using applications developed for that. In general, these applications running on background takes much less than 1% of CPU load. The application obtains power consumed in watts. This value is an instantaneous value each 1 or 5 seconds. The measured power (or current) consumption of 0.05W (or 14mA) is 0.07W (or 20mA) in reality. Thus, the model provided by the software to measure energy consumption has been used. Such model means how much battery energy (mA) your job has consumed in a determined time (mJoules). It is worth mention that energy measurements have been performed and repeated under equal conditions of battery charge for minimizing the error rate. IV. TIME AND ENERGY AWARE SECURITY This section shows the consumption of cryptographic algorithms -that provide a high or medium security level according to NIST [16]- involved in the cipher suites for SSL communications. Although FORTEZZA security system is also considered by NIST to provide a medium security level, it
has not been included in the comparative, because it is not supported by mobile devices. A. Symmetric algorithms The symmetric algorithms recommended in SSL communications for encryption are AES (Advanced Encryption Standard), DES (Data Encryption Standard), 3DES, IDEA (International Data Encryption Algorithm), RC2 (Rivest Cipher 2), and RC4, in their mode CBC (Cipher-Block Chaining). The performance in CBC mode is very similar to CFB (cipher feedback) and OFB (output feedback), and greater than ECB (electronic codebook). The complete list with key sizes and security level is shown in Table I. The comparative only include the algorithms that are supported by all the different systems analyzed: Linux (or Linux-based), Java Mobile Edition (JME) Security and Trust Services API (JSR 177) [17] and non-Linux based OS, excepting AES because it is the only one algorithm that provides a high security level and it is supported by OpenSSL despite not be included in a concrete version of the library used. Thus, IDEA and RC4 are not showed in the measurements, because IDEA is only supported by OpenSSLbased library, and RC4 is not supported in the non-Linux based OS and JSR 177. Nevertheless, the RC4 performance has been the smallest measure (i.e., 23.51ms) in the case of Linux OS.
TABLE I
SYMMETRIC ALGORITHMS FOR ENCRYPTION IN SSLV3
Algorithm AES 3DES DES IDEA RC2 RC4
Key sizes (bits) 256, 192, 128 168 192 128 128 128
Security level High Medium Medium Medium Medium Medium
This table shows the key sizes recommended for each symmetric algorithm and the security level provided by encryption algorithms in accordance with the key length according to NIST [16].
Fig. 2 shows the performance time (in milliseconds) in operations of data encryption. The length of the data used is 10KB to show measurements, but the conclusions are the same for greater data size, 1MB. In this figure, it is possible to see the performance of AES is lesser than (i.e., about 25 milliseconds in native OSs) or similar to other algorithms. In addition, the key size is not relevant, because the performance is very similar, excepting in Java ME. Even, in JME the performance for key size of 192 bits is lesser than 128 bits. AES is quicker, relatively simple to implement and requires little memory. Finally, it worth to mention JME has been the slowest of all the platforms, duplicating, at least, the time in all cases. Regarding 3DES, it is most costly than others in all cases, followed by RC2 in both native operating systems. Then, DES and AES performances are comparable. So the use of AES is favourable in terms of security level and execution performance.
338
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013
Fig. 2. Performance time of each symmetric algorithm using CBC mode in different platforms. The algorithms show the key size. The time is expressed in msec.
Fig. 3. Performance time in seconds of hash functions belonging to the family of cryptographic functions SHA with RSA verification, a key length of 1024, and data size of 100KB.
In regards as energy consumption, the behaviour is the same to the time consumption. 3DES is the most costly, being lesser in OpenSSL-based library than in the non-Linux based operating system; about 71.5mJ facing towards 729mJ respectively. B. Asymmetric Algorithms Asymmetric algorithms include RSA (Rivest, Shamir and Adleman), DSA (Digital Signature Algorithm), and ECDSA (Elliptic Curve Digital Signature Algorithm). In this case the measurements have been taken in sign and verification on Linux, because in non-Linux OS the access to API is restricted and using other libraries is similar. RSA and DSA have been tested with different key sizes: 1024, 2048 and 4096 bits. ECDSA, in turn, has been tested with keys size of 160, 192 and 256 bits. RSA uses different hash functions; in this case, the results showed use SHA and MD5, by being functions more used in SSL, especially SHA. The duration is very similar in both case and even with other hash functions. Even, there can say the behaviour of several hash functions is linear; a meaningful difference is not perceived when data size is small. However, when data volume increases (i.e., from 100KB), then, the difference in time is especially perceived for distinct families of SHA functions, that is, using SHA-2 (i.e., SHA224, SHA256, SHA384, and SHA512). Such as can is depicted in Fig. 3, there is a significant difference among the SHA-2 functions, because the temporal cost (expressed in seconds) becomes increased in a factor of 2.9 for SHA224 and SHA256 and up to a factor of 6 for SHA512 and SHA384 with respect to SHA1, with a key size of 1024 to sign. In verification, the behaviour of SHA family functions is similar, but in this case the maximum factor, that is, between SHA1 and SHA512 is of 3.2 approximately. DSA, in its turn, uses DSS (Digital Signature Standard) as hash function. In Fig. 4, charts (a) and (b) show the time in seconds used for sign and verification in both RSA and DSA, respectively, in accordance with different key sizes. The results show once again that RSA is faster verifying than signing, whereas DSA is faster signing than verifying, especially in the case of small data and keys.
Likewise, for key size of 4096, RSA and DSA increase its performance ratio in a meaningful way. The temporal cost of passing 2048 to 4096 is multiplied by a factor of 7 approximately in the case of sign, and 4 times for the verification in RSA. As long as DSA, the factor is 3 approximately in both cases.
(a) (b) Fig. 4. Performance time of RSA and DSA for sign (a) and verification (b) with different hash functions, according to the key sizes.
This behaviour is kept if both them are compared, RSA is faster verifying than DSA, whereas DSA is faster signing than RSA (see Fig. 5). In the charts (a) and (b), there can be seen DSA is twice faster than RSA to carry out signatures, whereas RSA is sixteen (16) times faster than DSA for verification. One common issue between RSA and DSA lies in the recommendations about key length for providing the same security assurance, bigger than 1024 bits (i.e., 2048) from 2010 by NIST [18], and European ECRYPT II Project [19]. Despite this, the time to generate keys in DSA is huge greater than the time used to generate keys in RSA. Thus, the main disadvantage of DSA is the time used in the key generation as is explained later.
(a) (b) Fig. 5. The difference in the performance time between RSA and DSA respect to sign (a) and verification (b), respectively, on average.
F. Almenares et al.: Overhead of using Secure Wireless Communications in Mobile Computing
339
Finally, ECDSA performance is so similar to DSA. In the same way, it is faster sign than verify, and the time (in seconds) spent is high when data are bigger and keys are longer. The meaningful difference lies in time spent to generate keys such as can be seen in Table II. DSA is the slowest with a relevant magnitude order among the three algorithms. DSA spends, at least, 7 times more than the time used by RSA to generate keys of the same length. ECDSA is the best algorithm in this sense, because of key sizes are smaller and efficient. In all the cases for ECDSA the time is a lot lesser than 1 second.
TABLE II
KEY GENERATION TIME
Algorithm
Key sizes (bits) 1024 2048 4096 512 1024 2048 4096 160 192 256
Time (s) 3.078093214 33.99207942 366.1998620 5.243404385 22.23015594 370.8107643 3353.931850 0.06464195 0.08208847 0.12192440
OS; therefore, it can be concluded JME browsers make calls to the system, using the underlying support offered by the OS. The first conclusions regarding support that can be pulled out from the table are: DSS is the unique protocol for authentication supported by browsers installed in non-Linux OS. Diffie-Hellman (DH) key exchange is only supported by native browsers. For maximum security, RSA or DSA authentication with ephemeral Diffie-Hellman key agreement is recommended (e.g., DHE-RSA-AES256SHA, DHE-DSS-AES128-SHA, etc.), because these cipher suites provide perfect forward secrecy, and can support large keys for long-term confidentiality [16]. A cipher suite using RC2 is only supported by Prestobased browser.
TABLE III
CIPHER SUITES SUPPORTED BY BROWSERS IN MOBILE DEVICES
RSA
Cipher suite ADH-AES256-SHA DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA AES256-SHA ADH-AES128-SHA DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA AES128-SHA ADH-DES-CBC3-SHA ADH-DES-CBC-SHA EXP-ADH-DES-CBC-SHA ADH-RC4-MD5 EXP-ADH-RC4-MD5 EDH-RSA-DES-CBC3-SHA EDH-RSA-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EDH-DSS-DES-CBC3-SHA EDH-DSS-DES-CBC-SHA EXP-EDH-DSS-DES-CBC-SHA DES-CBC3-SHA DES-CBC-SHA EXP-DES-CBC-SHA EXP-RC2-CBC-MD5 RC4-SHA RC4-MD5 EXP-RC4-MD5 DES-CBC3-MD5 DES-CBC-MD5 EXP-RC2-CBC-MD5 RC2-CBC-MD5 EXP-RC4-MD5 RC4-MD5
Supported browser NB-NL NB-L All NB-NL NB-L All NB-NL, NB-L NB-NL NB-NL NB-NL NB-NL All All NB-NL, PB PB All All NB-NL, PB -
DSA
ECDSA
Time used to generate key pairs in RSA, DSA and ECDSA. The time is expressed in seconds in accordance with the different key sizes.
C. Certificate Management All the platforms support X.509 certificates version 3 [20], with keys from 512 to 4096 bits. It is favourable, because it allows testing a bigger number of cipher suites. Browsers have access to the certificate store, where some certificates from well-known commercial Certification Authorities (CAs) are previously installed. In most cases, the interface to users manage certificates is restricted. The browsers have the control of managing personal certificates when they are required from a server. V. COST OF SECURE COMMUNICATIONS For secure communications, the measurements have been carried out for each of the cipher suites available in the native WebKit-based browser installed in the smart phone and others browsers, and varying the size of the Web page. The first point was to know the support in the different browsers. It is to say that from the 32 cipher suites available in the openSSLv0.98g used for setting up the secure server, only a subset of 13 cipher suites were supported by the native browser in non-Linux OS (NB-NL), 8 cipher suites by the native browser in Linux OS (NB-L), and 9 cipher suites by the non-native Presto-based browser (PB) in the best case. The list detailed is shown in Table III. There can be noted that cipher suites using ECC algorithms are not supported by this version of the OpenSSL. Browsers developed in Java ME are not included because the support is the same than native browsers installed in the
This table shows the support of cipher suites in the different browsers for mobile devices. NB-NL: Native Browser in Non-Linux OS, NB-L: Native Browser in Linux OS, PB: Presto-based Browser, -: None, All: all browsers.
340
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013
In addition, as conclusions about all browsers can be mentioned the following: All browsers support at least a cipher suite using AES cipher with RSA key exchange and authentication; therefore, they are able to provide a high security level. Although could not provide recommended maximum security, because only native browser installed in Linux OS are supporting both DH key exchange and RSA authentication. All browsers support cipher suites using DES, 3DES, or RC4 ciphers with RSA key exchange and authentication; therefore, they are able to provide a medium security level. The energy consumption (in Joules) of these cipher suites according to the data size can be seen in Fig. 6. The time consumption is similar until data of 100KB but with data greater the relation energy versus time is not directly proportional; for instance, energy consumed by RC4-MD5 cipher suite is bigger than energy consumed by DES-CBCSHA cipher suite; however, the time used by DES-CBC-SHA is greater than time used by RC4-MD5.
Fig. 7. Energy consumption (in Joules) in establishing a SSL connection to transfer a Web page with different data sizes between the smart phone’s native browser and a secure server, using a processor with 264MHz.
In addition, in both charts can be observed that both magnitudes increase linearly with the size of the transferred page. The variations between the different cipher suites are more significant for bigger file sizes, especially in regard to energy consumption. With small data size (i.e., up to 100KB) the difference between measurements is inappreciable.
Fig. 6. Energy consumption (in Joules) of a SSL connection by each cipher suite to transfer a Web page with different data sizes between a smart phone’s native browser and a secure server, using a processor with 264MHz.
Fig. 8. Time consumption (in seconds) when establishing a SSL connection to transfer a Web page with different data sizes between the smart phone’s native browser and a secure server, using a processor with 264MHz.
In this way, Fig. 7 and Fig. 8 represent the consumption in terms of energy and time, respectively, for the establishment of a SSL connection according the test bed explained previously in Section III. The measurements in the native browser based on WebKit are only showed, because linear upward trend is the same in all cases. Nevertheless, in the Presto-based browser, the execution time is 30% faster, although it supports lesser ciphers suite. In addition, Presto-based browser does not support SSL client authentication through digital certificates, therefore, this is an important limitation when it comes time to implement security steps. SSL client authentication could be performed using other mechanism with less security level such as login and password, for example.
The correlation between time and energy consumption can be analyzed better in the chart of the Fig. 9. The evolution for a specific case has been analyzed: with the greatest data size, 1MB, because it is possible to better appreciate such correlation. From the graph, there can be observed that algorithm consuming more energy it is not the same algorithm that consumes more time, EXP-EDH-RSA-DES-CBC-SHA. In the case of AES-256 cipher suite is the second one in energy consumption and the fourth one in the time consumption. The cipher suites using RC4 for key exchange are the lightest as regards time, but EXP-DES-CBC-SHA and DES-CBC-SHA are the lightest as regards energy consumption. Thus, there is not a direct general correlation between the performance in time of an algorithm and the associated energy consumption,
F. Almenares et al.: Overhead of using Secure Wireless Communications in Mobile Computing
341
i.e., the slowest cipher suite is not necessary the most expensive in terms of energy. The cost of energy depends on the operations underlying the particular cipher suite and thus evolves differently with time. So from the graph in Fig. 7, Table IV summarizes the energy consumption overhead for the best and worst cipher suites (i.e., the cheapest and the more expensive from the point of view of energy consumption) with respect to the case where no security is applied, using a file size of 1MB. In both cases, the security level provided is medium. The overhead for a high security level is 18% approximately in average (i.e., using cipher suites with AES256 and 128). The cipher suites in Table IV are the ones with lowest and highest energy consumption versus time ratio in Fig. 8, which justifies the overhead results for big data size. The consumption without cipher suite represents HTTP connections with Wi-Fi; therefore, there is no overhead in this case.
be seen that the overhead is between 5% and 17% for the same data size (i.e., 1MB) with a faster processor; meanwhile the overhead is between 7% and 71% for very small data size, 1KB. In this case, the equivalent cipher suites without export encryption algorithms, EDH-RSA-DES-CBC-SHA, is also the most costly cipher suite, and DES-CBC-SHA is the lightest one.
Fig. 10. The overhead added by cipher suites for SSL connections in Linux OS. The overhead is showed for each cipher suite supported according to different data sizes, using a processor with 330MHz.
For a high security level, the AES overhead is 9% in average for file size of 1MB and 21% for file size of 1KB. This last overhead is not meaningful with respect to the other cipher suites.
Fig. 9. Energy consumption (in Joules) versus time consumption (in seconds) in establishing a SSL connection to transfer a Web page with 1MB of size, using a processor with 264MHz.
VI. CONCLUSION AND FUTURE WORK In this paper results obtained from a study about support and efficiency of secure connections have been showed, i.e., using HTTP over TLS, and cryptographic algorithms associated with this. According to the results presented there can be concluded that although native browsers do not always provide the better performance, they provide more security support to applications using HTTPS. They are prepared to offer the maximum security level according to the NIST recommendations, using RSA or DSA authentication with ephemeral DH key agreement with AES as encryption algorithm. Besides, such browsers do not send all the user’s certificates stored in the device when client-side authentication is required. On the other side, Presto-based browser supports lesser ciphers in most cases, and allows sending all users’ certificates. Regarding overhead added by the security algorithms, this reaches about 17% in the worst case for big data size (i.e., 1MB), whereas it can reaches a 71% in the worst case for small data size (i.e., 1KB), taking as reference the faster processor. In the case of requiring a high security level, then, the overhead added would be 9% that could be considered low in return for benefits obtained with big data size, or 21% for
As mentioned previously, the overhead presented in the table is relative, it would be simply in case of 1MB data size, but for small data size the overhead could be even of 71%.
TABLE IV
ENERGY OVERHEAD FOR THE BEST AND WORST CIPHER SUITES
Cipher suite No cipher suite EXP-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA
Energy Consumption
Overhead
37,2205909 J 39,9790813 J 46,1130985 J
0% 7,41% 23,89%
The overhead added by cipher suites in SSL connections. The table shows the best and the worst case for file size of 1 MB, using a processor with 264MHz.
Fig. 10 shows the overhead added by cipher suites according to different data sizes. In this case, the measurements have been performed in a mobile device with the processor with 330MHz. Thus, the number of cipher suites is lesser, because the support is different. Nevertheless, the results are equivalent to the results showed previously. In the chart of Fig. 10, it can
342
IEEE Transactions on Consumer Electronics, Vol. 59, No. 2, May 2013 [16] C. Chernick, C. Edington, J. Matthew and R. Rosenthal (eds.), “Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations”, NIST Special Publication Rep. 800-52, 2005. [17] Java Community Process (JCP), “JSR 177: Security and Trust Services API for J2ME,” Aug. 2007. [18] E. Barker, W. Barker, W. Burr, W. Polk, M. Smid, “Recommendation for Key Management, Part 1: General”, NIST Tech. Rep., SP 800-57, Jul. 2012. [19] N. Smart (ed.), “Yearly Report on Algorithms and Key sizes (20112012),” Project Tech. Rep., D.SPA.20 Rev.1.0, ICT-2007-216676 ECRYPT II, Sep. 2012. [20] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” IETF Tech. Rep., RFC 5280, May 2008. BIOGRAPHIES Florina Almenárez Mendoza, (M’07) received her Ph.D. degree from the University Carlos III of Madrid (Spain) in 2006 and is currently an associate professor at UC3M. She received an award-winning as Magna CumLaude in her Computer Engineering degree. Her research interests include trust management, identity federation, security in ubiquitous computing, and SIM-based applications. She leads the research activities of the PerLab group in advanced trust models, security architectures for open and dynamic spaces, and identity management. Patricia Arias Cabarcos, received her Telecom. Eng. degree from Univ. Carlos III of Madrid in 2008 and she obtained the MSc degree in Telematics in 2009. Currently, she is pursuing a PhD at the Department of Telematics Engineering in the Univ. Carlos III of Madrid, working within the Pervasive Computing research group. Her research focuses on the problem of identity management in open and dynamic environments, with special attention to risk analysis and the underlying trust models. Andrés Marín López, (M’07) received a Telecom. Eng. degree and PhD from the Technical Univ. of Madrid in 1992 and 1996 respectively. He lectures in Computer Networks and Ubiquitous Computing in the Univ. Carlos III de Madrid, as an associate professor. His research interests include ubiquitous computing: limited devices, trust, security services, and security in NGN. Daniel Díaz-Sánchez, (M’07) received a Telecom. Eng. degree from Univ. Carlos III de Madrid in 2002. He graduated as Master Telematic Engineering (2004) and obtained his PhD (2008) from Univ. Carlos III of Madrid. He works as researcher and teacher at Universidad Carlos III. His research topic is distributed authentication, authorization and content protection activities. Rosa Sánchez Guerrero, received a Telecom. Eng. degree from Univ. Carlos III de Madrid in 2009 and she obtained the MSc degree in Telematics in 2011. Currently, she works as researcher at the Department of Telematics Eng. in the Univ. Carlos III of Madrid, working within the Pervasive Computing research group. Her research topics include the problem of identity management, security and privacy in healthcare.
small data size, whose consideration would be made in function of data being exchanged. Other testbed including cipher suites based on ECC are being performed, because this support was not extended, but it is currently greater each time. ACKNOWLEDGMENT Authors would like to thank to the students David Maroto, Rocío Blanco López, and Elma de la Fuente for their collaboration in performing measurements for different operating systems. REFERENCES
[1] [2] [3] [4] [5] [6] H. Richmond, “The Growth of Mobile Marketing and Tagging,” Microsoft Tag Rep., Mar. 2011. Accenture Consulting, “Mobile Web Watch Survey 2012: Mobile Internet --Spawning New Growth Opportunities in the Convergence Area,” Rep., Jul. 2012. T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol, Version 1.2,” IETF Tech. Rep., RFC 5246, Aug. 2008. E. Rescorla, “HTTP over TLS,” IETF Tech. Rep., RFC 2818, May 2000. C. Newman, “Using TLS with IMAP, POP3, and ACAP,” IETF Tech. Rep., RFC 2595, Jun. 1999. L. Shilong, H. Xi, C. Li, Z. Ze, and L. Dong, “Design and implementation of an ASIC-based sensor device for WSN applications,” IEEE Trans. Consumer Electron., vol. 55, no. 4, pp. 1959-1967, Nov. 2009, doi: 10.1109/TCE.2009.5373756. K. Mooseop, J. Hongil, K. Youngsae, P. Jiman, and P. Youngsoo, “Design and implementation of mobile trusted module for trusted mobile computing,” IEEE Trans. Consumer Electron., vol. 56, no. 1, pp. 134-140, Feb. 2010, doi: 10.1109/TCE.2010.5439136. H. Rifà-Pous, and J. Herrera-Joancomartí, “Computational and Energy Costs of Cryptographic Algorithms on Handheld Devices,” Future Internet, vol. 3, no. 4, pp. 31-48, Feb. 2011. N.R. Potlapally, S. Ravi, A. Raghunathan and N.K. Jha, “A Study of the Energy Consumption Characteristics of Cryptographic Algorithms and Security Protocols”, IEEE Trans. on Mobile Comput., vol. 5, no. 2, pp. 128-143, Feb. 2006. V. Gupta and M. Wurm, “The Energy Cost of SSL in Deeply Embedded Systems,” Sun Tech. Rep., 2008. N. Balasubramanian, A. Balasubramanian, and A. Venkataramani, “Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Applications,” in Proc. of the 9th ACM SIGCOMM Conf. on Internet Measurement (IMC '09), ACM Press, New York, NY, USA, pp. 280-293, Nov. 2009. F. Almenares, P. Arias, A. Marín, D. Díaz-Sánchez, and R. Sánchez, “How Costly are Secure Transactions on Handheld Devices?,” in Proc. of the IEEE Conf. on Consumer Electronics (ICCE), Jan. 2013. S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”, IETF Tech. Rep., RFC 4492, Network WG, May 2006. Cloud and Web Service Security Lab (ClaWSLab), “Browser Security Handbook”, Research Project Rep., 2011. N. Vallina-Rodríguez and J. Crowcroft, “Energy Management Techniques in Modern Mobile Handsets”, in IEEE Commun. Surveys & Tutorials, vol. 15, no. 1, Jan-Mar 2013.
[7]
[8] [9]
[10] [11]
[12]
[13]
[14] [15]
