Jun 9, 2006 - vi. AN ABSTRACT OF THE THESIS OF. Camille Georges Gaspard for Master of Engineering ... Title: PRIDE â Policy-Driven Web Security For Handheld Wireless Devices. Almost all ...... 2.1 Example of PATRIOT's policy⦠...... act as a Security Gateway for the organization by receiving all the Web traffic and.
AMERICAN UNIVERSITY OF BEIRUT
PRIDE – POLICY-DRIVEN WEB SECURITY FOR HANDHELD WIRELESS DEVICES
by
CAMILLE GEORGES GASPARD
A thesis submitted in partial fulfillment of the requirements for the degree of Master of Engineering to the Department of Electrical and Computer Engineering of the Faculty of Engineering and Architecture at the American University of Beirut
Beirut, Lebanon June 2006
AMERICAN UNIVERSITY OF BEIRUT
PRIDE – POLICY-DRIVEN WEB SECURITY FOR HANDHELD WIRELESS DEVICES
by
CAMILLE GEORGES GASPARD
Approved by:
______________________________________________________________________ Dr. Ayman Kayssi, Professor Advisor Electrical and Computer Engineering
______________________________________________________________________ Dr. Ali Chehab, Assistant Professor Member of Committee Electrical and Computer Engineering
______________________________________________________________________ Dr. Mazen Saghir, Assistant Professor Member of Committee Electrical and Computer Engineering
______________________________________________________________________ Dr. Wassim Masri, Assistant Professor Member of Committee Computer Science
Date of thesis defense: June 9, 2006
AMERICAN UNIVERISTY OF BEIRUT
THESIS RELEASE FORM
I, Camille Georges Gaspard
authorize the American University of Beirut to supply copies of my thesis to libraries or individuals upon request.
do not authorize the American University of Beirut to supply copies of my thesis to libraries or individuals for a period of two years starting with the date of the thesis defense.
____________________ Signature
____________________ Date
ACKNOWLEDGMENTS
My recognition and gratitude are addressed to my committee members, Dr. Ayman Kayssi, Dr. Ali Chehab, Dr. Mazen Saghir and Dr. Wassim Masri, for their support and advice throughout this work. In particular, I would like to thank my supervisor Dr. Ayman Kayssi., the person from whom I learned a lot. I would like also to thank all the great people I met and worked with in the ECE department at AUB and especially in the 204 lab. Very special thanks go to Wassim Itani who was a great support. My deep gratitude goes to my father and mother who were always considering themselves second priority after us (me, my brother and sister). Finally, very special thanks to my brother Fares, my sister Nour, Sarah Yazji, Jonathan Van Melle and all my friends.
v
AN ABSTRACT OF THE THESIS OF
Camille Georges Gaspard
for
Master of Engineering Major: Computer and Communications Engineering
Title: PRIDE – Policy-Driven Web Security For Handheld Wireless Devices
Almost all portable devices such as laptops, palmtops, and smart phones are equipped with built-in Web browsers. New mobile commerce (m-commerce) applications such as banking and mobile payments are becoming possible. Although the adoption of m-commerce services is showing some acceleration, great concerns are raised about the security of the sensitive data flowing over the wireless links. Wireless applications have special and unique requirements compared to Internet applications. Usually the wireless applications operate over lower bandwidth networks with high latency and frequent disconnections using devices that vary greatly in capabilities and resources. For this reason, the protocols used in securing wireless enterprise applications have to be designed specifically for operation in wireless environments on devices that are constrained in terms of processor speed, memory resources, storage capacity, and battery power.
This thesis presents PRIDE (Policy-driven web secuRity for handheld wIreless DEvices) as an efficient security architecture for assuring the confidentiality and integrity of Web traffic between wireless handheld devices and enterprise application servers. PRIDE is a scalable, policy-based solution capable of evolving and adapting to suit the security requirements of a wide range of wireless devices with various capabilities and resources. The customizable policy-based architecture in PRIDE can be configured to provide the security services according to the content and sensitivity of the network data in a Web transaction. This gives PRIDE considerable performance gains over existing bulk encryption protocols such as SSL.
In addition, this thesis presents ODYSSEY as an efficient security architecture for assuring privacy and security through applying selective confidentiality and integrity on Web traffic between wireless handheld devices and the Internet. ODYSSEY does not impose any requirements on surfed Web sites.
Finally, this thesis presents SmartSSL. SmartSSL is a solution for assuring security of Web sites using SSL in an efficient way. SmartSSL is a content- and policyvi
based security solution that applies SSL dynamically on parts of the Web traffic without requiring the administrator to inspect the content of the Web site.
PRIDE, ODYSSEY and SmartSSL are designed as platform-independent architectures and can be seamlessly integrated into existing application servers and wireless mobile client devices.
vii
CONTENTS
ACKNOWLEDGMENTS................................................................. v ABSTRACT ...................................................................................... vi LIST OF ILLUSTRATIONS .......................................................... xiii LIST OF TABLES .......................................................................... xvi
Chapter
1. INTRODUCTION......................................................................... 1 1.1
Overview of Wireless Web Security ..........................................................1
1.2
IPSec...........................................................................................................2 1.2.1
Overview....................................................................................2
1.2.2
IPSec Implementations ..............................................................3
1.2.3
1.2.2.1
Host Implantation ....................................................3
1.2.2.2
Router Implementation ............................................5
IPSec Modes ..............................................................................6 1.2.3.1
Transport Mode........................................................7
1.2.3.2
Tunnel Mode............................................................8
1.2.4
Security Association ..................................................................9
1.2.5
Policy .........................................................................................9
1.2.6
Encapsulating Security Payload (ESP) ......................................9
1.2.7
Authentication Header (AH)....................................................11
1.2.8
Internet Key Exchange (IKE) ..................................................11
1.2.9
Multi Layer IPSec (ML-IPSec)................................................12
viii
1.3
Secure Sockets Layer (SSL).....................................................................13 1.3.1
Overview..................................................................................13
1.3.2
SSL Architecture......................................................................14
1.3.3 1.4
1.3.2.1
SSL Session ...........................................................15
1.3.2.2
SSL Connection .....................................................16
1.3.2.3
Digital Certificates.................................................16 Certificates in SSL ...............................17
1.3.2.3.2
Subscriber Authentication: ..................18
1.3.2.4
SSL Record Protocol .............................................19
1.3.2.5
Change Cipher Protocol.........................................20
1.3.2.6
Alert Protocol.........................................................20
1.3.2.7
Handshake Protocol ...............................................20
KSSL........................................................................................22
XML Security...........................................................................................24 1.4.1
Overview..................................................................................24
1.4.2
Document-based Security ........................................................25
1.4.3
XML Digital Signature ............................................................25 1.4.3.1
1.4.4 1.4.5
Access Control Requirements................................34
XKMS......................................................................................35 1.4.6.1
1.4.7
XML Encryption Methods.....................................31
Access Control.........................................................................34 1.4.5.1
1.4.6
XML Canonicalization ..........................................29
XML Encryption......................................................................30 1.4.4.1
1.5
1.3.2.3.1
XKMS Specifications ............................................35
Tools and other Standards........................................................36 1.4.7.1
Author-X................................................................36
1.4.7.2
IBM Alpha Works .................................................36
1.4.7.3
SAML ....................................................................37
Comparison...............................................................................................38
ix
1.6
Thesis Organization..................................................................................38
2. PREVIOUS WORK ..................................................................... 39 2.1
Introduction ..............................................................................................39
2.2
Security Protocol Design..........................................................................41
2.3
Implementation and Performance Analysis..............................................45 2.3.1
PATRIOT Overview................................................................45
2.3.2
PATRIOT Implementation ......................................................46
2.3.3
ESCORT Overview .................................................................47
2.3.4
ESCORT Implementation........................................................48
3. PRIDE .......................................................................................... 51 3.1
Introduction ..............................................................................................51
3.2
The Security Policy ..................................................................................52
3.3
Policy Loading and Compaction ..............................................................55
3.4
Policy Scope and Caching ........................................................................56
3.5
Web Traffic Confidentiality and Integrity................................................57
3.6
Mathematical Model.................................................................................62
3.7
3.6.1
Percent Decrease in Encrypted Bytes ......................................63
3.6.2
Performance Gain ....................................................................64
PRIDE Implementation ............................................................................66 3.7.1
.Net Overview..........................................................................67 3.7.1.1
Application Security: Best Practices......................67
3.7.1.2
.Net Security ..........................................................68
x
3.7.1.3
IIS and ASP.Net Link ............................................70
3.7.1.4
File Handling .........................................................70
3.7.2
Implementation Environment ..................................................71
3.7.3
PRIDE’s HTTP Response........................................................72
3.7.4
Results......................................................................................74
4. OTHER APPLICATIONS ........................................................... 76 4.1
4.2
ODYSSEY................................................................................................76 4.1.1
Introduction..............................................................................76
4.1.2
Privacy Issues on the Web .......................................................77
4.1.3
The Anonymizer ......................................................................79
4.1.4
Web Statistics ..........................................................................80
4.1.5
Concept ....................................................................................82
4.1.6
ODYSSEY’s Design................................................................82 4.1.6.1
The Security Policy................................................83
4.1.6.2
Policy Customization.............................................86
4.1.6.3
Policy Caching and Growing.................................86
4.1.6.4
Web Traffic Confidentiality and Integrity .............86
SmartSSL..................................................................................................89 4.2.1
Introduction..............................................................................89
4.2.2
Concept ....................................................................................90
4.2.3
SmartSSL Design.....................................................................90
4.2.4
4.2.3.1
Requirements .........................................................91
4.2.3.2
Security Policy.......................................................91
4.2.3.3
Web Traffic Confidentiality and Integrity .............91
Comparisons (PRIDE, SmartSSL, Bulk SSL) .........................93
5. CONCLUSIONS AND FUTRE WORK...................................... 95
xi
Appendix
REFERENCES................................................................................. 97
xii
ILLUSTRATIONS Figure
Page
1.2.1 IPSec - Host Implementation + OS integration......................................
4
1.2.2 IPSec - Host Implementation + BITS…………......................................
5
1.2.3 IPSec - Native Router Deployment.........................................................
6
1.2.4 IPSec - Router BITW Deployment…......................................................
6
1.2.5 IPSec - IP packets in different IPSec Modes...........................................
7
1.2.6 IPSec - Transport Mode………………………………….......................
8
1.2.7 IPSec: Tunnel Mode………………………………................................
9
1.2.8 IPSec - ESP Payload…………………………………............................
10
1.2.9 IPSec: AH Header…………………………………...............................
11
1.3.1 SSL Protocol Stack…………………………………..............................
15
1.3.2 SSL Record Protocol Operation……………………..............................
21
1.3.3 SSL Handshake Protocol.........................................................................
23
1.4.1 XML Signature structure........................................................................
28
1.4.2 Example: Original XML document.........................................................
32
1.4.3 Example: Encrypting the entire document………..................................
32
xiii
1.4.4 Example: Encrypting the tag................................................
33
1.4.5 Example: Encrypting the content of the CardID element.......................
34
1.4.6 Example: Encrypting arbitrary non-XML data (JPEG example)............
35
2.1
Example of PATRIOT’s policy……………………...............................
46
3.1
PRIDE high-level structure.....................................................................
51
3.2
PRIDE architecture and components…………………………………...
52
3.3
Sample security policy……………………............................................
53
3.4
Server-side Security Engine operation....................................................
53
3.5
PRIDE’s Server Security Engine Flow...................................................
59
3.6
PRIDE’s Client Security Engine Flow....................................................
61
3.7
PRIDE’s HTTP Header………………...................................................
73
3.8
Bulkily Encrypted Image Response........................................................
74
3.9
Content-base secured HTML Response..................................................
74
3.10
Client Processing Speed..........................................................................
75
4.1
Privacy on the Web.................................................................................
78
4.1
AUB Website Statistics………………………………….......................
80
xiv
4.2
Example of Public Proxies’ Statistics......................................................
81
4.3
ODYSSEY General Architecture…........................................................
82
4.4
ODYSSEY’s Policy.................................................................................
83
4.5
SmartSSL General Structure...................................................................
91
4.6
Comparisons……………………………………………………............
93
xv
TABLES
Table
Page
1.4.1
Specification of XML Signature Elements……………………….........
28
2.1
PATRIOT performance results...............................................................
48
2.2
ESCORT database server implementation results..................................
48
2.3
ESCORT desktop client implementation results.....................................
48
2.4
ESCORT mobile client implementation results......................................
50
3.1
Summary of .Net cryptographic capacities.............................................
69
3.2
Example of file handlers….....................................................................
71
3.3
PRIDE Client Test Results......................................................................
75
xvi
To My Father and Mother,
CHAPTER 1 INTRODUCTION
Security is one of the most critical concerns on today’s Internet. Companies are investing in security products in order to protect their information systems. In addition, enterprise Web applications accessed from wireless devices with limited resources have different requirements and challenges in comparison with today’s high-performance desktop machines. This is due to the scarce CPU power, memory and limited battery resources they feature. This has raised the interest level in building an efficient security system for the enterprise wireless Web applications.
1.1 Overview of Wireless Web Security Almost all portable devices such as laptops, palmtops, and smart phones are equipped with built-in Internet connectivity and Web browsers which make them capable of browsing Web content anywhere and anytime without being bound to one location. New mobile commerce (m-commerce) applications such as banking and mobile payments are becoming possible and many existing electronic commerce (ecommerce) applications can be modified to fit into the mobile environment. Although the adoption of m-commerce services is accelerating, great concerns are raised with regards to security of the sensitive data flowing over the wireless links where data confidentiality and integrity may be compromised by unauthorized access. Wireless applications have special and unique requirements compared to Internet applications. Usually the wireless applications operate over lower bandwidth networks with high latency and frequent disconnections using
1
devices that vary greatly in capabilities and resources. For this reason, the protocols used in securing wireless enterprise applications have to be designed specifically for operation in wireless environments and must address the needs and requirements of a large variety of wireless devices which are, in their majority, severely constrained in terms of processor speed, memory resources, storage capacity, and battery power. Different solutions exist to secure enterprise Web sites. These solutions can be categorized based on the layer at which security is applied. IPSec for example, applies security at the network layer while SSL applies security at the transport layer. XML Security, on the other hand, is an application-layer security platform. In this chapter we survey IPSec, SSL and XML Security as examples of network, transport and application-layer security protocols, respectively.
1.2 IPSec 1.2.1
Overview Internet Protocol (IP) provides no means or mechanisms to secure network
traffic. This has lead to the implementation of security protocols and mechanisms on upper network layers such as on transport or the application layer. From a security point of view, IP can not guarantee that IP datagrams received are [1]: •
from the claimed sender,
•
that they contain the original data that the sender placed in them or
•
that the original data was not inspected by a third party while packet was
being sent from source to destination.
IPSec [1] was created to guarantee origin authentication, data integrity and confidentiality, thus solving the above mentioned problems. By implementing security
2
at the network level, IPSec assures security on all upper-layer protocols (e.g. TCP or UDP). IPSec implements two main protocols to protect IP datagrams: Encapsulating Security Payload (ESP) and the Authentication Header (AH). Both provide dataorigin authentication, data integrity and anti-replay protection. ESP provides in addition, data confidentially by the use of encryption. For keys management, IPSec uses IKE – the Internet Key Exchange protocol. IKE is used to dynamically authenticate IPSec peers, agree on security settings and generate and distribute shared keys. Keys in IPSec are used for encryption (in ESP) and for keyed MAC (data integrity in both AH and ESP). Public key interaction is limited to the initial phase of key exchange due to the inherent low performance in this technology that is not suitable for IPSec which must be a fast protocol. This section is organized as follows: Section 1.1.2 presents the IPSec different implementations. Modes of IPSec are shown in Section 1.1.3. Security Associations or SAs along with policies are presented in Sections 1.1.4 and 1.1.5, respectively. ESP and AH are described in Sections 1.1.6 and 1.1.7 while IKE is shown in Section 1.1.8. Finally, the new proposed multi-layer IPSec protocol is presented in Section 1.1.9.
1.2.2
IPSec Implementations
1.2.2.1 Host Implantation Host implementation is when the packet is secured in the same host that originates it. The main advantages of host implementation are as follows: •
Provides security end-to-end.
•
The ability to implement all modes of IPSec.
•
Provides security on a per flow basis.
3
•
The ability to acquire the user context for authentication.
Host implementation can be done in two deployment scenarios: •
Operating system (OS) integrated. See Figure 1.2.1.
•
“Bump in the Stack” (BITS) by adding a shim between the network and
data link layer of the protocol stack. See Figure 1.2.2.
Fig. 1.2.1.IPSec - Host Implementation + OS integration
Fig. 1.2.2. IPSec - Host Implementation + BITS
4
1.2.2.2 Router Implementation In this scenario security is provided by tunneling IP packets at the security gateway. This is extremely useful in building secure VPNs and extranets. The following are the advantages of router implementation: •
Ability to build secure VPNs over public networks such as the Internet.
•
Ability to authenticate users entering to the enterprise intranet.
Two deployment scenarios exist for router implementation: •
Native deployment: see Figure 1.2.3.
•
“Bump In The Wire” (BITW): see Figure 1.2.4.
Fig. 1.2.3. IPSec - Native Router Deployment
5
Fig. 1.2.4. IPSec - Router BITW Deployment
1.2.3
IPSec Modes IPSec can operate in two modes: transport mode and tunnel mode. Transport
mode is an end-to-end model that must be implemented at the level of peers (hosts) while in tunnel mode, gateways take the responsibility of securing the IP traffic and peers do not get involved in security operations. Each has its own advantages and disadvantages and one is not absolutely preferable over the other. Figure 1.2.5 depicts protected IP packets in both tunnel and transport modes.
6
Fig. 1.2.5. IPSec - IP packets in different IPSec Modes
1.2.3.1 Transport Mode In transport mode, AH or ESP can be used to provide end-to-end security. In this mode, adding gateways and major changes in the network topology are not needed. This is the main advantage of using transport mode over tunnel mode. The main disadvantage in this mode is that changes in the stack model must be done on the hosts that want to communicate securely. Figure 1.2.5 depicts an IP packet when secured in tunnel mode. Transport mode’s topology is depicted in Figure 1.2.6.
7
Fig. 1.2.6. IPSec - Transport Mode
1.2.3.2 Tunnel Mode When tunnel mode is used, IP packets are secured by a device different than the host that generated the packets. This device is the IPSec gateway which takes responsibility of securing and removing security features from IP packets. Tunnel mode is used mainly to secure VPNs. Tunnel mode requires the installation of new nodes in the network, the IPSec gateways, but does not require further changes on the hosts which is a strong advantage for tunnel mode over transport mode. Packets protected with tunnel mode are shown in Figure 1.2.5 while Figure 1.2.7 depicts tunnel mode’s topology.
Fig. 1.2.7. IPSec: Tunnel Mode
8
1.2.4
Security Association A security association or SA is a collection of necessary security
configurations. SA defines what traffic is to be secured, how it is secured, and with whom the protection is performed. SAs are unidirectional, thus for two IPSec peers to communicate securely, four SAs must exist; two for each peer. SAs are refereed to by a Security Parameter Index (SPI) - which actually is present in each IPSec packet’s header to be transmitted. SAs reside in a SA Database (SADB). SA might be manually or automatically configured, and has a certain lifetime.
1.2.5
Policy Policies are saved in a policy database called the Secure Policies Database
(SPD). This database is indexed by selectors which are identifications of packets. Selectors can be a source address, destination address, name, protocol or upper layer ports [2]. These policies are consulted when an IP packet crosses an IPSec peer and results in an operation to be done on that IP packet. Such operations can be: drop, secure or remove security from packet.
1.2.6
Encapsulating Security Payload (ESP) ESP ensures data authenticity, integrity and confidentiality. ESP payload is
depicted in Figure 1.2.7.
9
Fig. 1.2.8. IPSec - ESP Payload
The fields are as follows: •
Security Parameters Index (SPI): (4 bytes) specifies the SA this traffic
belongs to. •
Sequence Number: (4 bytes) tracks the number of IP packets for anti-
replay purposes. •
Payload: (variable length) contains the actual data in the original IP
•
Padding: (0 to 255) padded to make the length of the plain text a
packet.
multiple of a certain number of bytes to satisfy the requirements of some encryption algorithms. •
Pad Length: (1 byte) specifies the length of the added pad.
•
Next Header: (1 byte) defines the protocol type of the data inserted in
the payload field. •
Authentication Data: (variable length) the integrity check value. Unlike
the AH, ESP integrity checking does not cover the IP header.
10
1.2.7
Authentication Header (AH) AH is used to achieve data authenticity and integrity. Figure 1.2.9 depicts the
AH header that is positioned between the IP header and the layer four protocol layer. The authentication data is a keyed hash calculated based on the IP payload and the IP header except the mutable fields such as the TTL.
Fig. 1.2.9. IPSec: AH Header
The fields that are different from the ESP header are:
1.2.8
•
Payload Length: (1 byte) indicates the length of the AH
•
Reserved: (2 bytes) currently unused, set to zeros.
Internet Key Exchange (IKE) SAs can be manually configured, yet it is a tedious job to manually configure
all IPSec peers. Thus an automated mechanism to negotiate SAs and distribute keys among peers is needed. IKE is the protocol made for this special purpose. IKE is based on the integration of two protocols: ISAKMP [5] and Oakley Key Exchange [6]. More on IKE can be found in [1].
11
1.2.9
Multi Layer IPSec (ML-IPSec) TCP performance enhancement proxy (PEP) mechanisms have been
proposed to enhance the performance of TCP networks especially over intermittent networks such as wireless networks. In PEP for example, intermediate nodes monitor the TCP layer and send explicit link failure notifications to the TCP sender. Another interesting feature is for these nodes to send premature acknowledgments to the sender and suppress any negative acknowledgments sent by the destination and later retry to send lost packets. PEP is not applicable when IPSec is implemented since access to the original IP and TCP headers is not possible due to the encryption applied by ESP. The solution proposed by ML-IPSec [3] is to divide the encrypted payload into regions and associate with each region a SA. For example, by giving different routers access to different zones, it is possible to give certain routers access to only TCP or IP headers. In this case, a zone will be the TCP header of the packet. A composite SA (CSA) will bind all zones in one secured traffic. A CSA will be established between two IPSec peers for them to communicate securely. For many reasons ML-IPSec is still considered inflexible particularly when used to build IP VPNs [4]. Such problems with ML-IPSec for example are: static byte ranges for zones, the need for configuration and prior knowledge about the routing path and establishment, keying and re-keying overheads. All these problems and suggestions to solve some of them are presented in [4].
12
1.3 Secure Sockets Layer (SSL) 1.3.1
Overview SSL was originally developed by Netscape. Starting version 3, the protocol
was made public and it was later published as an Internet draft proposal. Later on, the Transport Layer Security (TLS) working group was formed within the IETF to develop a standardized version of SSL. Mainly, the TLS can be considered as SSL v 3.1 and is fully backward compatible with SSL v 3. TLS has the ability, when interacting with a legacy SSL v3 endpoint, to back down to version 3 and to fully operate as an SSL v 3 entity. SSL is transparent to the application since it resides between the underlying TCP protocol and the application. SSL is applicationindependent, yet it has been tuned and enhanced for HTTP and FTP. Most of today’s Web browsers and Web server applications are equipped with SSL. HTTP over SSL can be identified by the prefix “https://” that is used in the URLs for any secure Web interaction. The rest of this section is devoted to SSL v3 which is the de facto standard for Web security today. This section is organized as follows: Section 1.3.1 discusses, in detail, the SSL protocol architecture. This section discusses SSL Session, SSL Connection, Digital Certificates, Record Protocol, Change Cipher Protocol, Alert Protocol and the Handshake protocol. Finally, Section 1.3.2 discusses a light weight version of SSL, called KSSL.
13
1.3.2
SSL Architecture
Fig. 1.3.1. SSL Protocol Stack
SSL is not just one protocol; rather it can be seen as a suite of protocols that provide an end-to-end secure TCP connection. SSL can be divided into two layers of protocols. On the lower level, and directly above the underlying protocols, sits the SSL Record protocol. On a higher level, there are three SSL protocols that ensure the connection initialization, maintenance and termination. These are: SSL Handshake, SSL Change Cipher Spec and SSL Alert protocols (see Figure 1.3.1). Two main entities ensure the secure connection between two SSL endpoints. These are the SSL Connection and the SSL Session. Many connections can be associated with one session. Sessions are initiated by the handshake protocol. This initiation procedure is costly in terms of computing power and typically involves public key interaction and certificates exchange. This is why these two concepts, the SSL connection and session, were introduced, as they considerably reduce the time and processing resources used for establishing new connections. The session, along with all its variables, can be reused many times. When a new connection is being
14
established, the two communicating parties have the option of reusing an already available open session’s variables. Both ends have the right to reset the session at any point in time if secret keys were thought to be compromised. From a Web point of view, this session variables’ preservation capability is very crucial and efficient since Web traffic is bursty in nature and it encompasses many simultaneous connection establishments even when fetching a normal Web page with all its images and other dependencies. One more concept that firmly relates to SSL is digital certificates. Digital certificates are used to identify people and resources on the network or the Internet.
1.3.2.1 SSL Session [7] SSL sessions can be identified by the following parameters: •
Session identifier: an identification random number chosen by the
server at the session establishment stage to be used later to refer to the session. •
Is resumable: indicates whether the session can be reused in further
communication between the client and the server. •
Peer certificate: an X 509.v 3 certificate related to one peer and can be
•
Compression method: algorithm to be used to compress data before
null.
encrypting it. •
Cipher spec: defines the encryption and hashing algorithms used along
with its attributes. Available options are for example DES for encryption and MD5 or SHA-1 for hashing. •
Master secret: 48-bit long key shared between the server and the client.
15
1.3.2.2 SSL Connection [7] SSL connections can be identified by the following parameters [8]: •
Server and client random: byte sequence chosen by the server and the
client for each connection. •
Server write MAC secret: secret key used in MAC operations on data
written by the server. •
Client write MAC secret: secret key used in MAC operations on data
written by the client. •
Server write key: the bulk cipher key for encrypted data by the server
and decrypted by the client. •
Client write key: the bulk cipher key for encrypted data by the client
and decrypted by the server. •
Initialization vectors: This field is first initialized by the SSL handshake
protocol when a block cipher in CBC mode is used. Thereafter, the final cipher-text block from each record is preserved for use with the following record.
1.3.2.3 Digital Certificates Digital certificates [9] are electronic documents used to identify people and resources over networks such as the Internet. This gives the ability to secure communication between two entities using encryption and integrity checking based on public key techniques. Each certificate must be issued by a Certification Authority (CA) that signs the certificate and makes sure that it has not been tampered with. Once the CA signs the certificate, the holder, e.g. a user or a Web server, can present their certificate to other entities as a proof of identity. Later, secure communication
16
can be established using encryption and hashing techniques after key management procedures. Certificates usually contain information about the holder entity and the issuer CA such as: •
Name and other needed identification information such as URL and
email address.
1.3.2.3.1
•
The holder’s public key used for encryption.
•
The name of the CA that issued the certificate.
•
A serial number to identify this certificate.
•
Validity period including start and end date.
•
Signature to make sure that the certificate has not been tempered with.
Certificates in SSL SSL certificates are used to identify resources and people on the network.
These certificates are widely used in making sure that Web sites are secure and genuine especially in e-commerce applications. Authentication of clients is optional in SSL and is done when the server requires clients to be authenticated. Certificates should be checked in the initialization of any SSL communication. The following is a list of steps that SSL entities must go through when initializing a new session such when browsing a secure Web site: 1. A client connects to trusted Website by using a URL prefix “https://”. 2. Website authenticates itself by presenting a certificate. 3. The client checks signature, CA and validity of the certificate to determine if it should trust the certificate. To trust the CA, the client must make sure
17
that the issuer CA is in the browser’s database or that the certificate has been cross certified by a root whose certificate is in the browser’s database. 4. If the client’s browser decides to trust the server, it generates a one-time, unique session key and encrypts it with the server’s public key. Then it sends the encrypted key to the server. 5. The server recovers the secret key by decrypting the message using its private key. 6. Symmetric encryption communication starts between server and client using the recovered secret key. Usually the certificates are obtained from CAs for annual fees after presenting identification documents by the applicants.
1.3.2.3.2
Subscriber Authentication: CAs, when receiving requests from clients for new certificates, go through a
long process to make sure of the identity of the requester. The CA checks the following: 1. Domain name: the certificate applicant has the right to use the domain name. 2. Authentication of organization: the requesting organization has the legal right to use the organization name. 3. Authorization of requester: the certificate request is made by an authorized representative of the organization.
18
1.3.2.4 SSL Record Protocol SSL Record protocol provides data confidentiality and integrity. The handshake protocol defines the secret key to be used in encrypting the payload for data confidentiality. In addition, the handshake protocol is responsible for defining secret keys that will be used later for generating message authentication code (MAC). As shown in Figure 1.3.2, the record protocol first receives the data from the upper SSL layers or the application layer and fragments it into pieces of 216 bytes or less. Then lossless compression takes place using the algorithm defined by the handshake protocol. MAC is added to the message in this stage. Later, the message is encrypted using the secret key and the encryption algorithm defined by the handshake protocol. Finally, SSL record header is added which includes information such as the SSL version. Moreover, the header contains the plain-text length before compression for the decompression process.
Fig. 1.3.2. SSL Record Protocol Operation
19
1.3.2.5 Change Cipher Protocol This protocol uses the SSL record protocol and consists of a single message that contains one byte. This byte causes the pending state to be copied to the current state. This message is used when one peer wants to change the cipher settings used in the connection. The two communicating parties must send this message for the new settings to be activated.
1.3.2.6 Alert Protocol This protocol is used to convey SSL-specific alerts. These alerts have a level of either “warning” or “fatal”. When a fatal alert is sent, the connection is terminated directly and no more new connections to the same session are allowed. These alerts can be for example a “certificate_expired” or “close_notify” alert. The latter must be sent by the two peers in order to close a SSL connection.
1.3.2.7 Handshake Protocol When an SSL client and server first start to communicate, they agree on a protocol version, select cryptographic and compression algorithms, optionally authenticate each other, and use public-key encryption techniques to generate secret keys. The SSL handshake protocol is responsible of all the above mentioned tasks. In other words, the handshake protocol is responsible for setting a set of connection and session variables. This procedure is depicted in Figure 1.3.3. In phase 1, the client initiates a logical connection to the server by sending a “Client Hello” message to which the server must respond with a “Server Hello” message. These two messages define the following attributes: protocol version, session ID, cipher suite and compression method. Moreover, two random values are generated
20
and exchanged: Client Hello Random and Server Hello Random. If both peers agree to continue an already open session, a “Finished” message is sent and the secure communication starts after a short handshake operation. Later, in phase 2, the server sends its certificate if it is to be authenticated. The server might later require the client to be authenticated as well in the “Certificate Request” message. Finally the server sends the “Hello Done” message. In phase 3, and if the server asks for client authentication, the client must send either a “Certificate” message or a “No Certificate” alert. “Client Key Exchange” depends on the public key algorithm used. If the client has sent a certificate with signing ability, a digitally-signed “Certificate Verify” message is sent to verify the certificate. Both server and client agree on an encryption algorithm and key secrets in phase 3. Consequently the pending state is copied to the current Cipher Spec. At this point, the handshake is complete and secure communication starts.
21
Fig. 1.3.3. SSL Handshake Protocol
1.3.3
KSSL Despite its success in securing Internet applications, SSL, in some of its
parts, is too compute and memory-intensive for wireless devices, thus Sun Microsystems has developed a light-weight SSL implementation called KSSL [10] which is a client-side implementation of SSL version 3.0, supporting the RSA-RC4128-MD5 and RSA-RC4-40-MD5 cipher suites.
22
The main concept behind KSSL is represented in reusing previous session results such as certificate parsing results and master secrets, so as to avoid repeated SSL handshakes. This helps in avoiding complex, resource-intensive public-key operations on the client device. Moreover, KSSL does not implement client authentication since it requires CPU-intensive private key RSA operations. In spite of the advantage provided by KSSL in securing mobile commerce applications, its performance is considered unacceptable when the client needs to communicate with different servers or when browsing sensitive content. This is due to the fact that in such cases the full handshake SSL operation needs to be carried out every time the client connects to a new Web server. The full handshake takes 10–13 s on a CDPD wireless network using a 20 MHz Palm PDA [10]. This performance bottleneck can be avoided when the client communicates with the same server repeatedly by performing an abbreviated handshake that makes use of the previous session’s certificate parsing result and master key, hence bypassing resource-intensive public key operations. However, storing the master secret and reusing it repeatedly in generating the symmetric ciphering keys raise some concerns about the security of this master key on the wireless device which can be easily snooped or stolen. This is a very important issue to consider since nearly all the security of SSL depends on keeping the master secret private. An attacker who knows the master secret can compute all the cryptographic keys that are used to protect the connection.
23
1.4 XML Security 1.4.1
Overview The Web is now used as the main information dissemination means both at
internal and external levels in an enterprise. This has lead to the need for a standard for information representation among different systems. XML (eXtensible Markup Language) was the answer for this need. XML is a platform-independent information representation standard based on tag entities that are contained in simple text documents that are both human and machine readable. Web services, a mechanism to exchange data based on XML and standard Web protocols, is nowadays the most used interface for businesses to communicate with each other. Web services have enforced XML as a general, multi-purpose and portable information exchange language. XML allows Web services to be technology-independent, and to hide the complexities and differences between systems to let them communicate in a free way. Due to this widespread use of XML, a need has risen for securing XML documents by applying known security techniques on XML documents. A comprehensive collection of XML Security literature is available in [22]. Securing XML documents entails addressing three main issues: authenticity, integrity and confidentiality. Authenticity helps in ensuring that the sender is really who he/she is claiming to be. Ensuring document integrity means ensuring that the content of the document has not been tampered with during transmission. Document confidentiality means that content of a document can only be disclosed to authorized entities according to certain access control policies. All the three main tenets of security demand the existing of a Public Key Infrastructure (PKI) to facilitate key management procedures. This leads to the need for digital certificates and Certification Authorities (CAs).
24
This section starts by an overview of document-based security in Section 1.4.2. XML Digital Signature and XML Encryption are presented in Section 1.4.3 and 1.4.4, respectively. Access control is discussed in Section 1.4.5 while XML Key Management Specification (XKMS) is introduced in 1.4.6. Finally, Section 1.4.7 shows some XML Security tools and other protocols.
1.4.2
Document-based Security [16] XML Security can be considered as a document-based security architecture.
Within the concept of document-based security, all security-related attributes and security sessions are preserved inside the document. A logical security session is created within the document that has a long life and allows for multiple parties to be part of a single session. An upcoming protocol for Web Services, the Business Transaction Protocol (BTP) [17], relies on the same concept of preserving securityrelated attributes in the document.
1.4.3
XML Digital Signature [13] Several approaches for realizing digital signatures were suggested, all trying
to fulfill common requirements. The European Parliament and the Council of the European Union define digital signature as follows [11]: An advanced electronic signature should meet the following requirements: a) it is uniquely linked to the signatory; b) it is capable of identifying the signatory; c) it is created using means that the signatory can maintain under his sole control; and
25
d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable;
For a user to sign any type of electronic document he/ she must have a unique private key. Usually this private key is used to encrypt the message authentication code (MAC) or message digest for the signature to be a function of the sent document. Digital signatures need a key management system to maintain and secure pairs of public and private keys. However, signing XML documents imposes more requirements compared to textual documents due to the richer document structure that XML offers. For instance, XML offers a rich way to identify data that is based on tag elements, thus XML digital signatures should be able to be done at the tag level. The XML Digital Signature Working Group [20] in conjunction with IETF is working on standardizing XML digital signatures. The goal is to provide a way in XML to represent digital signature. This standard does not specify XML as the data object to be signed, yet it is particularly suited for XML documents.
26
( ()? )+ ()? ()*
Fig. 1.4.1. XML Signature structure
An example on an XML signature is shown in Figure 1.4.1 and more details on elements of an XML digital signature are provided in Table 1.4.1.
27
Table 1.4.1. Specification of XML Signature Elements (Originally from [12]) Element
Specification
Signature
The root element of the XML Signature
SignedInfo
Contains all information about the signed data and additional information necessary for signature validation
CanonicalizationMethod
It specifies the algorithm used for the generation of the canonical form of SignedInfo
SignatureMethod
It specifies the algorithm used for the signing of the SignedInfo element
Reference
One for each data object to be signed. It contains attribute URI, identifying the data object being signed
Transforms
It contains a list of ordered transformations applied by the signer to the data object
DigestMethod
Specifies the algorithm used for the generation of the digest value of the data object
DigestValue
Contains the digest value of the data object
SignatureValue
Stores the digital signature of the whole SignedInfo element
KeyInfo
Stores additional information enabling the recipient to obtain the keys for signature validation
Object
An optional element, storing the data object, in case of enveloping signature
28
Three different localization options [12] are available in the standard: •
Enveloping Signature: The data object is contained in the Object
element. In this case the object is part of the Signature element. •
Enveloped Signature: The data object encloses the Signature element.
Thus, the Signature element is inserted into the XML document containing the data object being signed. •
Detached Signature: The data object is either an external data object, or
a local data object included as a sibling element in the XML document containing the Signature element.
1.4.3.1 XML Canonicalization [21] XML encryption defines a selective and flexible way to encrypt XML documents and other non-XML data objects. When encrypting XML documents, a problem arises that is not applicable to other binary or textual content. This is due to the fact that rules for XML authoring are flexible in the sense that the same document structure and the same piece of information can be represented by different XML documents. This leads to different digital signatures for the same document. XML canonicalization is the work-around to solve this problem. The purpose is to find the logical equivalence of an XML document in a way that the same information represented in different XML documents produces the same logical equivalence. W3C has defined canonicalization rules such that the canonical form of two XML documents will be the same if they are logically equivalent. More on XML canonicalization can be found in [21].
29
1.4.4
XML Encryption Traditional encryption techniques, such as those applied in SSL, encrypt
blindly everything in a document or session interaction which might not be very convenient in securing Web traffic. Taking SSL for example, the following are two main unaddressed areas: •
Encrypting part of the data being exchanged
•
Secure sessions between more than two parties
Selective encryption is a very important necessity in securing Web traffic since the sensitive information that should be secured usually represents just small parts of a Web document. XML encryption has the ability to encrypt at the level of a tag element. Still this might not be enough in some scenarios especially when big text elements exist. A good example to show the importance of selective encryption is an XML document that contains different sections authorized to different users according to an access control policy. Each part of the document, and according to the user that it is authorized to, would be encrypted with a key. In this case, each user can only see the part that he/ she is authorized to access. Due to the increasing importance of the topic and the prevalence of XML, W3C has created an XML Encryption Working Group [14], whose aim is to define a selective encryption mechanism for XML digital content. The goal of this working group is to have a more selective and flexible way of encrypting digital content on the Web. XML encryption can handle both XML and non-XML (e.g. binary) data which makes XML encryption very convenient for a context like the Web where data of different types are part of a single page.
30
1.4.4.1 XML Encryption Methods XML encryption offers different options to encrypt a document. To explain these options an example is presented in the following section which is taken from [15].
1.4.4.1.1
Example Assume that it is required to secure the following simple XML document
(see Figure 1.4.2)
book 123-958-74598 12 123654-8988889-9996874 visa 12-10-2004
Fig. 1.4.2. Example: Original XML document
Different options are allowed in XML encryption: encrypt the entire document (see Figure 1.4.3), encrypt a tag (see Figure 1.4.4) or encrypt the content of a certain element (see Figure 1.4.5). Figure 1.4.6 demonstrates encrypting non-XML data.
31
A23B45C56
Fig. 1.4.3. Example: Encrypting the entire document
book123-958-7459812 A23B45C564587
Fig. 1.4.4. Example: Encrypting the tag
32
book 123-958-74598 12 A23B45C564587
visa 12-10-2004
Fig. 1.4.5. Example: Encrypting the content of the CardID element
A23B45C56
Fig. 1.4.6. Example: Encrypting arbitrary non-XML data (JPEG example) 33
1.4.5
Access Control Access control is about specifying which subjects can access which objects.
After stating access control policies, they are enforced by the access control mechanism. Developing an access control mechanism tailored for XML poses special requirements that have to be considered. These requirements can be briefly summarized in the following Section.
1.4.5.1 Access Control Requirements for XML Security XML access control mechanisms should possess the following characteristics: •
Content-based: Simply put, XML security access control objects should
be able to be identified based on a document’s content including both structure and type. •
Selective and differentiated: XML documents may have nested or
hierarchical structures. Moreover, XML documents are usually inter-linked through references. Different elements, structures or sub- or super-structures may have different security requirements. XML access control must address all these selective identification methods. •
Intensional: XML documents may have Document Type Definition
(DTD) or XMLSchema specifying their structures. XML access control mechanisms must exploit this intensional description and be able to identify objects based on their intensional description. For example, it is possible to define a policy at the DTD level and apply it to several XML documents to enforce a specific security policy. •
Specifying subjects by means of credentials: Security policies based
on the notion of credentials are required in XML control access since many users
34
might be accessing an XML document. Based on the credentials of the user the access control mechanism must decide whether to grant access to the requester or not.
1.4.6
XML Key Management Specifications (XKMS) [23] The XML Key Management Specification (XKMS) [23] defines standards
for public key management services. Public key management features the creation of a public and private key pair, the binding of this key pair with identity and other attributes. Key management is an essential component of any security mechanism. This applies to all aspects of XML Security: XML Digital Signature, XML Encryption, and access control mechanisms. XKMS defines XML message formats to support requests and responses for public key management, including registration, revocation and updates. This protocol does not require any particular underlying public key infrastructure (such as X.509 [25]) but it is designed to be compatible with such infrastructures.
1.4.6.1 XKMS Specifications XKMS consists of three main specifications. These specifications define the XML request and response message model required for registering and managing information associated with public keys and for making sure end-to-end security is preserved. These specifications are: •
XML Key Information Service Specification: Supports the delegation
by an application to a service of the processing of key information associated with an XML Signature and XML Encryption. •
XML Key Registration Service Specification: Supports the registration
of a key pair by a key pair holder, with the intent that the key pair is subsequently
35
used in conjunction with the XML Key Information Service Specification or any public key infrastructure such as X.509 [25]. •
Protocol Bindings: Define mechanisms for meeting security
requirements, including mechanisms to ensure message confidentiality, integrity, and security. More information and examples on XKMS can be found in [23] and [24].
1.4.7
XML Security Tools and other Standards In this Section we review some XML tools and other standards that are built on top of XML. These are Author-X, IBM Alpha Works XML Security Suite and SAML.
1.4.7.1 Author-X [12] Author-X provides a comprehensive environment for the specification, administration and enforcement of access control policies for XML documents. More information about Author-X can be found in [12].
1.4.7.2 IBM Alpha Works XML Security Suite [19] From [19], “XML Security Suite is a tool that provides security features such as digital signature, encryption, and access control for XML documents. These features are beyond the capability of transport-level security protocols such as Secure Sockets Layer (SSL)”. The included technologies in XML Security Suite are: •
Digital signature implementation based on XML Signature Syntax and
Processing by W3C/ IETF.
36
•
XML encryption implementation based on XML Encryption Syntax and
Processing by W3C. •
XML Access Control Language and implementation.
1.4.7.3 Security Assertion Markup Language (SAML) [18] From [18], SAML is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (such as a human user) to other entities, such as an enterprise application. Federated identity allows a set of service providers to agree on a way to refer to a single user, even if that user is known to the providers in different guises. Most commonly, federated identity is achieved through the linking together of the user's several accounts with the providers. In practice, this means that users can be authenticated by one company or Web site and be recognized and delivered personalized content and services in other locations without having to re-authenticate or sign on with a separate username and password. Web SSO (Single Sing-On) can be an example where SAML can be used. In Web single sign-on, a user authenticates to one Web site and then, without additional authentication, is able to access some personalized or customized resources at another site. Microsoft’s .Net passport is an example of a Web SSO. SAML’s main advantages are: Platform neutrality; loose coupling of directories - thus no need for synchronization between directories; improved online experience for end users and reduced administrative costs for service provides.
37
1.5 Comparison The security solutions at the three layers (Application, Transport and Network) and other solutions at the data link layer are not in competition with each other. Rather, each one plays a role in providing overall security for information systems. This is due to the fact that each solution has many advantages and some disadvantages. Thus, it is very important to exploit the strengths of each while minimizing its drawbacks. The real business requirements are the main criteria based on which the decision of which solution to use can be made. Nevertheless, in many scenarios a hybrid model is the most suitable solution. But, with the shift nowadays from desktop to handheld wireless computing and due to the fact that new networks and protocols are being developed continuously, standardized application security systems might offer the most convenient and flexible solution.
1.6 Thesis Organization The remainder of this thesis is organized as follows. Chapter 2 overviews the work done within the security group in the ECE department at AUB on the “Policybased Wireless Security Enterprise Engine”. Chapter 3 presents PRIDE with its design and mathematical model. In addition, Chapter 3 attempts to verify the model through implementation results. Chapter 4 presents suggested applications that use PRIDE’s Web security engine. These are ODYSSEY and SmartSSL. Finally, Chapter 5 concludes with a summary of the thesis work and ideas for future work.
38
CHAPTER 2 PREVIOUS WORK
2.0 Previous Work 2.1 Introduction Wireless enterprise applications usually operate over low bandwidth networks with high latency and frequent disconnections, using wireless devices that vary greatly in capabilities and resources. This makes today's enterprise applications very assorted in requirements, configurations, and resources and necessitates that the security protocols used in securing such applications be designed specifically for operation in such diverse environments. These security protocols must address the needs of a huge variety of client devices which maybe severely constrained in terms of processor speed, memory resources, and storage capacity. This diversity makes the implementation of a unique security standard that encompasses the whole device range infeasible. A least-common denominator security standard that targets devices with limited memory and slow processors would be unfair for powerful devices and would not meet their security requirements, and in the same sense, a security standard that addresses high-end devices would neither fit nor perform efficiently on limitedresource devices. What is needed is a security protocol that can be customized and configured to perform the security operations flexibly, taking into consideration the memory capabilities and the processing power of the device, the wireless network latency, and the specific requirements of the enterprise application. This ensures the efficient operation of the same application on a wide range of devices and wireless networks. Moreover, this protocol must be extensible, scalable and capable of evolving to meet new challenges and to adapt to new application requirements. 39
PRIDE is a Web security protocol targeting wireless limited devices that is built on top of the security engine developed by the security group in the ECE department at the American University of Beirut. The security engine is a policy- and content-based security framework for wireless limited devices. This security engine was previously implemented in other applications than PRIDE that are presented in this section. The first protocol, PATRIOT [26], is an optimized security architecture for safeguarding audit log files on wireless devices. The second protocol, ESCORT, is an enterprise, policy-based security protocol for protecting relational database network objects. PATRIOT, ESCORT, and PRIDE secure enterprise data based on content and sensitivity and highly surpass the performance of bulk encryption protocols such as the Secure Socket Layer (SSL) protocol and the Transport Layer Security (TLS) protocol (see Section 1.3) by utilizing a customizable, policy-based security architecture. This policy-based architecture makes use of the structure of enterprise data objects (log files in PATRIOT, database objects in ESCORT and Web pages in PRIDE) to provide flexible, multi-level, and fine-grained encryption and hashing methodologies. This makes these protocols a very efficient choice for operation in wireless enterprise environments characterized by low-bandwidth wireless networks and supporting limited-resource wireless devices with low memory and processing power. PATRIOT, ESCORT, and PRIDE are designed in a platform-neutral manner and can operate on a wide range of wireless clients and enterprise servers. This chapter is organized as follows: Section 2.2 gives a general introduction to the design of the security protocol along with its features and characteristics. Section 2.3 presents two main applications where the security engine has been applied
40
and through implementation demonstrated high performance enhancement over other bulk encryption protocols.
2.2 Security Protocol Design This section provides a very brief overview of the common design and architectural features of the three security protocols: PATRIOT, ESCORT, and PRIDE. These protocols operate on the client and server sides by seamlessly employing a Security Engine component to transparently control the enterprise data encryption/decryption operations. The Security Engine is the component responsible for taking security decisions and carrying out security-related operations to secure the enterprise data objects. The security services supported by the Security Engine component are controlled and configured based on the information present in a policy configuration file which provides the primary information source that the Security Engine consults for taking security decisions at runtime. The three protocols presented utilize a policy-based architecture which specifies the security behavior and operation of the enterprise security system. The source information of the security policy is present in a secure repository on the server side and its high-level representation is configured by a company authority or a security administrator. The security policy consists of two main parts. The first part specifies a set of security-related attributes and configuration parameters, while the second part identifies the scope and strength of the encryption and hashing operations to be applied on the enterprise data. The security-related attributes and configuration parameters specified in the first part are protocol dependent; examples of some commonly used attributes include: the encryption algorithm used by the protocol, the hashing algorithm, the key management algorithm, the ciphering key life time …
41
These security attributes are required by the Security Engine component on the client and server to control the confidentiality, integrity, and key management operations. The second part in the security policy controls the level and scope of the security operations to be applied on the enterprise data object. In other words, the second part specifies the selectors for data confidentiality and integrity along with the security level that should be applied. According to this specification, the security of every data object belongs to one of three security modes: A Secure_All mode: this mode states that all the contents of the object must be secured, and specifies the strength of the encryption to be applied on this object. Four encryption levels are supported by the security engine: a High_Security level which is equivalent to 256-bit AES encryption (By AES encryption we mean an encryption complying with the AES standard as provided by the National Institute of Standards and Technology (NIST) and we don’t specify the Rijndael algorithm itself); a Medium_Security level which is equivalent to 192-bit AES encryption; a Low_Security level which is equivalent to 128-bit AES encryption, and a No_Security level which represents no encryption on the field. A Secure_Range mode: this mode specifies the field sections to be secured in byte ranges together with the level of security to be applied on each range. The term “byte” in this context doesn’t represent a physical unit of data storage but rather a logical unit whose specification depends on the representation of the data being secured. This logical and generic representation is very essential since it allows the specification of these ranges without any dependency on the data encoding mechanism and representation. A Secure_None mode: this mode states that the data must be processed as is without any encryption or integration checking.
42
Not all the network and log entities generated by the enterprise system will be treated in the same way by the Security Engine. The security policy introduces the concept of policy-based classes. According to this concept, every object will be secured depending on the policy class it belongs to. The policy class membership criterion is based on one of the fields of the produced enterprise objects satisfying a particular regular expression or a certain file type (in case of entities being files). This criterion might differ from application to application. If the produced object doesn’t satisfy any of the policy classes specified in the security policy, it will be secured based on a default policy class. Figure 2.1 illustrates a sample of PATRIOT’s high-level policy configuration store:
43
Encryption_Algorithm: Rijndael Hashing_Algorithm: SHA-1 Trusted_Server_URL: fea.aub.edu.lb Key_Management_Algorithm:DH Secure_Log_URL: c:/system/securelog/securelog.txt Field_Count:3 Field_Separator: TAB //End of part 1, start of part 2 Log_Class_1 (Field1==regular expression 1) { Field1 { Encryption: Secure_None //Secure_None mode Integrity_Enforcement:No //field1 of log records belonging to this class // will not be included in the hash chain } Field2 { Encryption: //Securing byte //ranges Integrity_Encforcement: Yes } Field3 { Encryption: Integrity_Enforcement:Yes } } // end of Log_Class_1 Default_Log_Class
. //default log class for log records not satisfying any log //class
{ Field1 { Encryption: Secure_All Integrity_Enforcement:Yes } Field2 { Encryption: Secure_All Integrity_Enforcement:Yes } Field3 { Encryption: Secure_None Integrity_Enforcement:No } } // end of Default_Log_Class
Fig. 2.1 Example of PATRIOT’s policy
It should be noted here that the protocols leave the issue of resolving any conflict, which may arise if an enterprise entity satisfies two different policy classes, to the implementer. That is, the implementer may assign the enterprise object to the first policy class it satisfies in the policy configuration, to the default policy class, or in any other implementation-specific way. In PRIDE for example, if part of a Web
44
transaction belongs to more than one class, the highest security level of the two classes will be applied. The Security Engine is the component responsible of securing the integrity and confidentiality of the enterprise data object on the client and server platforms. It carries out a secure authentication and key agreement mechanism with the trusted server at system startup. This allows the client device and the database or application server to validate each other’s identities and to share the Source Key (SK0). SK0 is the source key that will be used by the Security Engine to derive the encryption keys for securing the confidentiality of the data object.
2.3 Implementation and Performance Analysis Due to the large number of enterprise configurations and the diverse nature of the hardware and software components used in building these components, the implementation of the security protocols used an extensive set of development tools, hardware and software patterns, programming languages, and networking protocols to prove its platform-independence as well as its ability to operate efficiently and flexibly on various computing architectures. This section sheds light on the implementation details and the performance results obtained.
2.3.1
PATRIOT Overview [26] PATRIOT is an optimized, policy-driven security architecture for protecting
the confidentiality and integrity of audit log files on wireless devices. PATRIOT is based on a set of well-known cryptographic protocols and is designed to suit the limited nature of wireless devices. It offers a policy-driven, customizable security model and specifies a flexible, multi-level, and fine-grained encryption methodology
45
that provides the suitable security strength without compromising performance. PATRIOT is designed in a platform-neutral manner and it can be deployed on a wide range of wireless devices and operating systems.
2.3.2
PATRIOT Implementation A sample simulation implementation for PATRIOT was developed for an HP
iPAQ rx3115 Pocket PC device with a Samsung S3C 2440 processor (300MHz) and 56 MB of RAM. The .NET Compact framework 2.0 runtime running on top of Windows Mobile 2003 is used. A log file of around 900 records each consisting of three fields is used. The total size of the log file is 890 KB. These fields are: date, time and description of the event that is to be logged. In the tests, the classes are being distinguished based on date or time patterns. For example, one class might be for events that happens in a certain month of the year because of the sensitivity of operations that are undertaken yearly in that specific month, such as the yearly budget revision for an organization. The comparison is made with a traditional security system that secures the log file by encrypting all its contents. In this method the whole record is encrypted and hashed. One thing to consider is the parsing time of the policy, which does not exist in the traditional logger. This process, the reading of the file and parsing the policy, took in the environment discussed above around 370 milliseconds total. This is done one time at the starting-up of the system. Clearly, it is not a real deficiency for the policy driven system since it happens once at startup. For the traditional security method, two cases are studied: securing the log on record basis or on field basis. Table 2.1 presents some performance measurements conducted on both the traditional security mechanism and the policy-based security system for around 900 records. The
46
traditional method was undertaken in Medium level security (192-bit key) while the policy based approach is adaptive. For each class of records, each field or even part of a field can be secured with the four previously discussed security levels. The hashing rate was found to be 1085.9 kbps. From Table 2.1 it is possible to notice clearly the improvement that is achieved by just encrypting/ decrypting what is really needed to be secured. Policy-based numbers differ slightly depending on the policy being used. In general, the results show an improvement of 48% over the field basis method and 31% over the record basis encryption.
2.3.3
ESCORT Overview ESCORT is an efficient end-to-end security architecture that ensures the
confidentiality and integrity of database objects flowing over network links between the Enterprise Information System (EIS) layer represented mainly in relational database servers and the client layer represented by a large variety of devices with diverse capabilities and resources. ESCORT is designed to provide the suitable security strength for a wide range of enterprise application configurations without compromising the application's efficiency and performance. It secures data based on content and sensitivity and highly surpasses the performance of bulk encryption protocols such as the SSL protocol and the TLS protocol by utilizing a customizable policy-based security architecture. This policy-based architecture makes use of the relational structure of database objects to provide flexible, multi-level, and finegrained encryption and hashing methodologies that target the field level in the database result object. Moreover, ESCORT's security policy can be configured to hit the bytelevel granularity in securing individual database fields. This makes ESCORT a very efficient choice for operation in wireless enterprise environments characterized
47
by lowbandwidth wireless networks and supporting limited-resource wireless devices with low memory and processing power. ESCORT neither deals with the security of static data in the database store nor requires the encryption of database objects at the storage level. This makes it transparent to the normal database server's processes such as update, delete and query operations, and eliminates any data access overhead at the storage level. ESCORT is designed in a platform-neutral manner and can operate on a wide range of database servers and client devices.
2.3.4
ESCORT Implementation ESCORT implementation and tests were performed on Linux and Windows
servers, running Oracle and SQL Server, respectively, as shown in Table 2.2. Client platforms included Linux, Solaris, and Windows, as shown in Table 2.3, and Windows Mobile and Symbian, as shown in Table 2.4. Tables 2.2 – 2.4 further show the hardware and software specifications of the servers and clients used in the implementation. The performance tests were carried out against an accounting database composed of 270 tables and views. The benchmarks used a large set of SQL requests including various table join operations and function and procedure calls. We maintained an average row size of 220 bytes. ESCORT's performance is compared to the traditional security approach represented in bulk encryption protocols that encrypt the whole database result. On the server side, ESCORT shows a performance gain of 250% to 350%, with an average of 280%. On the client side, the performance gain ranges from 230% on average on the limited clients (Table 2.4), to 330% on average on the PC clients (Table 2.3.)
48
Table 2.1. PATRIOT performance results Encryption Time
Encryption Rate
Encryption Time Per record
Decryption Time
Decryption Rate
Encryption Time Per record
Policy-based logger
22 sec
331.7 kbps
23.45 ms
38 sec
192.0 kbps
40.51 ms
Traditional logger (record basis)
32 sec
228.0 kbps
34.12 ms
58 sec
125.8 kbps
61.83 ms
Traditional logger (field basis)
42 sec
173.7 kbps
44.77 ms
80 sec
91.2 kbps
85.28 ms
Table 2.2. ESCORT database server implementation results
DBMS
Oracle 10g R2 Oracle 10g R2
Operating System
RedHat Linux Enterprise Server 4 Windows Server 2003 Enterprise Edition SP1
CPU
Pentium 4 2.2 GHz Pentium 4 2.2 GHz
SQL Server 2000 SP4
Windows 2000 Advanced Server SP4
Dual Processor Pentium 4 2×2.0 GHz
SQL Server 2000 SP4 SQL Server 2005
Windows Server 2003 Enterprise Edition SP1
Pentium 4 2.6 GHz
Windows XP SP2
Pentium 4 2.2 GHz
Average Number of Rows encrypted/Second (ESCORT approach) Java .Net .Net Runtime 1.1 2.0 1.5.0
RAM
DDR 266 MHz 512 MB DDR 266 MHz 512 MB DDR 266 MHz 2 GB DDR 333 MHz 512 MB DDR 266 MHz 768 MB
Average Number of Rows encrypted/Second (Traditional approach) Java .Net Runtime .Net 1.1 2.0 1.5.0
2505
NA
NA
1012
NA
NA
2418
2502
236 6
965
712
905
3116
2961
318 5
1211
1104
1186
2133
1907
208 8
754
612
682
2423
2355
249 4
897
721
917
Table 2.3. ESCORT desktop client implementation results Average number of rows decrypted/second (ESCORT approach) Java Runtime .Net 1.1 .Net 2.0 1.5.0
Average number of rows decrypted/second (Traditional approach) Java Runtime .Net 1.1 .Net 2.0 1.5.0
Operating System
CPU
RAM
Fedora Linux 4
Pentium 4 2.8 GHz
DDR 266 MHz 512 MB
4975
NA
NA
1387
NA
NA
Windows XP SP2
Pentium 4 2.2 GHz
DDR 266 MHz 768 MB
3877
2491
2722
1065
713
918
Windows XP SP2
Pentium 4 2.6 GHz
DDR 266 MHz 512 MB
3933
3744
3842
1257
1106
1292
Solaris 10 (X86 Edition)
Pentium 4 2.8 GHz
DDR 266 MHz 512 MB
4988
NA
NA
1415
NA
NA
49
Table 2.4. ESCORT mobile client implementation results
Operating System
Windows Mobile 2003 (second edition) Symbian OS 7 Symbian OS 7
CPU
Samsung S3C 2440 300 MHz ARM 9 153 MHz ARM 9 104 MHz
RAM
Average number of rows decrypted/second (ESCORT approach)
Average number of rows decrypted/second (Traditional approach) .Net Compact Java Runtime Framework MIDP/CLDC 2.0
Java Runtime MIDP/CLDC
.Net Compact Framework 2.0
56 MB
NA
182
NA
73
28 MB
110
NA
51
NA
6 MB
62
NA
27
NA
50
CHAPTER 3 PRIDE – POLICY-DRIVEN WEB SECURITY FOR HANDHELD WIRELESS DEVICES 3.0 PRIDE 3.1 Introduction This chapter gives an overview of the design and architecture of PRIDE on the client side, the server side, and on a proxy that is used to optimize the performance in trusted intranets. In addition a detailed overview of the implementation of PRIDE is presented in this chapter. An abstract view of the major components of the security architecture and their interrelationships is shown in Figure 3.1 and Figure 3.2, respectively.
Fig. 3.1. PRIDE high-level structure
51
Figure 3.2. PRIDE architecture and components on the client and the server sides
3.2 The Security Policy The Security Policy controls the overall security behavior of the applications protected by PRIDE. The policy configuration is stored in an XML-formatted document that is developed for each Web application secured by PRIDE. This policy is used by the Server Security Engine (see Figure 3.4) while a compacted version is used on the client side. XML is used as the definition language for the high-level Security Policy on the server-side. Some parts of this policy are sent to the client device; these parts are compacted in a binary compressed form before they are transmitted from server to client. This helps in reducing network traffic and avoiding any performance degradation one the client due to XML parsing, without sacrificing the flexibility of XML on the server side.
52
Fig. 3.3. Sample security policy
Web Server
Security Engine
Server-side Scripting Engine
Policy.xml
Fig. 3.4. Server-side Security Engine operation
The Policy Decision Point is a main component in the security system. It ensures that the policy configurations are applied on all Web traffic which the Security Engine is supposed to protect. The Policy is divided into two main parts (see Figure 3.3): the first part specifies security-related attributes and parameters, while the second deals with how security mechanisms are applied on the Web content. The security-related attributes control the behavior of the Security Engine for confidentiality, integrity and key management. Following is a list of these attributes: 1. encryption algorithm 2. hashing algorithm
53
3. key management algorithm 4. session-keys life time
The second part of the Policy is divided into two main sections. The first section specifies the security classes that are to be used by the Policy. These classes are a set of security specifications that can be applied later to different types of Web content. These security classes are characterized by the following attributes: 1. class name 2. security level 3. integrity enforcement 4. force over local networks
PRIDE supports three main security levels: a High Security level, equivalent to an AES [28] 256-bit key length; a Medium Security level, which is equivalent to an AES 192-bit key length; and a Low Security level, which is equivalent to an AES 128-bit key length. The integrity enforcement attribute in the Policy specifies if data integrity needs to be applied on the Web traffic. The “force over local” attribute, when set to true, forces the Security Engine running on a proxy server not to decrypt secured Web content destined to the local intranet. This is very important when critical Web data is transmitted to non-trusted local networks. The second part of the Policy deals with Web content. It specifies the security level and scope for each type of content, by either stating explicitly these security settings or by referring to a certain security class. Web content is identified using the following three mechanisms:
54
1. filename 2. regular expression
Filename can be any valid file name, an asterisk (*) specifies all files in the directory or a certain file type identified by a valid file extension. Regular expressions are used to match and secure sensitive patterns that appear frequently in Web traffic. The Security Engine, when finding a match, encrypts the entire HTML tag element where the match occurred. All these identification mechanisms help the Policy Enforcement Point to specify the encryption boundaries and security levels of the Web data stream.
3.3 Policy Loading and Compaction The policy information present in the policy configuration store is designed to be human-readable, given the nature of XML, so that it can be easily configured by users and system administrators using simple XML or text editors. Transferring this information as is over the network to the client device will not only produce unnecessary increase in network traffic, but will also increase the storage requirements due to the policy caching mechanism, and the processing load on the client due to the large number of string operations necessary to parse the policy. For this reason, PRIDE utilizes the Policy Compactor component, which is responsible for parsing the policy configuration file and converting it into a compact binary form to be cached for later use on the server. For the client, PRIDE does not send the policy as is to the client security engine. Rather, the client will get a table that will allow it to reconstruct the original HTTP response as was generated by the Web server. This compact binary table representation consists of a set of simple data structures that can
55
be easily processed by the client device without any need of parsing. Ensuring the integrity of the policy information over the network links must be given exceptional attention. PRIDE uses symmetrically-encrypted message digests to protect the integrity of the policy information when loaded over the network.
3.4 Policy Scope and Caching Policy resolving and caching is an important feature that is performed on the server and is handled by the Policy Loader. To be secured by PRIDE, each Web application has to have at least one policy store. Moreover, each sub-folder can have its own security policy that overrides the security policies inherited from the application-level policy. For greater administrative control, each Web server can have a machine-level security policy store that is applied on all Web traffic that the server processes. This gives administrators great flexibility and facilitates the process of securing new Web sites and ensures that no security leaks exist. For example, in an mcommerce Web server, the administrator may need to protect all credit card transactions against tampering and eavesdropping. This is done by adding a corresponding regular expression pattern key in the server-level policy store. Each policy resolving process refers to the following policy stores: machinelevel, application-level, upper-level directories, and to the directory’s own policy. This procedure does not impose an overhead on the system since, when the server Security Engine resolves a new policy, it compacts the resolved settings and caches them for later reuse. Caching improves the policy loading time by using a compacted binary copy of the security policy instead of parsing it every time it is requested. However, due to the possible modification of the policy configuration by administrators, a timed hash
56
is used to determine whether the policy information in the server cache is up to date or not.
3.5 Web Traffic Confidentiality and Integrity The Security Engine is the component responsible of providing data confidentiality and integrity based on the sensitivity of the Web traffic (see Figure 3.2). To support a flexible encryption scheme, PRIDE identifies the content to be secured in the security policy and provides a standard interface through which the Web server application, the Web browser and the Security Engine communicate and interact. Through this standard interface, the Security Engine abstracts the security operations and hides their complexity from the Web application. The Web application developer need not to be concerned with the specifics of security programming and is only required to supply the Security Engine with identification of the Web content to be secured, how this data is to be secured and to what degree. It is the responsibility of the server-side Security Engine (see Figure 3.4) to perform the encryption and hashing operations of the Web data and to construct the secure response based on the request coming from the Web server and the security policy. The Security Engine on the client-side accepts the secure response, performs the necessary decryption operations and integrity verification, constructs the original response message as sent by the Web server and delivers it to the Web browser. This is done based on the request mode in the security policy. Sending a secure post-back request form the client to the server follows the same procedure. In this case the client-side and the server-side Security Engines will switch roles and the security operations and their strengths will be based on the mode of the “post-back” interaction type in the security policy. It should be noted that the algorithm used by the Security Engine in constructing and delivering
57
the secure requests and responses depends on the security attributes in the policy store. The following procedures summarize the overall request/response model of PRIDE on the server and client sides. The server: 1. receives incoming requests from the client through the Web server application 2. coordinates with the key management server in order to initialize a new secure session 3. parses the policy store and resolves the security settings, if no cache exists 4. caches the resulted settings 5. forwards the requests to the appropriate Server Side Script Engine or to the operating system’s file system in case of static files e.g. HTML, pictures.. 6. gets the generated response from the Server Side Script Engine or the file system 7. applies confidentiality and integrity settings on the generated response 8. attaches to the response the necessary reference table of the encrypted data 9. flags the response as secured and identifies if the post-back from the client needs to be secured as well 10.
finally, it receives the encrypted post-back from the client, decrypts
and forwards it to the Server Side Script Engine.
A more detailed description of the Server Security Engine’s flow can be found in Figure 3.5.
58
New HTTP Request
No
Security Should be applied
Forward the Request to the Server Engine
Get Response from Server Engine
No
Yes Yes Forward Request to Server Engine
Content-based
Get Security Level Get Response from Server Engine Forward Request to Server Engine
Send Request to Client
Parse Response Get Response from Server Engine
Add PRIDE’s Headers
Formulate the Reference Table and Encrypted Data Table
Encrypt and Hash Response Remove Matches from Response
Add Reference Table and Encrypted Data
Figure 3.5. PRIDE’s Server Security Engine Flow
On the other hand, the client: 1. receives requests from the Web browser and forwards them to the destination host 2. waits for the response and checks for its security flag 3. forwards the response as it is to the Web browser, if security flag is not set
59
4. decrypts parts of the Web traffic and checks for its integrity based on the reference table, if security flag is set 5. sends the response as plaintext back to the Web browser 6. encrypts and sends post-backs that are to be secured based on the policy.
A more detailed description of the Client Security Engine’s flow can be found in Figure 3.6.
60
Send Request to a Page
Receive Response
Response Secured by PRIDE
No
No
Yes
Content-based
Yes
Get Security Level
Get Security Level
Decrypt Response
Get Reference Table and Encrypted Data
No Decrypt Data
Error Message and Warn the User
Integrity Check Succeeded
Add decrypted Data according to Reference Table Forward Response to Web Browser
Yes Formulate Original Response
Figure 3.6. PRIDE’s Client Security Engine Flow
Most of the intelligence of the client-side Security Engine can be moved to a Proxy Security Engine that resides on the local network and serves clients in a certain trusted intranet. This alleviates the load from the client machines especially in the case of limited devices, and boosts the performance of the whole security system. In case the secured Web traffic is flagged to force security over local networks, the
61
client-side security engine will have to take responsibilities again. This is the case when highly critical data is transmitted over a non-trusted local network. Another interesting feature of the server-side Security Engine is that it can act as a Security Gateway for the organization by receiving all the Web traffic and forwarding it after securing the parts that need to be secured to the local Web servers. In this case it is not necessary to modify the existing enterprise Web servers’ topology and architecture.
3.6 Mathematical Model This section presents a formal mathematical analysis of PRIDE’s performance. Most of the equations presented in this performance analysis are conducted in a platform-neutral manner without relying on any device hardware or operating system (unless specified otherwise in the text). In the rest of this section we will use the following notation: T is the size of the Web document in Kbytes; TN is the number of bytes representing the HTML textual tags composing the Web document; TS is the number of bytes representing script files (Javascript, DHTML, CSS, …) linked to the base document; TI is the number of image objects embedded in the Web document; TO is the number of dynamic objects (audio, video, Flash, Java applets, ActiveX, …) embedded in the Web document; µN represents the percent of HTML bytes encrypted; µS represents the percent of script bytes encrypted; ψ (i) is a flag indicating whether the ith image in the page is encrypted or not; ϕ (i) is a flag indicating whether the ith object in the page is encrypted or not; λI (i) is the size in Kilo Bytes of the ith image in the Web document; λO (i) is the size in Kilo Bytes of the ith object in the Web document; ET is the total number of bytes encrypted; µNH, µNM,
µNL are respectively the percentage of HTML bytes encrypted by the high, medium,
62
and low encryption levels based on the specifications of PRIDE’s security policy; µSH,
µSM, µSL are respectively the percentage of script bytes encrypted by the high, medium, and low encryption levels based on the specifications of PRIDE’s security policy; ψL (i), ψM (i), ψH (i) are respectively a set of flags indicating whether the ith image in the page is encrypted by the high, medium, and low encryption levels; ϕL (i),
ϕM (i), ϕH (i) are respectively a set of flags indicating whether the ith object in the page is encrypted by the high, medium, and low encryption levels; PDE is the percent decrease in encryption operations resulting from the use of policy-based encryption mechanisms; PHE is the percentage of bytes encrypted according to the high encryption level; PME is the percentage of bytes encrypted according to the medium encryption level; and PLE is the percentage of bytes encrypted according to the low encryption level.
3.6.1
Percent Decrease in Encrypted Bytes The percent decrease in encrypted bytes is given by:
PDE =
T − ET × 100 T
(3.1)
with
ET = µ N × TN + µ S × TS + TI
T0
i =1
i =1
∑ (ψ (i) × λI (i)) +∑ (ϕ (i) × λ0 (i)) TI
T0
i =1
i =1
and T = TN + TS + ∑ λI (i) +∑ λ0 (i)
(3.2)
(3.3)
It should be noted that the percent decrease in hash operations can be obtained in a similar manner.
63
3.6.2
Performance Gain In the previous section, we calculated the percent decrease in encrypted bytes
resulting from the use of content-based encryption mechanisms. In this section we will calculate the performance gain achieved due to applying multi-level, fine-grained encryption. We define WP to be: WP = µ NP × TN + µ SP × TS + i =1
(3.4)
T0
T1
∑ (ψ
P
(i ) × λI (i )) + ∑ (ϕ P (i ) × λ0 (i )) i =1
where the subscript P can take the values H, M, and L that correspond to high, medium, and low encryption levels, respectively. The percentage of bytes encrypted according to the high, medium and low encryption levels are respectively obtained follows: PHE =
WH × 100 T
(3.5)
PME =
WM × 100 T
(3.6)
WL × 100 T
(3.7)
PLE =
Let X, Y, and Z be the cost of an encryption operation using the low, medium, and high encryption levels respectively. This cost may be the number of CPU cycles to perform an encryption operation or the RAM footprint consumed by an encryption operation, or a function of both. It should be noted that the values of X, Y, and Z are platform-dependent but X < Y < Z since the complexity of encryption is proportional to the size of the encryption key. Assume that the traditional security approach of securing all Web traffic uses an encryption strength equivalent to the medium encryption level used in PRIDE; we define J=
PLE (i ) PME (i ) PHE (i ) PCP(i ) ×X + ×Y + ×Z + × CF 100 100 100 100
64
(3.8)
Where PCP is the percentage of content-based data to be parsed for sensitive data. CF is the complexity factor of the match to be performed on the Web traffic that is to be content-base encrypted. This can be for example the complexity of the regular expression used in parsing HTML files. The performance gain G, resulting from the use of content-based encryption mechanisms relative to the traditional approach will be given as follows: G=
Y−J × 100 Y
(3.9)
Considering a typical Web page with TN =15 KB, TS = 32 KB, and assume that we have 15 images with ψ (i) = (1,0,0,0,0,1,1,0,1,0,0,0,0,1,0) and 3 dynamic objects with ϕ (i) = (1,0,0). Let λI (i) (in KB) = (10,23,67,44,14,15,18,33,8,210,65,119,114,32,497)
λO (i) = (233,612,854) KB, µN = 0.3, µS = 0.1 ⇒ T = 3015 KB, ET = 323.7 KB ⇒ PDE = 89.26 % To find the gain G, we have to calculate PHE, PME, and PLE. Let
µNH = 0.05, µNM =0.05, µNL = 0.2; µSH = 0.01, µSM =0.02, µSL = 0.07; ψH (i) = (0,0,0,0,0,0,0,0,1,0,0,0,0,0,0); ψM (i) = (0,0,0,0,0,0,0,0,0,0,0,0,0,1,0);
ψL (i) = (1,0,0,0,0,1,1,0,0,0,0,0,0,0,0) ϕH (i) = (0,0,0); ϕM (i) = (0,0,0); ϕL (i) = (1,0,0) ⇒ PHE = 0.3 %, PME = 1.08 %, and PLE = 9.33 % From [27], Rijndael for example encrypts 20% slower for 192-bit keys and 40% slower for 256-bit keys. Assuming that X = 100 performance units, Y = 120 performance units and Z = 140 performance units, and assuming that CF=35-69 depending on the complexity of the regular expression use, we obtain PCP=2% ⇒ G = 86.4 - 87 %
65
The system will not provide any performance gain when the cost of parsing becomes very high compared to the cost of encryption. By setting G to zero in (3.8) we can estimate the value of CF that will cause the system to have zero gain for the given value of PCP (2%). In the above system, this occurs when CF=5400. This means that when the cost of parsing is almost 50 times higher than the cost of encrypting, the system will have the same performance as that of a bulk encryption system.
3.7 PRIDE Implementation PRIDE was designed in a platform-independent manner and its design features are optimized for implementation on a wide range of servers and wireless client platforms. An implementation of PRIDE was developed for a Pocket PC client device using the .NET Compact Framework 2.0 specifications and a server running Windows Server 2003. In this section, a brief description of the implementation along with the technologies, tools and devices used are presented. We begin by describing the server and the client environments. PRIDE’s server-side components were implemented on a Windows Server 2003 machine. The PRIDE server-side security engine was developed as an HTTP filter using IIS 6 and ASP.Net 2.0. This security engine is responsible of intercepting the incoming HTTP requests to the server and securing the responses according to a policy file that is specific to each Web folder. The responses are standard HTTP responses and viewing content-base secured pages in a standard browser will allow the user to see the unencrypted data; this means that the response’s PRIDE generates are well formatted HTML responses.
66
3.7.1
.Net Overview Microsoft .Net framework was built with security in mind. The framework
includes a wide range of features related directly or indirectly to security. Each component of the framework has its own security services. For managing user identity, Role-based security provides a unified model for authorization and authentication. Evidence-based security is responsible of enforcing trust and security levels on the running code. Web application security is the security mechanism taking care of Web forms security. As for protecting data that is transmitted across a network or stored persistently, cryptography is used.
3.7.1.1 Application Security: Best Practices To guide application developers to follow defense-in-depth principles, Microsoft uses a strategy nicknamed SD3 [33]. This stands for secure by design, by default and in deployment. The tenets of this strategy can be explained as follows: •
Secure by Design: Developers follow secure coding principles and
implement security features to offset potential vulnerabilities. •
Secure by Default: Applications that are secure by default assume that
most end users install the application without changing the default settings, and therefore require these users to specifically select features that might not be used or that might reduce security. •
Secure in Deployment: The application can be kept secure after
installation by updating it with security patches, monitoring it for attacks, and auditing it for abuse.
PRIDE is an example of the Secure by Design tenet of the SD3.
67
3.7.1.2 .Net Security The .Net framework provides out of the box implementations of many of the well known cryptographic algorithms. These implementations are easy to use and their properties are set to safest by default. In addition, a programmer can easily plug his/ her implementation of any cryptographic algorithm since the cryptography framework was designed to be extensible. Table 3.1 summarizes the main cryptography functionality that is provided by the .Net framework 2.0.
68
Table 3.1. Summary of .Net cryptographic capacities
Functionality Support for Symmetric algorithms
Details The .Net framework implements the following algorithms: - RijndaelManaged/AES - DES - RC2 - TripleDES
Support for Asymmetric algorithms
The .Net framework implements the following algorithms: - DSA - RSA
Support for Hash algorithms
The following hash algorithms are supported: Non-keyed: - MD5 - SHA1 - SHA256 - SHA384 - SHA512 - RIPEMD 160 (.Net v2.0) Keyed: - HMACSHA1 - HMACSHA 256/ 384/ 512 (.Net v2.0) - HMACRIPEMD 160 (.Net v2.0) - MACTripleDES
Support for Digital Signature
The framework provides two classes that support generating and verifying digital signatures.
69
Notes AES is the only fully managed symmetric algorithm and hence is the favorable choice. RC2 is essentially DES but with a variable key size [33]. The framework also supports two padding schemes to be used by the RSA algorithm to protect against attacks that rely on the unencrypted text being simple [33]. Keyed algorithms are those that use a key (agreed upon by the sender and receiver) to encrypt and hence protect the hash against modification [33].
.Net also provides a way in which you can create a digital signature in an XML document; which would greatly simplify the storage and transfer of digital signatures [33].
3.7.1.3 IIS and ASP.Net Link ASP.Net (Active Server Pages) is the server-side engine scripting technology of the .Net framework. ASP.Net contains the System.Web namespace of the class library of .Net. This namespace encompasses all Web-related objects such Web Controls and other HTTP objects. IIS is the Web server for windows servers and ASP.Net. IIS receives requests from clients and server static requests and forwards dynamic requests each to the equivalent server-side engine or ISAPI executable depending on the requested file extension. IIS maintains, in its metadata, a table that links file extensions to appropriate ISAPI executables. The ASP.Net executable agent is aspnet_isapi.dll and comes as part of the .Net framework. ASP.Net can only handle those requests that are forwarded to it from IIS. This is extremely crucial especially when working with directory security in ASP.Net. Security can be applied both on IIS and ASP.Net which strengthens the implementation of the defense-in-depth principle that Microsoft encourages developers to follow.
3.7.1.4 File Handling After the ASP.Net engine receives a GET request for a file sent by IIS, the ASP.Net engine will process the request in accordance with the related file handler that is configured in the Machine.config which is a machine-level configuration file for the .Net framework instance. For ASP.Net to control security for a file type that is not support by default by the ASP.Net engine, two things must be done. First, IIS should forward file requests of such type to ASP.Net. Second, the Machine.config file handler section should contain an entry that corresponds to the requested file type. Table 3.2 gives examples of such handlers in the Machine.config file.
70
Table 3.2. Example of file handlers Handler System.Web.UI.PageHandlerFactory System.Web.HttpForbiddenHandler System.Web.StaticFileHandler
System.Web.HttpMethodNotAllowed
Description Normal ASP.Net pages Returns a forbidden request page Returns the file, if the authorization rules allow that. (Very useful to control folder security for types not supported by the ASP.Net by default) Returns an error page
As an example, for PRIDE to be able to process all requested files to the Web server, all file types should be forwarded to the ASP.Net working process in the IIS configuration console.
3.7.2
Implementation Environment The client machine is an HP iPAQ Pocket PC h6340. The .Net Compact
Framework 2.0 was used to develop the PRIDE client-side security engine. The client is connected to the server using a USB Sync cable provided with the PDA device. To simulate a real-life scenario where securing Web traffic is a requirement, we chose to test PRIDE on an e-commerce Web site. A typical example is Amazon.com. We simulated purchase operations and downloaded the HTML pages along with all their related components. The total size of the tested site was 9.3 MB. The elements were distributed as follows: 2.5 MB of HTML pages, 2.2 MB of images and 4 MB of product manuals, i.e. PDF, and video content. A list of the Web site files was fed to the client engine which was responsible of fetching and decrypting these files from the server. The tests were done in three stages. Each stage was repeated many times to make ensure consistency of the results. The first stage was conducted with the policy set on the server to send all content as clear-text without any encryption. This phase was conducted in order to measure the time the client needs to download the content. The second phase was to set the policy
71
to encrypt everything; i.e. bulk encryption. In this case, the system is equivalent to a standard bulk encryption protocol. The third phase of the tests was to implement the PRIDE’s content-based encryption methodology. The policy was built based on the following analysis: 300 KB of the data was considered highly sensitive. This data can not be content-base encrypted. This consisted of sensitive images, and PDF files; 1.2 MB of HTML files were eligible to be selectively encrypted. The selection of what to encrypt was based on regular expressions; 7.8 MB of images, videos and PDF files were considered to be not sensitive and thus sent unencrypted. This category consists mainly of product-related data such as images and few manuals in the format of PDF, video files and HTML.
3.7.3
PRIDE’s HTTP Response In order to analyze PRIDE’s results and show it in an understandable way,
we used wfetch [34], a tool that comes with IIS 6.0 free Resource Kit Tools. Wfetch is used to troubleshoot connectivity issues between IIS and Web clients. It is used to view data that is not displayed in the Web browser, such as the HTTP headers that are included in the Request and Response packets. Figure 3.7 depicts the HTTP header in PRIDE’s response. PRIDE introduces some new HTTP header keys that serve the client to reconstruct the original response. These new keys are: •
PRIDE-Security-Level: This indicates the security level that the
response is secured in. This can be 0,1,2 or 3. To simplify the implementation and for performance purposes, we considered the security level of the response as to be the highest of all its constituents.
72
•
PRIDE-Content-Based: Indicated whether the response is content-base
secured. This is used to prevent any parsing operations by the client when the response is bulkily secured. •
PRIDE-Original-HTML-Length: This indicates the original file size of
the HTML file. This will help the client security engine to make sure it has totally reconstructed the HTML file in case of content-base security.
PRIDE Headers
Fig. 3.7. PRIDE’s HTTP Header
Figure 3.8 shows in details a bulkily encrypted image where as Figure 3.9 depicts a content-base secured response.
73
Header
Encrypted Data
Fig. 3.8. Bulkily Encrypted Image Response
Reference Table
Encrypted Data
Plain Text HTML Fig. 3.9. Content-base secured HTML Response
3.7.4
Results PRIDE showed a great performance enhancement by selectively encrypting
sensitive data and sending insignificant data unencrypted. The time needed to download the contents to the client device was calculated in order to focus on the 74
overhead introduced by the encryption and related processes. As Table 3.3 shows, it was possible to reduce the time that bulk encryption takes to secure a Web site by 83% (from 42 sec to 7 sec). From a speed point of view, PRIDE is almost six times faster than bulk encryption (See Figure 3.10).
Table 3.3. PRIDE Client Test Results Encryption time
Encryption Speed
Key Length
Bulk Encryption
42 seconds
224 KB/Sec
192 bits
PRIDE Encryption
7 seconds
1.3 MB/Sec
128/192/256 bits
KB/Sec 1400 1200 1000 800 600 400 200 0 Bulk Encryption
PRIDE Encryption
Fig. 3.10. Client Processing Speed
75
CHAPTER 4 PRIDE’S WEB SECURITY ENGINE – OTHER APPLICATIONS 4.0 OTHER APPLICATIONS 4.1 ODYSSEY 4.1.1
Introduction In this section we present ODYSSEY (pOlicy-Driven anonYmizer for
handheld WireleSS dEvices privacY). ODYSSEY is an efficient security architecture for assuring privacy through applying selective confidentiality and integrity on Web traffic between wireless handheld devices and the Internet. The security gateway, or the anonymizer, is situated between the client and the Internet and hides the identity of the user by maintaining privacy since the gateway acts on behalf of the client; and by preserving confidentiality and integrity since the gateway applies content-based encryption and hashing on the Web traffic between itself and the client. The system is a scalable, policy-based solution capable of evolving and adapting to suit the security requirements of a wide range of wireless devices with various capabilities and resources. The customizable policy-based architecture in the system can be configured to provide privacy through applying security services according to the content and sensitivity of the network data in the Web traffic. In addition, ODYSSEY is autonomous since it can continuously update its policies based on existing policy rules and user behavior. This gives ODYSSEY considerable performance gains over existing standard anonymizers that use bulk encryption protocols such as SSL. ODYSSEY is designed as a platform-independent architecture and can be seamlessly
76
used to access Web sites on the Internet from different client platforms. ODYSSEY does not impose any requirements on the Web servers.
4.1.2
Privacy Issues on the Web Each Web site the user visits, directly or indirectly, is able to obtain a lot of
information about the user, and the machine he/ she is using through some variables the Web browser sends as part of the HTTP request. These headers are used to fetch the page the user wants to access. The main variables Web servers can acquire form the Web browser are [29]: •
HTTP_USER_AGENT: Reveals the user’s browser version which helps
the Web servers send tailored responses to the client. •
REMOTE_HOST: Reveals the IP address of the requesting machine. As
demonstrated in some experiments, it was even possible to get the machine’s local IP address along with the IP address of the proxy server of the requesting client. Using NAT technology, one would have thought that his/ her IP address is protected while browsing the Web, which is not always true. From the IP address, and depending on other Web services, such as the “whois” service, the Web server can get more information about the user’s ISP and geographical location. •
HTTP_REFERER: Reveals the previous page the user has surfed before
visiting the intended page. For example, the Web server is able to identify the user’s favorite search engine along with the search term the user used to reach the intended Web site.
77
In addition to all the above variables, the Web server can take advantage of some bugs, after knowing the user’s Web browser version. These bugs can reveal the user’s email address for example [29]. One other very important privacy issue involves the Internet Service Provider (ISP). When not using SSL, the ISP can get full access to the Web traffic the client is initiating. This is a very large surface that is fully exposed to the ISP. Companies usually trust their ISP, which is not always justifiable especially when taking into consideration that not all of the ISP’s employees are fully trust-worthy. Even worse, in many countries the number of ISPs is very limited and regulated by the government. The ISP, using one of the many available Web analytics packages [30], can have access to behavioral information about the users. In case of an enterprise, this might mean revealing sensitive behavioral information about what business the enterprise is doing to some potential competitors. A full case study on the cost of not taking care of the enterprise’s privacy on the Web is available in [30].
Fig. 4.1. Privacy on the Web: From [30]
78
4.1.3
The Anonymizer The Anonymizer provides technological means for maintaining a user’s
privacy when surfing the Internet. The basic idea is very simple: to act as a middleagent between the client (or the enterprise) and the Internet. In this case, the Anonymizer will act as the client’s proxy by fetching all the client’s requested pages using the IP of the Anonymizer not the IP of the client. In this case, the client will deal exclusively with the Anonymizer, thus hiding all traffic behavior from the ISP. Another privacy issue worth mentioning is that the visited Web site will not get any information about the client since the request is being generated from the Anonymizer server and not from the client. The server will get the HTTP request variables from the Anonymizer, and not from the client. The roles the anonymizer will play in protecting the privacy of the client can be summarized as follows [29]: 1. “it does not forward the source IP address of the end-user; 2. it eliminates revealing information about the user’s machine configuration from the "User-Agent" MIME header; 3. it eliminates the user’s name from the "From" MIME header; 4. it eliminates the previously-visited site name from the "Referer" MIME header; 5. it does not forward the user’s email address to serve as a password for FTP transactions; 6. it filters out Java applets and JavaScript scripts which may compromise anonymity; 7. it filters out all "magic cookies" which may compromise anonymity; and
79
8. it gives positive feedback to the user by displaying an Anonymizer header on the page and adding the word "[Anonymized]" to the page’s title.”
In order to totally hide the traffic from the ISP, many anonymizers provide their clients with an SSL connection to guarantee full privacy end-to-end. In this case, the logical channel between the client and the anonymizer will be absolutely hidden to the ISP. The obvious disadvantage of this scenario is performance. SSL is slow since it is a bulk encryption protocol.
4.1.4
Web Statistics Figure 4.1 is an example of the statistics of a Web server (the Web server of
the American University of Beirut [31]), while Figure 4.2 shows Web traffic statistics of three public proxies [32].
Fig. 4.1. AUB Website Statistics [31]
80
Fig. 4.2. Example of Public Proxies’ Statistics [32]
From Figure 4.1 and 4.2 we can conclude the following: •
More than 75% or the requests are images
•
More than 50% of Web traffic is images
•
HTML counts for almost 20% of the Web traffic from which almost 50%
are Java Scripts and Cascading Style Sheets (both of which are formatting and interface-related files).
Since sensitive data is usually in HTML documents, we can conclude that its volume does not exceed 20% of the total Web traffic, and in many cases, it will account for less than 10% of that traffic.
81
4.1.5
Concept ODYSSEY utilizes PRIDE’s web security engine in order to protect and
secure the logical channel between the client and the anonymizer. ODYSSEY utilizes the mature design of a Web anonymizer (described in Section 4.1.3) and replaces the SSL connection between the client and the anonymizer server by a PRIDE secure connection. This secure connection is a content-based and policy-driven secure channel. ODYSSEY introduces new features and policy keys to the PRIDE’s security engine and policy.
4.1.6
ODYSSEY’s Design
Fig. 4.3. ODYSSEY General Architecture
82
Fig. 4.4. ODYSSEY’s Policy
This section gives an overview of the design and architecture of ODYSSEY on the client side, the anonymizer, and on the proxy that is used to optimize the performance in trusted intranets. An abstract view of the major components of the security architecture and their interrelationships is shown in Figure 4.3.
4.1.6.1 The Security Policy The Security Policy controls the overall security behavior of the Web traffic protected by ODYSSEY. The policy configuration is stored in an XML-formatted document at the anonymizer. This policy is used by the Server Security Engine (see Figure 4.3) and each subscriber user to the anonymizer has his/ her own policy. Each user can customize his/ her policy using a web-based interface made available at the anonymizer. The Policy Decision Point is a main component in the Security Engine. It ensures that the policy configurations are applied on all Web traffic which the Security Engine is supposed to protect.
83
As in PRIDE, the policy is divided into two main parts (see Figure 4.4): the first part specifies security-related attributes and parameters, while the second deals with how security mechanisms are applied on the Web content. The security-related attributes control the behavior of the Security Engine for confidentiality, integrity and key management. Following is a list of these attributes: •
Encryption algorithm
•
Hashing algorithm
•
Key management algorithm
•
Session-keys life time
The second part of the policy is divided into two main sections. The first section specifies the security classes that are to be used by the policy. These classes are a set of security specifications that can be applied to different types of Web content. These security classes are characterized by the following attributes: •
Class name
•
Security level
•
Integrity enforcement
•
Force over local networks
These attributes are the same attributes available in PRIDE (See Section 3.2). The second part of the Policy deals with Web content. It specifies the security level and scope for each type of content, by either stating explicitly these security settings or by referring to a certain security class.
84
Two main components represent the mechanisms using which the security engine is able to successfully select what to encrypt and at what security level. These components are: 1) trigger and 2) scope. Web content is identified using triggers which might be one of five: •
Filename
•
Tag type
•
Regular expression
•
Web site domain
•
Search key term
These triggers can be combined together to be more selective in choosing the data to be encrypted. Filenames can be any valid file name, with an asterisk (*) specifying all files. Tag type is any HTML tag type. Regular expressions are used to match and secure sensitive patterns that appear frequently in Web traffic. The Security Engine, when finding a match according to the trigger element, encrypts the Web traffic that is in the scope of the scope element. The scope can be one of the followings: •
Whole Web site
•
Current tag
•
Certain file types in the current Web site
•
Current HTML page
These scope elements can be combined in order to be more granular in selecting the data to be encrypted. All these identification mechanisms help the Policy
85
Enforcement Point to specify the encryption boundaries and security levels of the Web data stream.
4.1.6.2 Policy Customization The XML policy configuration file is read by the Security Engine when the user requests a Web site from the anonymizer. The policy information present in the policy configuration store was designed to be human-readable, given the nature of XML, so that it can be easily configured by system administrators using simple XML or text editors. Users can customize their policies via a Web interface available at the anonymizer.
4.1.6.3 Policy Caching and Growing Policy resolving and caching is an important feature that is performed on the anonymizer server and that is handled by the Policy Loader. The policy resolving and caching procedures are similar to those used in PRIDE (See Section 3.4). The policy might contain some keys that augment the policy by adding new keys to the policy store. For example, one key might state that whenever the text “credit card” is found, add a key to encrypt all traffic belonging to that Web site’s domain.
4.1.6.4 Web Traffic Confidentiality and Integrity To support a flexible encryption scheme, ODYSSEY identifies the content to be secured in the security policy. It is the responsibility of the server-side Security Engine (see Figure 4.3) to perform the encryption and hashing operations of the Web data and to construct the secure response based on the request coming from the client
86
and the security policy. The Security Engine on the client-side accepts the secure response, performs the necessary decryption operations and integrity verification, constructs the original response message as sent by the surfed Web site and delivers it to the Web browser. This is done based on the request mode in the security policy. Sending a secure post-back request form the client to the server follows the same procedure. In this case the client-side and the server-side Security Engines will switch roles and the security operations and their strengths will be based on the mode of the “post-back” interaction type in the security policy. The following procedures summarize the overall request/response model of ODYSSEY at the server and client sides. The Anonymizer server: 1. receives incoming requests from the client 2. coordinates with the key management server in order to initialize a new secure session 3. parses the policy store and resolves the security settings, if no cache exists 4. caches the resulted settings 5. HTTP fetcher retrieves the requested document or file 6. applies confidentiality and integrity settings on the retrieved document 7. attaches to the response an encrypted version of the necessary policy description 8. flags the response as secured and identifies if the post-back from the client needs to be secured as well 9. finally, it receives the encrypted post-back from the client, decrypts and forwards it to the appropriate Web site.
87
On the other hand, the client: 1. receives requests from the Web browser and forwards them to the anonymizer server 2. waits for the response and checks for its security flag 3. forwards the response as is to the Web browser, if security flag is not set 4. decrypts parts of the Web traffic and checks for its integrity based on the decrypted policy, if security flag is set 5. sends the response as plaintext back to the Web browser 6. encrypts and sends post-backs that are to be secured based on the policy.
Most of the intelligence of the client-side Security Engine can be moved to an Enterprise Proxy Security Engine that resides on the local intranet and serves all local clients. This alleviates the load from the client machines especially in the case of limited devices, and boosts the performance of the whole security system. In case the secured Web traffic is flagged to force security over local networks, the client-side machine will have to take responsibility again. This is the case when highly critical data is transmitted over non trusted local networks.
88
4.2 SmartSSL 4.2.1
Introduction In this section we present SmartSSL (Content-based SSL Web Security for
Handheld Wireless Devices). SmartSSL is a dynamic security solution for assuring security of Web sites using SSL in an efficient way. HTTPS, which denotes using HTTP on top of a SSL secure session, is being implemented in almost all types of Web browsers. Even small wireless limited devices are available with browsers that support SSL. The main disadvantage of SSL is the fact that it is a blind protocol; it encrypts everything regardless of the different sensitivity levels of different parts of the Web traffic. In order to overcome this shortcoming, administrators and webmasters tend to manually apply SSL on certain parts of their Web sites. The main disadvantages of this procedure are as follows: •
It does not assure the security of the Web site unless the administrator
takes a paranoid viewpoint and secures more parts in order to make sure the sensitive data is protected. •
In case the data to be encrypted is dynamically generated, which is most
probably the case in today’s m-commerce Web applications, it will be necessary to apply SSL on an even wider scope, thus securing even more data than necessary. •
Any changes to the Web site’s structure or content will require the
administrator to go through all the updated parts and make sure SSL is applied correctly.
The above will result in more portions of the Web traffic being encrypted than needed. This will sacrifice the limited resources of the client, making the users suffer from low performance, including battery time. SmartSSL is a content- and
89
policy-based security solution that applies SSL dynamically on parts of the Web traffic without requiring the administrator to go and inspect the content of the Web site. Instead, it just requires the administrator to configure a policy to be applied onthe-fly on the Web traffic which leaves the Web server. SmartSSL does not impose any requirements on the client machine. Any standard Web browser with standard SSL will work well with SmartSSL. SmartSSL is designed in a platform-independent manner and can be ported to most known platforms.
4.2.2
Concept The idea behind SmartSSL is to build a smart Web security engine that
applies SSL on parts of the Web site based on content and configurable policies. This will be achieved by two main mechanisms that will be discussed in more detail later: first, by rewriting all links in an HTML document to external sensitive resources, such as images, as SSL. Second, mandate SSL on sensitive objects, reject HTTP requests to these objects and send back an HTTP 302 response in order to redirect the client’s request to the HTTPS mirror of the object. For the client, the secured Web site will seem partially secured with SSL. This might give the users some doubts about the security level of the Web site, but his may be overcome by adding a plug-in to the Web browser to indicate that SmartSSL is being used.
4.2.3
SmartSSL Design This section gives an overview of the design and architecture of SmartSSL.
An abstract view of the major components of the security architecture and their interrelationships is shown in Figure 4.5.
90
4.2.3.1 Requirements As seen is Figure 4.5, SmartSSL does not impose any requirements on the client side. Any standard Web browser will work well with SmartSSL. For the server side, SmartSSL will be implemented as a plug-in HTTP filter on the Web server application (i.e. IIS or Apache). SmartSSL requires getting a certificate and point both
Request Handler
HTTP and HTTPS requests to the Request Handler.
Fig. 4.5. SmartSSL General Structure
4.2.3.2 Security Policy SmartSSL uses the same policy as in PRIDE. The policy resolving and caching mechanisms are the same as well (See Sections 3.2, 3.3 and 3.4).
4.2.3.3 Web Traffic Confidentiality and Integrity The Security Engine is the component responsible of providing data confidentiality and integrity based on the sensitivity of the Web traffic (see Figure 4.5). In order to better understand the mechanisms the system performs to secure the Web traffic, we will differentiate between three different scenarios.
91
One scenario is when receiving an HTTPS request to an object. In this case the Request Handler forwards the request to the SSL Content Handler which will identify whether the request is for a real object in the Web site or to a part of a content-secured page. If it is a request for a real object, it will fetch it and send it back to the client in a normal HTTPS response. More details regarding the second case are provided later. Another scenario is when receiving an HTTP request to an object. In this case, the Security Engine will perform a check to make sure this object is clear to be sent in plain text. If this is the case, the object will be sent as is to the client using a normal HTTP response. If the Security Engine classifies this object as sensitive, an HTTP 302 response will be sent to the client to redirect his/ her browser to the same object but this time using HTTPS. A more complicated scenario is when receiving an HTTP request to an HTML page. First, the Security Engine along with the HTML Rewriter will check the HTML file for external resources. The Security Engine will go over each of these external links to decide if it should be totally secured. If so, it will rewrite the link to that external resource using HTTPS. Second, the Security Engine will check in order to decide whether the file should be parsed. This is done according to the policy. If the file is to be fully secured, then this scenario will be similar to the case of requesting a sensitive object. If the file is to be parsed for matches, the Security Engine with the cooperation of the HTML Rewriter will parse the document searching for matches. Then, it will remove these matches from the original document and replace them with containers for external HTML documents. These containers can just be IFRAME tags. The source file of this container will be a non-existing page with an HTTPS prefix. The Security Engine will
92
send some information about these matches to the SSL Content Handler. The SSL Content Handler when receiving the request to these non-existing pages will send the sensitive data in a standard HTTS response to the client.
4.2.4
Comparisons (PRIDE, SmartSSL, Bulk SSL) We compare in this section securing a Web site using bulk SSL, SmartSSL
and PRIDE. The comparison is depicted in Figure 4.5 and is done on three scales: •
Server Installation: Time needed by the administrator to secure a Web
site on the server side. •
Client Deployment: Time and effort needed to deploy the security
mechanism to the client considering current Web browsers that have built-in SSL capabilities. In case PRIDE will be widely available in Web browser packages, all three solutions will have equal importance in this scale. •
Client Performance: Performance can be scaled based on CPU cycles,
RAM units or both that is needed to protect certain Web traffic.
Fig. 4.6. Comparisons
93
For server installation, SSL is the easier to be installed. Implementing SSL on a Web site involves acquiring a certificate and enabling SSL on parts of the Web site. As for SmartSSL and PRIDE, securing a Web site involves installing the Security Engine and creating policies. Thus, SmartSSL and PRIDE take more effort to be installed on the server. As for the client deployment, SmartSSL and SSL do not impose any requirements on current Web browsers since they all are equipped with SSL. On the other hand, PRIDE requires the Client Security Engine to be installed on the client machine. Finally, PRIDE has the best performance since its server and client Security Engines are tuned and enhanced for performance. PRIDE is faster than SmartSSL because the latter requires more HTTP requests to get a content-base secured page.
94
CHAPTER 5 CONCLUSIONS AND FUTRE WORK In this thesis we presented PRIDE, an optimized policy-driven security architecture for securing the privacy and integrity of Web transactions initiated by handheld wireless devices. PRIDE is a customized security protocol capable of operation in diverse wireless environments with different resources, capabilities, and configurations. The security services provided by PRIDE are based on the content and sensitivity of the network data. PRIDE is designed in a platform-neutral manner and can be seamlessly integrated into existing application servers and mobile client devices. Implementation showed PRIDE to be almost 6 times faster than bulk encryption protocols. In addition, we presented in this thesis ODYSSEY, an efficient security architecture for assuring privacy and security through applying selective confidentiality and integrity on Web traffic between wireless handheld devices and the Internet. ODYSSEY is a customized security protocol that ensures the user’s privacy and security while browsing the Web. ODYSSEY does not impose any requirements on surfed Web sites. Finally, we presented SmartSSL. SmartSSL is a smart security solution for assuring security of Web sites using SSL in an efficient way. SmartSSL is a contentand policy-based security solution that applies SSL smartly on parts of the Web traffic without requiring the administrator to inspect the content of the Web site. SmartSSL is designed in a platform-independent manner and can be ported to most known platforms.
95
Future work on PRIDE includes implementing the server- and client-side engines in a lower-level language such as C in order to better compare the performance of PRIDE with SSL. Another enhancement would be hardware implementation that verifies the validity of developing a hardware box that will take responsibility for securing the HTTP traffic in an enterprise. As for ODYSSEY, a full implementation is needed. This implementation will help in assessing the design of the system and open the opportunity to add new keys and mechanisms to the policy and security engine. Finally, a full implementation of SmartSSL is needed. The implementation of SmartSSL will make sure that SmartSSL can seamlessly easily with any standard Web browser that supports SSL. The implementation of a plug-in for some popular Web browsers to indicate when the Web site is secured by SmartSSL will avoid giving the user the feeling that the Web site is a mix of secured and non-secured pages.
96
REFERENCES
[1]
N. Doraswamy, D. Naganand, “IPSec: the new security standard for the Internet, intranets, and virtual private networks”, Prentice Hall, 2003.
[2]
Cisco Systems et. al. “Internetworking Technologies Handbook, Fourth Edition”, Cisco Press, May 2005.
[3]
Y. Zhang, “A multilayer IP security protocol for TCP performance enhancement in wireless networks”, IEEE journal in selected areas in communications, Vol.22 No. 4 May 2004.
[4]
J. Sing and B. Soh, “A critical analysis of multilayer IP security protocol”, ICITA 2005.
[5]
“Internet security association and key management protocol (ISAKMP)”, RFC 2408, Nov. 1998
[6]
H. Orman, “The OAKLEY Key Determination Protocol,” IETF RFC 2412, Nov. 1998, http://www.ietf.org/rfc/rfc2412.txt ; accessed May 2006.
[7]
W. Stallings, “Cryptography and Network Security: Third Edition”, Prentice Hall 2003.
[8]
W. Stallings, “SSL: Foundation for Web Security”, The Internet Protocol Journal, Cisco 1998.
[9]
“Understanding Digital Certificates & Secure Sockets Layer (SSL)”, Entrust Inc, 2005.
[10]
“Digital Certificates, Authentication, and Trust On The Internet”, KPMG LLP, 2002.
97
[11]
K. Scheibelhofer, “Signing XML Documents and the Concept of What You See Is What You Sign”, Master thesis, Graz University of Technology, 2001.
[12]
E. Bertino and E. Ferrari, “XML Security”, Elsevier Science Ltd, 2002.
[13]]
D. Eastlake and J. Reagle, “XML-Signature Syntax and Processing”, W3C, 2002.
[14]
W3C XML Encryption Working Group, www.w3.org/Encryption/2001/; accessed May 2006.
[15]
B. Siddiqui, “Exploring XML Encryption, Part 1”, IBM, 2002.
[16]
B. Siddiqui, “Exploring XML Encryption, Part 2”, IBM, 2002.
[17]
Business Transaction Protocol (BTP), http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=businesstransaction; accessed March 2006.
[18]
OASIS Security Services (SAML) TC, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=security; accessed February 2006.
[19]
AlphaWorks’s XML Security Suite, http://www.alphaworks.ibm.com/tech/xmlsecuritysuite, IBM; accessed March 2006.
[20]
W3C XML Digital Signature Working Group, www.w3.org/signature; accessed March 2006.
[21]
B. Siddiqui, “XML Canonicalization”, O”RELLY, http://webservices.xml.com/pub/a/ws/2002/09/18/c14n.html, September 2000; accessed June 2006.
[22]
C. Geuer-Pollmann, “XML Security Page”, http://www.nue.et-inf.unisiegen.de/~geuer-pollmann/xml_security.html, accessed March 2006.
98
[23]
XML Key Management Specification 2.0 (XKMS), W3C Recommendation 28 June 2005, http://www.w3.org/TR/xkms2/; W3C, accessed March 2006.
[24]
F. Hirsch, “Getting Started With XML Security”, 2002, http://www.fjhirsch.com/xml/xmlsec/starting-xml-security.html ; accessed March 2006.
[25]
X.509, ITU-T Recommendation X.509, The Directory: Authentication Framework, June 1997.
[26]
W. Itani, A. Kayssi, and A. Chehab, “PATRIOT – a Policy-Based, Multi-level Security Protocol for Safekeeping Audit Logs on Wireless Devices,” in Proc. IEEE/CreateNet First International Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2005), September 2005, Athens, Greece.
[27]
B. Shneier, J. Kesey, D. Whiting, D. Wagner, C. Hall and N. Ferguson, “Performance Comparison of the AES Submissions”, Version 2.0, February 1999.
[28]
J. Daemen and V. Rijmen, “Rijndael, the Advanced Encryption Standard” Dr. Dobb's Journal, March 2001.
[29]
J. Boyan, “The Anonymizer, Protecting User Privacy on the Web”, Anonymizer.com, http://www.december.com/cmc/mag/1997/sep/boyan.html; accessed March 2006.
[30]
“Protecting Your Company by Taking Your Network Uncover”, Anonymizer.com, 2004.
[31]
AUB Web Site Statistics, http://stat.aub.edu.lb/cgibin/awstats.pl?config=int-aub.edu.lb; accessed 17.May 2006.
[32]
A. Mahanti, C. Williamson, D. Eager, Department of Computer Science, Univeristy of Saskatchewan Canada, “Traffic Analysis of a Web Proxy Caching Hierarchy”, IEEE Network Magazine: Special Issue on Web Performance, June 2000.
99
[33]
T. Northrup, “Implementing Security for Applications”, Microsoft Press, 2005.
[34]
“HOW TO: Use Wfetch.exe to Troubleshoot HTTP Connections”, Microsoft Support, June 2005, http://support.microsoft.com/default.aspx?scid=kb;enus;284285; accessed January 2006.
100
