An Enterprise Policy-Based Security Protocol for Protecting Relational Database Network Objects Wassim Itani
Ayman Kayssi
Ali Chehab
Department of Electrical and Computer Engineering Beirut 1107 2020, Lebanon Tel: 961 3 717005
Department of Electrical and Computer Engineering American University of Beirut Beirut 1107 2020, Lebanon Tel: 961 1 350000
Department of Electrical and Computer Engineering American University of Beirut Beirut 1107 2020, Lebanon Tel: 961 1 350000
[email protected]
[email protected]
American University of Beirut
ABSTRACT
[email protected]
Keywords
In this paper we present ESCORT, an Enterprise, policy-baSed seCurity prOtocol for protecting relational daTabase network objects. 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, multilevel, and fine-grained 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 byte- level granularity in securing individual database fields. This makes ESCORT 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. ESCORT neither deals with the security of static data in the database store nor requires the encryption of database objects at the storage level. Results show a performance gain by a factor of three for ESCORT as compared to bulk encryption.
security, relational customizable security.
databases,
1. INTRODUCTION
policy-driven
security,
Relational Database Management System (RDBMS) are considered the primary medium for storing business data. This data consists of sensitive information such as credit card numbers, bank accounts, financial transactions, accounting journals, intellectual property, etc. and is considered the main constituent of the network data flowing between the database server and the application client. For this reason, ensuring and enforcing the confidentiality and privacy of database objects must be given an exceptional attention. This paper presents ESCORT, an enterprise, policy-based security architecture for protecting relational database network objects. ESCORT is an efficient end-to-end security system that ensures the confidentiality and integrity of database objects flowing over network links between relational database servers and enterprise clients. 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 SSL [1] and TLS [2] by utilizing a customizable, policybased security architecture. This policy-based architecture makes use of the relational structure of database objects to provide flexible, multi-level, and fine-grained 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 byte- level granularity in securing individual database fields. This leads to a substantial decrease in the number of encryption operations and a full control on their level and scope, which results in great flexibility and performance improvement. Moreover, ESCORT's policy-driven security architecture makes it a very efficient choice for operation in wireless enterprise environments. Usually wireless enterprise applications 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 large variety of client devices which may be severely constrained in terms of processor speed, memory resources, and storage capacity. This diversity makes the
Categories and Subject Descriptors H.2.7 [Database Management]: Database Administration – Security, integrity, and protection.
General Terms Algorithms, Performance, Design, Security.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IWCMC’06, July 3–6, 2006, Vancouver, British Columbia, Canada. Copyright 2006 ACM 1-59593-306-9/06/0007...$5.00.
343
implementation of a unique security standard that encompasses the whole device range infeasible. 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. For this reason, the security operations performed by ESCORT are based on an externally customizable and differential security policy [3,4] which groups database network data according to sensitivity and content, and takes into consideration the processing power and memory capabilities of the enterprise client device. 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 provides an Application Programming Interface (API) that supports a set of security abstractions and hides the complexity of database security programming from the application developer. This API is designed in a platform-neutral manner and can be implemented on a wide range of database servers and client devices. The rest of the paper is organized as follows: in Section 2 we discuss previous research work related to the security of database objects and network data. Section 3 describes ESCORT’s design and architecture. In Section 4, we present a brief discussion on ESCORT's implementation on several computing platforms and the performance results obtained. Conclusions are provided in Section 5.
memory intensive for some enterprise applications, mainly those supporting low-resource wireless and mobile clients; thus Sun Microsystems has developed a light-weight SSL implementation called KSSL [9] which is a client-side implementation of SSL version 3.0, supporting the RSA-RC4-128-MD5 and RSA-RC440-MD5 cipher suites. This SSL implementation (KSSL) provides a big advantage by enabling Java-enabled devices to communicate directly and securely with the huge number of Internet web servers supporting SSL. 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. In spite of the advantage provided by SSL, and its limited-clientside implementation KSSL, in securing mobile commerce applications, some comments are worth mentioning here. First, KSSL’s 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. 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. However, storing the master secret and reusing it repeatedly in generating the symmetric ciphering keys raises 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. A second comment about the operation of SSL and KSSL is their non-differentiation when performing the security operations on the client and server devices. This is due to the fact that SSL is a bulk encryption protocol that indiscriminately encrypts all the network data without regard to its type or sensitivity. To SSL, network data is of one type, and there is no categorization of this data based on sensitivity. Thus, when using SSL to secure database objects, all the contents of these objects are encrypted by the same cryptographic key strength, which can be unnecessary or even undesirable for some enterprise applications supporting limited-resource wireless and mobile clients. This fact about SSL will become more evident and pressing as the mobile commerce network expands; thus the need will arise for a configurable security model with flexible encryption schemes to meet a range of different requirements.
2. RELATED WORK
A lot of research work has dealt with the security and privacy of database information at the storage level. This research mainly focused on encrypting the database contents at rest in the database. Although this can protect the data from a hacker breaking into the database server or from the network or domain administrators, it doesn't protect the privacy or integrity of data traveling over the network links between the application client and the relational database. Moreover, the necessity to decrypt the encrypted data before being processed by the database server can impose a considerable performance impact and can induce a lot of limitations on certain database operations such as comparison queries and updates on encrypted data. For this reason the notion of column-based encryption on database tables was introduced to decrease the performance impact of encryption/decryption operations and to relax some of the restrictions on the basic database server operations. In spite of this, a significant performance decline is still experienced when accessing and updating encrypted data or when performing comparison searches and queries on an encrypted column in large databases. An extensive survey of the different approaches on encryption of database data at rest is beyond the scope of this paper. References [5–8] provide good sources of information on this topic. At the network level, SSL is the standard security protocol for providing confidentiality and integrity services for network data on the Internet. It provides point-to-point security by establishing a secure channel on top of TCP, where it supports server authentication using certificates, confidentiality, and message integrity. Optionally, there is support for cryptographic client authentication. SSL, in some of its parts, is too compute- and
3. ESCORT ARCHITECTURE
This section provides an overview of the design and architecture of ESCORT on the client and server-sides. Figure 1 presents an abstract view of the different components comprising ESCORT's security architecture. ESCORT operates on the client and server sides by seamlessly employing a Security Engine component to transparently control the database network data encryption/decryption operations. The security services supported by ESCORT's Security Engine are controlled and configured based on the information present in the policy configuration file which provides the primary information source that the Security Engine consults for taking security decisions at runtime. Based on this design paradigm, ESCORT can provide an end-to-end security protocol for all the enterprise
344
• Field_Count: specifies the number of fields composing the database object. This attribute is only used when ESCORT's Security Engine doesn't have direct access to the database data dictionary. • Field names and data types: specifies the names and data types of the database object fields. This attribute is only used when ESCORT's Security Engine doesn't have direct access to the database data dictionary. It is worth emphasizing that ESCORT, in theory, can generically support any number of encryption, hashing, and key management algorithms. However, increasing the number of supported algorithms is practically infeasible due to the possible implementation of ESCORT on limited- storage wireless devices. The second part in the security policy controls the level and scope of the security operations to be applied on the fields of the database object. According to this specification, the security of each field belongs to one of three security modes: A Secure_All mode: this mode states that all the contents of the field must be secured, and specifies the strength of the encryption to be applied on this field. Four encryption levels are supported by ESCORT: a High_Security level which is equivalent to 256-bit AES, 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 or security 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 field data being secured. This logical and generic representation is 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 field must be stored as is without any encryption. Not all the database records generated by the database server will be treated in the same way by the Security Engine. ESCORT’s security policy introduces the concept of database classes. According to this concept, every record generated will be secured depending on the database class it belongs to. The database class membership criterion is based on one of the fields of the produced database record satisfying a particular regular expression. If the produced database record doesn’t satisfy any of the database classes specified in the security policy, it will be secured based on a default database class. Moreover, every database class specifies whether the fields of the database record satisfying this class are to be added to the hash chain that enforces the integrity of the whole database result. It should be noted here that ESCORT leaves the issue of resolving any conflict, which may arise if a database record satisfies two different database classes, to the
application's database information flowing on the network. On the server side, ESCORT can either operate on the database server layer to encrypt database data as it moves out of the relational database server, or it can operate on the application server layer to secure database data between the application server and the client device. In the second case, it is assumed that the database server and the application server reside in the same security domain and that the network connection between these two servers is trusted. On the client-side, ESCORT can either operate on the client device to support the decryption and integrity verification of the database data, or it can operate on the proxy-server side to provide the data decryption and integrity assurance to an entire intranet site or Local Area Network (LAN). The second scenario is suitable for providing policy-based security services to small wireless devices with limited resources that are not capable of running the Security Engine in their address space. This is illustrated in Fig. 2.
3.1 The Security Policy
Each database object in the database is linked to a security policy file specifying the level and scope of the encryption operations to be applied on this database entity. The security policy source information is present in a secure repository on the server side. The high-level representation of the security policy is configured by the database administrator (DBA). ESCORT’s 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 fields of each database record. The security-related attributes and configuration parameters specified in the first part are required by the Security Engine component to control the confidentiality, integrity, and key management operations. The Security Engine is the component responsible for taking security decisions and carrying out security-related operations to secure the database result. The following is a list of attributes supported by ESCORT’s security policy: • Database_Server: specifies the Uniform Resource Locator (URL) of the database server. This attribute is only used if ESCORT's server-side Security Engine resides on the application server and not on the database server. • Database_Object: specifies the name of the database object associated with this security policy. • Encryption_Algorithm: specifies the symmetric encryption algorithm to be used for securing the privacy of the database records. • Hashing_Algorithm: specifies the hashing algorithm to be used in securing the integrity of the database object. • Key_Management_Algorithm: specifies the key management algorithm for sharing the initial secret key between the wireless device and the trusted server.
345
implementer. That is, the implementer may assign the database record to the first database class it satisfies in the policy configuration, to the default database class, or in any other implementation-specific way.
transport medium used. That is the policy configuration could be loaded to the device over the network, using a physical storage facility such as a memory stick or a smart card, or it could be initially built into the client device by the device’s manufacturer.
3.1.1 Policy Joining
3.1.4 Policy Caching
SQL queries usually request data from multiple database tables and views. To handle database queries requesting the join of more than one database object, ESCORT supports a policy union operation that dynamically constructs a policy configuration file at request-time.
In enterprise database applications, SQL requests to the DBMS are usually characterized by recurring patterns among users. For this reason, ESCORT stores the policy configuration of new SQL requests in a shared cache pool on the server-side. Whenever, the server receives an SQL request, ESCORT checks if the policy configuration is already cached in the shared pool. If this is the case, ESCORT retrieves this policy configuration from the cache and avoids performing the policy compaction and join mechanisms every time a new SQL request is received.
3.1.2 Policy Compaction
The policy information is initially stored in a high-level format on the server side. This high-level policy representation allows the database administrator to easily specify and customize the policy configuration using intuitive and flexible concepts and terms. Before delivering the policy configuration to the client device, there has to be a mechanism that converts the high-level policy representation into a low-level binary representation that is understood by the wireless device’s runtime environment. For this reason, ESCORT introduces the Policy Compactor component. This component is responsible for parsing the high-level policy configuration file and converting it into a compact binary representation before transmitting it to the client device. The policy compaction and optimization mechanism plays a major role in reducing the network traffic and the storage and processing requirements on limited-resource wireless devices.
3.2 The Security Engine
The Security Engine is the component responsible of securing the integrity and confidentiality of the database records on the client device. 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 database records. The security services supported by the Security Engine are controlled and configured based on the information present in the policy configuration which provides the primary information source the Security Engine consults for taking security decisions. The operation of the Security Engine in encrypting database records is described in Fig. 3. The functions and notations used in Fig. 3 are described below: • Database Recordi : This is the ith database record in the relational database object retrieved from the RDBMS. Still this database record has to go to the Security Engine to be secured and transmitted over the network. • Secure Database Recordi: This is the secure database record produced by the Security Engine after applying the policy confidentiality and integrity rules on the ith database record (Database Recordi). • Fn ( i) : This is the nth field in the ith database record. • SKi : This is the ith source key. SKi is a hash of SKi – 1. It completely overwrites SKi – 1 and derives the ith encryption keys used to secure the confidentiality of Database Recordi. Since
3.1.3 Policy Security
The security policy in ESCORT contains sensitive information that controls the various security operations of the Security Engine. Any malicious modification to this information may lead to dangerous security attacks (consider the scenario where all the security modes are maliciously modified to the Secure_None mode or where all the security levels and the integrity enforcement parameters are nullified). Thus, assuring the integrity of the policy information over the network links must be given exceptional attention. ESCORT secures the policy configuration integrity by signing this policy information with the private key of the application provider and appending the resulting digital signature to the policy configuration. When the policy configuration is loaded on the client device, the Security Engine component checks its validity by verifying the digital signature appended to it using the policy authority public key. It should be noted that this policy loading mechanism doesn’t depend on the
346
Secure Database Recordi - 1
Database Class Policy_Enc HEK i-1 , MEK i-1, LEK i-1 (F1( i-1) , F2( i-1) , … , Fn( i-1))
1) Security Engine determines the Database Class that database recordi belongs to 2) Encryption Keys generation HEKi = SHA-1(SK i) MEKi = HAVAL (SK i) LEKi = MD5 (SK i) 3)Policy_Enc HEK i , MEK i , LEK i (F1( i) , F2( i) , … , Fn( i)) 4) Scrub HEKi , MEKi , and LEKi from memory 5) HCHi = HASH (HCH i -1 , FFH(Policy_Enc HEK i , MEK i , LEK i (F1( i) , F2( i) , … , Fn( i)))) 6) MACi =MACSK i (HCH i) 7) SK i +1 = HASH (SK i) 8) Delete SKi
Security Policy
SK i= HASH (SK i - 1)
Secure Database Recordi
HCH i -1 MAC i -1
Database Class
Policy_Enc HEK i , MEK i , LEK i (F1( i) , F2( i) , … , Fn( i))
HCH i
MAC i
Figure 3. Securing Database records by the ESCORT Server-side Engine Table 1. ESCORT database server implementation specification and performance A verag e N u m b er of R ow s en cry p ted /Seco n d (E S C O R T a p p ro ach ) J a va .N et .N et R u n tim e 1 .1 2 .0 1 .5 .0
A verag e N u m b er of R ow s en cry p ted /Seco n d (T ra ditio n al a p p ro ach ) J a va .N et .N et R u n tim e 1 .1 2 .0 1 .5 .0
DBM S
O p era tin g S y stem
CPU
RAM
O racle 1 0 g R 2
R ed H at Lin u x E n terp rise S erver 4
P en tiu m 4 2 .2 G H z
D D R 266 M H z 5 12 M B
2 505
NA
NA
1 012
NA
NA
O racle 1 0 g R 2
W in d ow s S erv er 2 0 03 E n terp rise E dition S P1
P en tiu m 4 2 .2 G H z
D D R 266 M H z 5 12 M B
2 418
2 502
2 366
9 65
7 12
9 05
S Q L S erver 2 000 S P 4
W in d ow s 2 00 0 A d van ced S erver S P 4
D u al P rocessor P en tiu m 4 2 ×2 .0 G H z
D D R 266 M H z 2 GB
3 116
2 961
3 185
1 211
1 104
1 186
S Q L S erver 2 000 S P 4
W in d ow s S erv er 2 0 03 E n terp rise E dition S P1
P en tiu m 4 2 .6 G H z
D D R 333 M H z 5 12 M B
2 133
1 907
2 088
7 54
6 12
6 82
S Q L S erver 2 005
W in d ow s X P S P 2
P en tiu m 4 2 .2 G H z
D D R 266 M H z 7 68 M B
2 423
2 355
2 494
8 97
7 21
9 17
Table 2. ESCORT desktop client implementation specification and performance A verage number of row s decrypted/second (E SCO RT approach) Java R untime .N et 1.1 .Net 2.0 1.5.0
Average number of row s decrypted/second (T raditional approach) Java Runtime .Net 1.1 .N et 2.0 1.5.0
O perating System
CPU
RAM
Fedora Linux 4
Pentium 4 2.8 GH z
D D R 266 M Hz 512 M B
4975
NA
NA
1387
NA
NA
W indows XP SP2
Pentium 4 2.2 GH z
D D R 266 M Hz 768 M B
3877
2491
2722
1065
713
918
W indows XP SP2
Pentium 4 2.6 GH z
D D R 266 M Hz 512 M B
3933
3744
3842
1257
1106
1292
Solaris 10 (X 86 E dition)
Pentium 4 2.8 GH z
D D R 266 M Hz 512 M B
4988
NA
NA
1415
NA
NA
Table 3. ESCORT mobile client implementation specification and performance
Operating System
CPU
RAM
Average number of rows decrypted/second (ESCORT approach)
Average number of rows decrypted/second (Traditional approach)
Java Runtime MIDP/CLDC
.Net Compact Framework 2.0
Java Runtime MIDP/CLDC
.Net Compact Framework 2.0
Windows Mobile 2003 (second edition)
Samsung S3C 2440 300 MHz
56 MB
NA
182
NA
73
Symbian OS 7
ARM 9 153 MHz
28 MB
110
NA
51
NA
Symbian OS 7
ARM 9 104 MHz
6 MB
62
NA
27
NA
347
SKi is produced using a one-way hash function, an attacker capturing SKi can’t derive SKi -1, SKi – 2,… SK0 • HEKi, MEKi, and LEKi: These are the High, Medium, and Low encryption keys for encrypting the ith database record. They respectively represent the high, medium, and low security levels specified in ESCORT’s security policy. HEKi is a 256bit key. It is generated by hashing SKi using a 256-bit-output hash function, such as SHA-1. MEKi is a 192-bit key. This key is generated by hashing SKi using a 192-bit-output hash function, such as HAVAL. LEKi is a 128-bit key. It is generated by hashing SKi using a 128-bit-output hash function, such as MD5. • Policy_Enc HEK i , MEK i , LEK i (F1( i) , F2( i) , … ,Fn( i)): This function encrypts Database Recordi fields according to the rules specified in the security policy. The High_Security, Medium_Security, and Low_Security levels are provided using the HEKi, MEKi, and LEKi encryption keys respectively. Note that some fields and field portions may not be encrypted. Moreover, different field portions may be encrypted using different encryption strengths. (See Fig. 3). • FFH(Policy_Enc HEK i , MEK i , LEK i (F1(i) , F2( i) , … , Fn( i))): This function extracts from the Policy_Enc function output, the secure fields whose Integrity_Enforcement parameter is set to Yes in the security policy. These secure field values are concatenated and included in the hash chain that guarantees the integrity of the database network object. • HCHi: This is the hash chain constructed by hashing the output of the FFH function and the hash chain entry of the previous secure database record (HCHi – 1 of Secure Database Recordi - 1). Since HCHi includes HCHi -1, it is possible to verify the integrity of all previous secure database records by only authenticating HCHi. Initially, HCH-1 must be given a default value to start the hash chain. • MACi: This is the MAC of HCHi under the key SKi + 1. MACi is used to authenticate HCHi. Since SKi + 1 is derived using a one-way hash function from SKi, the attacker will not be able to deduce SKi and as a result the encryption keys HEKi, MEKi, and LEKi derived from SKi are also protected. On the client device, SK0 is used to generate all subsequent source and encryption keys. The Security Engine decrypts the secure database object according to the specification of the security policy, checks the validity and authenticity of the hash chain using the HCH and MAC entries, and makes sure that the database network object doesn’t contain any traces of a possible malicious attack. It should be noted here that the verification of the authenticity of the hash chain can be done without decrypting the database records, since the hash chain depends in its construction on the encrypted fields of the database record.
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 3), to 330% on average on the PC clients (Table 2.)
4. ESCORT IMPLEMENTATION AND PERFORMANCE
[7] U. Mattsson, "Database Encryption - How to Balance Security with Performance", ITtoolbox Database: http://database.ittoolbox.com/documents/peer publishing/database-encryption-how-to-balance-securitywith-performance-4503, July 2005.
5. CONCLUSION
In this paper we presented ESCORT, an enterprise security protocol for protecting the confidentiality and integrity of database network objects. ESCORT supports a policy-based architecture that employs flexible and efficient encryption and hashing mechanisms. ESCORT is designed in a platform-neutral manner and is implemented and tested on a wide range of clients and database servers. We showed that ESCORT provides a performance gain of a factor of three, compared to bulk encryption.
6. REFERENCES [1] A. Freier, P. Karlton, and P. Kocher, "The SSL Protocol Version 3.0", Internet-Draft, November 1996. [2] T. Dierks and C. Allen,"The TLS Protocol – Version 1.0", Internet –Draft, November, 1997. [3] W. Itani and A. Kayssi, “SPECSA: a Scalable, Policy-driven, Extensible, and Customizable Security Architecture for Wireless Enterprise Applications”, in Proceedings of the IEEE IPCCC Workshop on Information Assurance (WIA04), April 2004, Phoenix, Arizona. [4] W. Itani, A. Kayssi, and A. Chehab, “PATRIOT – a PolicyBased, 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. [5] J. He and M. Wang, "Encryption in relational database management systems. In Proc. Fourteenth Annual IFIP WG 11.3 Working Conference on Database Security (DBSec’00), Schoorl, The Netherlands, 2000. [6] A. Newman, "Encryption of Data at Rest", ITtoolbox Database: http://database.ittoolbox.com/whitepapers/encryption-of-data-at-rest-1922, May 2002.
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 ESCORT 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. The implementation and tests were performed on Linux and Windows servers, running Oracle and SQL Server, respectively, as shown in Table 1. Client platforms included Linux, Solaris, and Windows, as shown in Table 2, and Windows Mobile and Symbian, as shown in Table 3. Tables 1 – 3 further show the hardware and software specifications for servers and clients. The
[8] Transparent Data Encryption (TDE) in Oracle 10g Database Release 2, Oracle-Base: http://oracle.ittoolbox.com/documents/industryarticles/transparent-data-encryption-tde-in-oracle-10gdatabase-release-2-3824, October 2005. [9] V. Gupta and S. Gupta, “Securing the Wireless Internet,” IEEE Communications, December 2001.
348
