Design and Implementation of a Secure Web-Based File 1 1 Exchange Server 0 2 Specification Design Document n a J 4 2 CIISE Security Investigation Initiative ] R C . s Represented by: c [ 1 v Serguei A. Mokhov 0 4 Marc-Andr´e Laverdi`ere 6 4 Ali Benssam . 1 0 Djamel Benredjem 1 1 {mokhov,ma laver,al ben,d benred}@ciise.concordia.ca : v i X r a Montr´eal, Qu´ebec, Canada December 14, 2005 Contents 1 Introduction 1 1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Definitions and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 System Architecture 4 2.1 Architectural Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.4 LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.5 Certificate Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.6 Logging Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Software Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.1 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.2 Database Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.3 LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.4 Certificate Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.5 Logging Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Hardware Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6 Code View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 i Simple Secure Web-Based File Exchange Design ii 3 Detailed System Design 11 3.1 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.1 LDAPConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3.2 UserCredentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.3 OptionsFileLoaderSingleton . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.4 DatabaseConnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4 Data Storage Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4.1 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5 Options File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6 Directory Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.7 External System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.7.1 External Systems and Databases . . . . . . . . . . . . . . . . . . . . . . . . 20 3.8 User Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8.1 Typical Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8.2 Variant scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8.3 Variant scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.9 Administrator Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.9.1 Typical Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.9.2 Variant Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.9.3 Variant Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Bibliography 23 Chapter 1 Introduction Building Trust is the basis of all communication, especially electronic one, as the identity of the other entity remains concealed. To address problems of trust, authentication and security over the network, electronic communications and transactions need a framework that provides security policies, encryption mechanisms and procedures to generate manage and store keys and certificates. The Public Key Infrastructure (PKI) is a security architecture that has been introduced to pro- videanincreasedlevelofconfidencefor exchanginginformationoverincreasinglyinsecurenetworks, such as the Internet. A PKI infrastructure is expected to offer its users a secure and trustworthy electronic transaction. 1.1 Purpose The intent of implementation and deployment of PKI facilities is to meet its basic purpose of providing Trust. Presently, PKI needs to perform the following security functions: • Mutual authentication of entities taking part in the communication: Only authenticated prin- cipals can access files to which they have privileges. • Ensure data integrity: Byissuingdigitalcertificateswhichguaranteetheintegrityofthepublic key. Only the public key for a certificate that has been authenticated by a certifying authority should work with the private key possessed by an entity. This eliminates impersonation and key modification. • Enforce security: Communications are more secure by using SSL to transmit information. 1 Simple Secure Web-Based File Exchange Design 2 1.2 Scope PKI is implemented to secure sensitive resources of the organization and avoid security breaches. The PKI environment allows trustworthy communication between the different principals. These principals must be authenticated and the access to the resources (files) should be secured and regulated. Any principal wants to access to the database needs to perform the following steps: • Mutual authentication: The Web Server via which the database is contacted authenticates the principal using its digital certificate and username to ensure that it is who it claims to be . The principal authenticates also the server using its certificate information. • Principal validation: Tovalidatetheprincipal, theserverlooksupinformationfromanLDAP server which contains the hierarchy of all principals along with certificates and credentials. The LDAP service is compliant with the X.500 database structure. • Enforcing security: The security is enforced by using SSL to communicate between the Web Server and the LDAP server, the Web Server and the database and between the principal and Web Server. • Principal authentication: Upon successful authentication, the Web Server will allow the prin- cipal to perform actions on the database according to a pre specified Access Control List. • Kinds of users: We distinguish between a normal and an administrator. While a normal user can upload, download, delete and view files; the administrator has the ability to: upload, download, delete and view files; add, delete and modify users; generate user’s certificate, with all required information; generate ACL to users; manage groups, perform maintenance. Finally, thisinfrastructureallowsadditionalfeaturessuchastheabilitytoassignuserstogroups in order to provide users with the access to files prepared by other group members. 1.3 Definitions and Acronyms • PKI: Public Key Infrastructure • OpenLDAP : is a free, open source implementation of the Lightweight Directory Access Protocol (LDAP). • OpenSSL: an open source SSL library and certificate authority • Apache Tomcat: A Java based Web Application container that was created to run Servlets and JavaServer Pages (JSP) in Web applications Simple Secure Web-Based File Exchange Design 3 • PostgreSQL: An open source object-relational database server • SSL: Secure Socket Layer • JSP: Java Server Pages • JCE: Java Cryptography Extension • API: Application Programming Interface • JDBC: Java Database Connectivity • JNDI: Java Naming and Directory Interface • LDAP: Lightweight Directory Access Protocol • X.509: A standard for defining a Digital Certificate used by SSL • SRS: Specification request Document • SDD: Specification Design document • DER: Distinguished Encoding Rules • Mutual Authentication: The process of two principals proving their identities to each other • SFS: Secure File Exchange Server, this product • COTS: Commercial Off The Shelf, common commercially or freely available software Chapter 2 System Architecture This chapter is intended to provide an overview of the whole system as proposed in the previous requirements and specification document. It describes the product’s perspective, interfaces and design constraints as we have assumed. We will first describe the architectural guidelines for this product, followed by software interface design design, and hardware environment. 2.1 Architectural Philosophy The SFS technology hereby implemented is running on architecture that provides a high level of secrecy and integrity for exchanging information. The system is externally visible only through a web application for normal users, and is also entirely visible and accessible for administrators in the scope of normal operations. In addition, the system assumes an internal certificate authority which is explicitly trusted by all principals using SFS. For the proposed architecture, it requires mutual authentication between the user and the web server, an LDAP validation of the user by using digital certificates, the use of the SSL protocol to enforce the security over the communication between modules and the preservation of files in a database. This architecture must respect the following properties: • Security: The confidentiality, integrity and availability of information. This is to be imple- mented by supporting the data encryption and certificates mechanisms for secured commu- nication, as well as specifying an access control mechanism for the files stored • Trustworthiness: The use of electronic certificates internally generated, and of specific use for the application, allow an high trust to be given to the user. • Scalability: SFS can be expanded easily to cope with large loads. Methods such as load balancing and replication can be easily integrated. 4 Simple Secure Web-Based File Exchange Design 5 • Openness: The proposed architecture can be implemented and deployed using Java Tech- nologies and open source tools that are well-used and rely on standards. The SFS itself is an open source product developed to achieve security objectives. • Component-Based Software Engineering: The SFS framework may be treated as components (modules) . We have already mentioned the relevant technologies that can better fit for each of these modules. • Usability: The SFS service must be designed for high usability. All the required information for a single operation should be grouped in a single screen, with a minimum number of screens needed for all the application. This architecture aims at maximizing software reuse by the integration of COTS applications, portability and interoperability by the use of standards, security and scalability by the user of a single access point. 2.2 Components The Figure 2.1 describes the overall architecture of the SFS system. We see four major inter- acting components: the user interface, the web server, the database and the LDAP server. Two components are not displayed on this figure , which are the certificate authority and the logging engine. 2.2.1 User Interface The user interface constitutes of HTML web pages that the user uses through a web browser. Those web pages are generated by the web server and interact exclusively with the SFS web server. 2.2.2 Web Server The web server is the single access point of the system. It handles authentication responsibilities, database access and user interaction. This is to be handled by the Apache Tomcat 5.0 server and custom J2SE 5.0 code. 2.2.3 Database Server This database server contains all the information about the files and their access control rights. It contains also a subset of the user information. This is to be handled by PostgreSQL. Simple Secure Web-Based File Exchange Design 6 Figure 2.1: Main system architecture Simple Secure Web-Based File Exchange Design 7 2.2.4 LDAP Server This specialized server holds the user credentials (notably user name and password). It could be extended to include user certificates. This module will be realized by OpenLDAP. 2.2.5 Certificate Authority This responsibility is manually managed by administrators. Using software tools, they are able to generate the user and server certificates. In our case, we use OpenSSL to perform those functions. 2.2.6 Logging Engine This component is responsible for collecting the audit trails and debug information from other components and store it locally. We wanted to use log4j, but we finally opted for the logging mechanisms available in the tools we are using, notably by using Tomcat’s logging. 2.3 Interactions We will now describe the inter-module interactions by the use of a system scenario. The user, with a web browser, connects to the web server using SSL. The web server, being configured as to require client authentication, both parties exchange their certificates and validate their peer’s identity. The web server then prompts the user for a user name and password, thereby enforcing 2-factor authentication. Upon receiving this information, the web server queries the LDAP directory based on the user name and retrieves the user’s password hash and certificate (if any is defined). The web server then proceeds to hash the plaintext password (using SHA1) received from the user and compare with the one from the LDAP server. If that information (as well as the certificates, if any) matches, the user is logged in the system. The web server will then query the database server for the access rights of the user (adminis- trator or normal user) and the list of files the user has access to. Based on this information, it will display the appropriate user interface functions and the file list. On user requests to upload, delete or download files, the web server will request the database server to perform the needed transactions.