Analysis of Scalable Security – MC-SSL Savings Johnson Lee, Victor C.M. Leung, Konstantin Beznosov

University of British Columbia

2356 Main Mall

Vancouver, B.C., V6T 1Z4 Canada

{johnsonl,vleung,beznosov}@ece.ubc.ca

Technical Report LERSSE-TR-2005-02

Introduction

Recent breakthroughs in software complexity have increased demands on computer

systems. Hardware developments in mobile devices have not been able to keep up to the

demands of the software. In addition, mobile device requirements have been steadily

rising with the appearance of additional features. New applications such as Voice over IP

(VoIP) have only increased the gap between the desired functionalities versus the real

capabilities of a mobile device. Battery life is also another key issue in the development

of mobile devices [1] . As computational demands increase while the CPU technology

used remains relatively constant, battery drain issue due to complex software processing

has become a common problem. One solution to offset both the battery-drain problem

and the high CPU requirements issue is to employ scalable features. This is already a

common way of saving battery life in modern laptops. For example, Acer Notebooks

feature their ePowerManager Software [2] that controls the CPU speed, LCD brightness,

and CPU fan such that system achieves the best energy efficiency.

Security processing is one of the more CPU intensive processes in mobile devices.

Modern mobile devices include a web browser that would allow users to access financial

institutes for online banking or to access online stock brokers to make crucial stock

transactions. These applications require a fairly high level of security and therefore, have

resulted in intensive CPU processing by using some of the higher-end cipher suites. This

paper will investigate how MC-SSL can alleviate the CPU requirements of secure web

transactions by using multiple channels, each with its own, different, cipher suite, and

switching the channel based on the data’s security requirements.

MC-SSL Background

The Multi-Channel Secure Socket Layer (MC-SSL) protocol has been developed by

Yong Song [3] as a general solution to using partially trusted applications proxies. Thus,

the original problem domain for MC-SSL is in the area where application proxies are

used, such as mobile computing. Many mobile devices currently on the market cannot

directly access data from outside the service provider’s network due to different protocols

used for data access. For instance, some GSM/GPRS mobile phone service providers use

the Wireless Application Protocol (WAP) for data access, which is not able to directly

use Internet Protocol (IP) packets. In order for a mobile device to access the Internet, an

application gateway proxy is required in order to repackage the IP packets into WAP

packets. This application gateway proxy has to be able to read the contents of the

Internet packets and appropriately repackage into the correct WAP packets. Therefore,

application proxies usually have to be completely trusted. MC-SSL alleviates this issue

by providing separate, direct channels for highly critical data; thus allowing the proxy

servers to be only partially trusted.

In essence, the MC-SSL allows the client and server to negotiate the number of channels

required and the security strength of each channel. The negotiation process starts with

the primary channel, which is a direct link between the server and the client. This

channel is used to communicate the number of channels required, whether proxies are

used, which proxies are mutually trusted, and the cipher suite for each channel. The MC-

SSL protocol also allows the client and server to negotiate the channel direction for all

secondary channels as a security measure to increase its man-in-the-middle-attack

resistance by not allowing instructions to be sent through the channel.

Although MC-SSL has been developed as a solution to using partially trusted proxies, the

protocol is general enough to be used for other applications, one of which will be the

main investigation of this paper. Since MC-SSL allows negotiation of different channels

with different cipher suites, it would theoretically be able to adjust the security level

based on the data sensitivity.

VS

MC-SSL:Primary Channel (Confidentiality and Integrity)

MC-SSL: Secondary (Integrity Only) Channel

MC-SSL:Secondary (Clear Text) Channel

SSL Connection:Both Confidentiality and Integrity Protected

Figure 1 – Normal SSL Connection VS MC-SSL Connection

The above figure shows the topology provided by MC-SSL. The elliptical circle

indicates the actual connection established in the transport layer. MC-SSL essentially

creates three different kinds of pipes within one connection to push data through. The

primary channel provides both confidentiality and integrity while secondary channel’s

cipher suites are negotiated according to the needs of the data.

Methodology

For this investigation, we used the Java Secure Socket Extension API to program a

simulation of MC-SSL as a way to measure the CPU usage. There are three elements in

the simulation: the SSL web server, clear-text web server, and client. The basic idea is to

establish three communication channels: an integrity only channel, an encrypted, integrity

checking channel, and a clear text channel. We will compare the CPU usage of the file

transfer by breaking down a 10 megabyte MP3 file, which cannot be further compressed

by any lower level protocols, into various proportions and sending them through different

channels. The goal of the measurements is to establish a three dimensional graph of the

percentage of data requiring integrity and/or confidentiality versus the CPU savings

percentage.

The SSL web server will enable two cipher suites,

SSL_RSA_WITH_NULL_SHA and TLS_RSA_WITH_AES_128_CBC_SHA. The

actual cipher suite used for a particular connection depends on which one the client has

enabled. The SSL_RSA_WITH_NULL_SHA is the integrity only channel with SHA-1

hashing algorithm for integrity check. TLS_RSA_WITH_AES_128_CBC_SHA is the

encrypted channel using Advanced Encryption Standard (AES) coupled with SHA-1

integrity checking algorithm. The 128_CBC means that the AES algorithm uses Cipher-

Block Chaining (CBC) technique with 128 bit encryption. CBC is a technique for linking

each of the 128 bit cipher blocks together such that all of them are dependent on each

other. Lastly, the RSA keyword in the cipher suite indicates that the RSA key exchange

algorithm is used to establish a common key. For more information, refer to [4] [5] [6]

This SSL web server will host an array of MP3 files ranging from 0 bytes to 10Mbytes in

an interval of 1Mbytes. In other words, it will contain MP3 files of size 0 Mb, 1Mb…

8Mb, 9Mb, and 10Mb. The clear-text web server is just a plain, unmodified web server.

The clear-text web server hosts the same files as the SSL web server but using a different

port. The client, therefore, establishes connection to the SSL web server by enabling one

of two cipher suites, depending on which type of channel it would like to establish –

encryption with integrity check or integrity only channel.

The connection sequence is shown below in Figure 2. First the SSL Server

enables the two cipher suites. Then, the client enables the

TLS_RSA_WITH_AES_128_CBC_SHA cipher suite and initiates the handshake process.

Once the handshake is complete, the client requests the appropriate file, which will be

explained in the below. After the first connection is established, the client then creates a

new SSL socket and enables SSL_RSA_WITH_NULL_SHA cipher suite for that socket

and initiates the handshake. This process is repeated for the clear text server until all

three sockets have requested for a file and waiting for the actual file transfer. At this

point, a CPU snapshot is taken. The CPU snapshot library uses Java Native Interface

(JNI) to call a C native routine that get the CPU time and Process time. After the CPU

snapshot, the file transfers begin and another CPU snapshot is taken afterwards. Using

the two CPU snapshots, we are able to measure the CPU usage, process CPU time, and

total elapsed CPU time. Our comparison uses the process CPU time and discards the

other information. The file chosen to be transmitted depends on the current data

protection breakdown. For example, an instance of the file transmission could be

encryption and integrity channel 4Mb file, integrity channel 3Mb file, and clear text

channel 3Mb file. Total file size of all three connections must be 10 Mb.

ClientClient SSL ServerSSL Server Cleartext

Server

Cleartext

Server

7: Enabled Cipher:

"SSL_RSA_WITH_NULL_SHA"

1: Enabled Cipher:

"SSL_RSA_WITH_NULL_SHA" &

"TLS_RSA_WITH_AES_128_CBC_SHA"

3: Enabled Cipher:

"TLS_RSA_WITH_AES_128_CBC_SHA"

4: start SSL Handshake

8: start SSL Handshake

5: "GET " + (file) + " HTTP/1.0"

9: "GET " + (file) + " HTTP/1.0"

11: "GET " + (file) + " HTTP/1.0"

2: Create SSL Socket1 (Host, Port)

6: Create SSL Socket2 (Host, Port)

10: Create normal Socket3 (Host, Port)

12: CPU Snapshot

13: Read inStream from Socket1

14: Read inStream from Socket2

15: Read inStream from Socket 3

16: CPU Snapshot

Figure 2 – MC-SSL Simulation Connection Sequence

Theoretical Results

Based on the works of Ravi, Raghunathan, and Potlapally [7] on wireless security

processing gap, we were able to extrapolate the theoretical CPU work load savings by

downgrading the security algorithm on non-sensitive data. In their section on wireless

security gap, they indicated that the processing requirements for 3DES, AES, SHA, and

MD5 at 10Mbps are 535.9, 206.3, 115.4, and 33.1 MIPS respectively. Assuming that the

MIPS value are linearly related such that a channel using confidentiality AES and

integrity SHA has a total MIPS requirement 651.3 (535.9+115.4), we can vary the

percentage of data sent through each type of channel to determine topographical shape of

the resulting graph. In Figure 3, we plot the extrapolation results ranging confidentiality

and integrity from 0 to 100. The resulting maximum savings, located at the top of the

graph, is 86.5%. Although one cannot have confidentiality without integrity in SSL

connections due to cipher suite limitations, the theoretical extrapolation is able to include

such possibility and the areas which confidentiality exceeds integrity should not be

considered. Another assumption used for this analysis is an estimated value for the MIPS

requirements of a clear text channel at 50 MIPS. Due to the fact that Ravi, et al. provided

the MIPS requirements for a pure AES or SHA algorithm, the processing needs of a

regular cleartext channel is not available. We chose a value of 50 MIPS to illustrate the

potential savings and linearly add it to the MIPS requirements of AES and SHA for the

SSL channel overhead. In the next section, we will show the actual results based on our

web server simulations.

0

20

40

60

80

100

0

20

40

60

80

100

0

10

20

30

40

50

60

70

80

Confidentiality

Integrity

Savings

Figure 3 – Theoretical Integrity, Confidentiality vs. CPU Saving Graph

Actual Results

Our measurements, based on ten repetitions of each data point, sixty-six data points in

total, are summarized in Figure 4. It is interesting to see how similar the actual results

are to the theoretical extrapolation in max value, at 76.4%, versus 86.5%. It is also worth

noting that the actual results confirm that the relationship is purely linear with low impact

of the overhead at 10Mbps.

2

4

6

8

10

0

2

4

6

8

10

12

0

10

20

30

40

50

60

70

Confidentiality

Intergrity, Confidentiality vs CPU Savings

Intergrity

CPU Percentage Saving

Figure 4 – Actual Integrity, Confidentiality vs. CPU Savings

Conclusion

The results of the simulation support the use of scalable SSL connection for mobile

devices where CPU processing power is limited. By sending large, non-confidential data

from a confidential site through an integrity only channel, one can save up to 50% of

CPU processing power. However, by breaking down websites in finer granularities, one

would also require a way to reassemble the data together. This can be done at the

application layer but it would be most preferable to be built into a protocol where HTML

tags would signal what kind of channel the data should be sent through. In a typical

banking application, the data breakdown is 3.4% integrity and confidentiality, 96.6%

integrity only. Therefore, the resulting CPU saving is 37% if it employs scalable MC-

SSL. This value can be translated to a battery life saving but the relationship is different

for each platform and user style. Much of the data sent in this case study is actually

advertisement and can consider it to be sent through a clear text channel for a greater

CPU saving. However, there may be possible security weaknesses such as phishing or

impersonation when advertisements are not protected by integrity checks.

Future Work

The total file size transferred in this experiment is 10 Mbytes. Apparently at 10 Mbytes,

the channel overhead does not cause significant lowering of the CPU savings. Therefore,

the next logical step in the experiment is to lower the total file size transferred down to 8

Mbytes, 6 Mbytes, 4 Mbytes, and 2 Mbytes. This would allow us to see at what point the

multiple channel scheme is worthwhile applying. It is essential that we narrow down the

exact point which the connection overhead causes this scheme to be ineffective because

the current data rate of cellular devices have not reach the point where this scheme would

be useful. However, for Personal Data Assistant devices (PDAs), the scheme might

already be applicable because a typical PDA only has 300MHz processing power but is

able to use 802.11b/g wireless network, which can operate up to 56Mbps.

References

[1] P. Prasithsangaree and P. Krishnamurthy, “Analysis of Energy Consumption of RC4

and AES Algorithms in Wireless LANs,” Globecom 2003, pp. 1445 – 1449.

[2] Acer, Acer eManager, http://global.acer.com/products/notebook/emanager01.htm.

[3] Y. Song, “Multiple-Channel Security Model and Its Implementation over SSL,”

Master Thesis, University of British Columbia, 2004.

[4] Wikipedia, “Block Cipher Modes of Operation,”

http://en.wikipedia.org/wiki/Cipher_Block_Chaining, Aug. 2005.

[5] Wikipedia, “Advanced Encryption Standard,” http://en.wikipedia.org/wiki/AES,

Sep. 2005.

[6] Wikipedia, “SHA hash functions,” http://en.wikipedia.org/wiki/SHA, Sep. 2005.

[7] S. Ravi, A. Raghunathan, N. Potlapally, “Securing Wireless Data: System

Architecture Challenges,” Proc. Int’l Symp. System Synthesis, p195-200, Oct. 2002.

[8] S. Thomas. SSL and TLS Essentials – Securing the Web. John Wiley and Sons, Inc.,

Third Avenue, New York, 2000.

Related Work

*NOTE: this section is meant as an insert into the related work for the MC-SSL paper

that also discusses proxies.

In terms of MC-SSL’s features, there is similar protocol paradigm that utilizes proxies:

Split SSL. In typical web proxy topology, the proxy server does not check for data

integrity but instead, just caches and dumps the data. As a result, the proxy sometimes

provides out-of-date information to the client. Split SSL proxies mitigate that issue by

simulating a normal SSL connection with the client and merging authentication records

from the server with the data from its cache. Although this effectively reduces the

bandwidth load on the server, it does not provide confidentiality and the proxy has to be

unconditionally trusted. In the sample system designed by Lesniewski-Laas and

Kaashoek, the system is able to provide secure public file downloads via mirrors/proxies

with instant update. Compared to normal proxies, the data distributes and updates

immediately and resolves the issue of out-of-date data.

Compared to MC-SSL, Split SSL technique is similar in that it is able to provide data

integrity through the use of proxies. MC-SSL proxies establish proxy channels that may

be configured with hash function for data integrity and an optional cipher suit. On the

other hand, MC-SSL and Split SSL differs in that Split SSL does not require

modifications to the client while MC-SSL does. In addition, MC-SSL can provide

confidentiality by routing sensitive data via direct connection and less or non-sensitive

data through the proxy. Split SSL’s proxy can impersonate the server and therefore, still

has to be completely trusted. However, for the designed application, which is the

distribution of public software, confidentiality is not an issue.

C. Lesniewski-Laas and M. Kaashoek, “SSL splitting: securely serving data from

untrusted caches,” Proceedings of the 12th USENIX Security Symposium, Aug 2003.