Securing applications in the Demostene projects - CiteSeerX

Securing applications in the Demostene project G. Dall’Agnola1, M.G. Fugini1, A. Lioy2, F. Maino2, F. Maio1, D. Mazzocchi2

Abstract This paper describes the experience in securing distributed applications gained in the Demostene project, funded by the Italian National Research Council (CNR). The project aimed to provide security for distributed systems in the heterogeneous environments found in the information systems of the Italian Public Administration. The work was based on the common authentication framework offered by X.509 certificates, used to authenticate both users and services. Specifically this technique was adopted in the JAVAGLAD tool to connect distributed databases in a secure way, and in the development of secure versions of Telnet and FTP with certificate-based access control lists.

1. Introduction The Demostene project (DEMOstrantor of Security TEchnologies in a Networked Environment). was funded by the Italian National Research Council (CNR) and aimed to provide security in the heterogeneous distributed systems found in the Italian Public Administration. The work described in this paper is part of the whole project and was performed by the security groups of Politecnico di Torino (network security and electronic signatures) and Politecnico di Milano (security of federated distributed databases). The common foundation between the two groups is the extensive usage of X.509 certificates to provide authentication in different applications. User partners were offices of the Italian Department of Justice and of local administrations (e.g. Regione Lombardia) that contributed by expressing requirements and testing the methodologies and the tools. Currently, the most widely deployed systems for network security are those based on digital signatures and X.509v3 certificates because they are already available in standard commercial products: those that offer SSL (or TLS) for secure Web and S/MIME for secure e-mail. As the project’s users were already accustomed to using digital certificates for authentication purposes in the Web and e-mail areas, we wanted to extend the reach of these certificates to other areas as well. Therefore we looked at various insecure applications and developed solutions based on X.509v3 certificates. In particular, the work focussed on three areas: 1. Access to a federated database, which is protected through the JavaGlad tool developed at Politecnico di Milano. The system considers the authorisations existing in the local databases and analyses their compatibility with the security requirements of the federation. JavaGlad is accessed and administered through a standard Web Browser, that uses Transport Layer Security (TLS) [DiAl99] for mutual authentication and privacy (which is especially needed when the access occurs from outside the Intranet).

1 2

Politecnico di Milano, Dipartimento di Elettronica e Informazione Politecnico di Torino, Dipartimento di Automatica e Informatica

2. Interactive access to remote computers, to perform management functions (system management, Web site management) or to run interactive applications (e.g. 3270 emulation for legacy database access). This is protected by using a modified TELNET protocol, layered on top of TLS for authentication and privacy. These aspects have been studied by Politecnico di Torino. 3. Network file transfer, to store and retrieve data from large FTP data repositories or from nodes that do not want to implement a full Web server. This is protected by using a modified FTP protocol, layered on top of TLS for authentication and privacy. Also these aspects have been studied by the group at Politecnico di Torino. The paper is organised as follows. In Section 2 the JavaGlad tool for database security is described: architecture, users, functionality. In Section 3, details about the JavaGlad implementation in a networked environment are given and examples of tool usage are provided. Section 4 discusses issues in adding Transport Layer Security to TELNET and FTP, both in Unix and Windows environment. Finally, concluding remarks and future work are reported in Section 5.

2. The JavaGlad tool Most of the database systems that are currently being constructed are a network of existing databases. Conventional security policies, such as need-to-know policies, usually hold for these databases [CaFu95]. In the paper, we use the term federated database (or global database) to denote a networked aggregation of existing databases. In fact most organisations, and Public Administrations as well, are currently facing the problem of re-engineering, or connecting their (legacy) databases to form a database federation, rather than constructing a true, distributed database from scratch. Therefore, policies for data sharing have to be defined when data are exported from local databases towards the distributed environment since not all the data of a database that joins the federation should or need to be visible in the federation. A prototype tool (JavaGlad) has been developed to secure access to federated databases. The tool automates the export of access authorisations from a local database to the federation. Starting from user-provided security policies for exported data, the tool analyses the consistency of all exported authorisations, reports possible inconsistencies to the administrators, and eventually stores valid authorisations in a global catalogue called Global Authorisation Dictionary. The dictionary is then checked at run-time for access control upon each access request to federation data. The JavaGlad tool implements the algorithms presented in [CaDe98] regarding the derivation of authorisations in a federated Information System. These algorithms consider the authorisations existing in the local databases, and analyse their compatibility with the security requirements of the federation. Then, it manages the authorisations in the federation using various modules that are described in the following. The global JavaGlad architecture is depicted in Figure 1. For sake of simplicity, we will consider a federation of homogeneous databases (e.g. relational databases). However, the tool can manage also heterogeneous databases, since its functionality depend only on the schema of the federation (the Federated Schema in Figure 1) that has to be designed in a way that integrates the various data models of the sites.

Web Browser (Administrators)

Central Federation Server Web Server

DBA1 . . .

JavaGladApplet Local/Global Authorization Manager

DBAn

GLAD Module Pure Java Connection (JDBC)

Browser Web (Users)

Access Control Module Federated User

Federated Schema

Global Global Authorization Authorization Dictionary Dictionary

Federated Local User

Internet/Intranet Server1

Servern LEA1 CS1

DB1 DB1

LEAn

...

CSn

DBn DBn

IDS Server

IDS Server

Figure 1, JavaGlad Architecture JavaGlad is composed by the following modules: •

The JavaGlad application, running on the Central Federation Server as a Java applet. It is downloaded by the Web Browsers of users or administrators at connection time, and is locally executed. The users of the federation can have different requirements, and accordingly have different security profiles. As discussed in [CaDe98], we distinguish among the following main profiles: •

federated user: he/she accesses only the resources belonging to the federation, e.g. shared data and documents, global applications, shared resources that have been defined as shared in the global system.

•

local federated user: he/she usually work locally, using local data on which he/she has local privileges. Sometimes he/she also logs into the federation to access shared data, and in this case has global privileges as a federated user. Usually his/her global privileges are different from the local ones, even when they apply to the same physical resource. The reason is that the same physical resource can be renamed, or mapped into, a different logical resource when exported to the federation.

•

local administrator; this user is usually the DBA of the local databases. He/she has all access and administration privileges on the local databases. He/she is also in charge of defining and implementing the sharing policies of the federation in cooperation with other local administrators and with the administrator of the federation.

•

federation administrator; this user is the DBA of the federation. He/she administers the shared resources and holds all access privileges on them. He/she is responsible for coordination of the security policies and for their enforcement at the federation level. He/she holds no privileges on local databases, and can instead only negotiate access to them with the local administrators.

Depending on the user who gets connected, the execution of the JavaGlad application is started in various modes through different functionality. The front-end tool is always the Web Browser both for administration activities and for normal access to single component databases. •

•

The Web Server of the federation is located within the Central Federation Server. It manages: •

the authorisation repository of the federation (Global Authorisations Dictionary), where all the global privileges are stored.

•

the schema of the shared data (Federated Schema), describing in an integrated way all the data of the federation, that is, the data that have been set up as shared out of the component databases. Note that no physical data are maintained at the global level but rather only their description or schema.

The Local Servers located on different physical sites of the network. Each server is equipped with: •

An IDS Server, that is, a middleware component implemented in the Java technology supporting the networked sharing of the local DBMSs;

•

The schema of the i-th component database described via a relational schema (Component Schema - CSi)

•

The local authorisations that have been exported, defined by the administrator of the i-th component database (Local Exported Authorisations - LEAi).

The JavaGlad application is in turn composed of three main modules: 1. The Local/Global Authorisation Manager: this supports the administration of the authorisations that have been exported by each component database. It takes care of their mapping into global authorisations. In fact, a data resource at the global level can correspond exactly to one data resource in a component database, or can be an aggregation (or an integration) of various local resources. Managing the mapping of global-to-local objects is an issue of the Federated DBMS engine. Managing the mapping of authorisations is instead a problem of the Local/Global Authorisation Manager. It has to maintain a correct mapping between the privileges of the global object and the privileges of the local object(s) that correspond to it. It also manages the global authorisations for those data which exist only in the federation, or that are not automatically derived from existing local privileges but rather defined directly by the federation administrator. 2. Glad Module: this module implements the algorithms for automatic derivation of global authorisations from authorisations exported by component databases. Optimisation algorithms are implemented regarding the construction and maintenance of the Global Authorisations Dictionary. The Glad Module also manages that portion of the federated schema FS containing the description of the mapping between global data and local ones. 3. Access Control Module: this module is in charge of run time checking of user access to the federation data. It consults the Global Authorisation Dictionary and employs an Access Control List (ACL) protocol, as will be illustrated in the following sections. This is the same protocol which is also used for the server site implementation in the Certified Access to the Central Federation Server implemented by Politecnico di Torino for the part regard adding transport layer security to TELNET and FTP (see Section 4).

3. JavaGlad, ODBC and Internet/Intranet Connections In this section, we show in some more detail, especially regarding implementation issues, how JavaGlad manages the connection to Internet/Intranet and, internally, to the authorisation dictionaries. Figure 2 Figure 2 shows how the Central Federation Server of Figure 1 interfaces the external world of Client administration applications via a communication protocol secured through SSL. Also the interface towards users is secured under SSL.

Client1

WEB Server

...

IDS Server

HTML Page

Internet/Intranet Access

IDS Server IDS Server Control Applet

CS 1 + CS + LEA 11 LEA 1

JDBC

... ODBC

SSL

Clientn

JavaGlad Applet

CS n + CS n + LEA n LEA n

Access Control Module Local/Global Administrators

Administration Module FS FS

Glad Module

Central Federation Server

Global Global Authorization Authorization Dictionary Dictionary

SSL

Internet/Intranet Access

Local/Global Users

... User1

Usern

Figure 2, External Interfaces of the Central Federation Server Internally, the Central Federation Server interfaces using an IDS Server interface the database that implements the Global Authorisation Dictionary. From the Web Server site, an IDS Server Control Applet interfaces an IDS Server that interconnects the different databases storing: 1. The Federated Schema 2. The Global Authorisation Dictionary 3. The ODBS interface to the databases that store remotely, that is, at each site:

3.1.

•

the Component Schemas - CSi ( the data schemas of the federation component databases) and

•

the Local Exported Authorisations – LEAi, that is, the authorisations that each component database has decided to export and that have been checked for consistency with the global environment by the Glad Module.

Sample user interactions with JavaGlad

Here, we report some of the main screens of the JavaGlad prototype.

JavaGlad can work both from within a common application or as a Java stand-alone application through any Java interpreter on any platform. The tool is compose of six sections: 1. Connection 2. Local Schema Manager 3. Federation Schema Manager 4. Exported Authorisation Manager 5. Global Authorisations Manager 6. Access Control Test

CONNECTION Using this screen (see Figure 3) the administrator can connect to the Federation Server in order to perform tasks such as integration and updating of schemas or management of global authorisations. The same screen can be accessed also by local administrators who get connected to the local decentralised Servers in order to manage the schemas of the component databases, and the exported authorisations.

Figure 3, Connection Screen Users are authenticated and then the connection to the reference server is activated. Now users can access the other tool modules. In particular,

•

local administrators access the following TABs : Local Schema Manager, Access Control Test, and Exported Authorisations Manager;

•

the federation administrator accesses all the TABs.

LOCAL SCHEMA MANAGER This screen (see Figure 4) includes functions to manage the component database schemas, that is, objects, subjects, and relationships between objects (we mean here data objects). For each object, the associated properties can also be visualised, added, or removed. Each object, subject and relationship is formally denoted via a reference to the schema it belongs and via its code/denomination (using a dot notation).

Figure 4, Local Schema Manager Screen FEDERATION SCHEMA MANAGER This screen (see Figure 5) is similar to the previous one. Elements managed here are also genericity relationships between objects of the Federated Schema and objects of the local schemas. In the denomination of the schema elements, the FS is used followed by the element code/denomination (using the dot notation). It is possible to see, add, remove object properties.

Figure 5, Federation Schema Manager Screen In the dialogue window of Figure 6, we show the adding of an element of type "object" to the FS starting from the TAB "Federation Schema Manager". It is specified that an object of type “integrated” is identified, that is, obtained as a global object by integrating local objects using one of well-known data/schema integration techniques for databases.

Figure 6, Adding an object to the FS EXPORTED AUTHORIZATIONS MANAGER In this screen, the administrators of component databases can decide which authorisations can be exported to the federation. In the upper part of the screen, the tool allows one to define object-level or property-level authorisations. In the low part of the screen, the various authorisations to be exported are listed, with the option to remove those that are no longer necessary. As an example, in Figure 7, the administrator of component db CDB2 exports the authorisation for user “Meg” to read founding information (CDB.Found) about new projects. Such authorisation will then be checked by the GLAD module for consistency with other global authorisations.

Figure 7, Exported Authorisation Manager Screen GLOBAL AUTHORIZATIONS MANAGER This screen (see Figure 8) allows the definition of authorisations on global object described in the FS, upon decision of the federation administrator. The list of the authorisations defined at the federation level contains the authorisations both at the level of single object and at the level of properties defined on each single object. In the central part of the screen, two buttons are defined: •

"Derive Global Auth": it allows one to activate the derivation algorithms starting from local exported authorisations. New authorisations are added to the list in the lower part of the screen

•

"Optimise Global Auth": it allows one to remove from the list the redundant global authorisations. For example, if a "read only" mode is defined for each properties of an object, these authorisations will be remove from the list and substituted by a unique "read only" authorisation at the object level.

Figure 8, Global Authorisations Manager Screen ACCESS CONTROL TEST This screen (similar to the previous ones) allows the system to check and monitor the user access to the federation data. Authentication is executed from within this screen; then, the list of objects allowed for the authenticated user is shown. The user get connected via his/her Web Browser (using the CONNECT TAB) and then is faced by the access control test screen to which he/she provides his/her username and password. He/she requires a certain access mode (currently read and write are implemented) on a specified federation object. Access control is therefore implemented on an ACL basis. A distinction is made in the tool between: § objects of type “imported” and “integrated”, that are derived from local objects, and § “federated” objects, that have been defined by the federation and do not map to any local object. In fact, some users can access only the second type of objects. For the first type, the screen shows also the local objects that can be accessed and denote their location.

4. Adding Transport Layer Security to TELNET and FTP Now, let’s consider those users that need to interactively access remote computers to perform oldstyle tasks, such as transfer files from an FTP site or perform an interactive login for system management or to run text-based applications (e.g. VT-100 or 3270 applications). As the standard tools for these tasks (TELNET, TN3270, FTP, RLOGIN, RCP) are insecure, they shouldn’t be used

in a sensitive environment. A secure suite for such tasks is offered by the SSH-based applications, but they are not based on X.509 certificates and hence would require the setup of a completely different security management environment. On the contrary, the users targeted by this project were already provided with an X.509 certificate to access secure Web servers and protect their e-mail with S/MIME. Some of the users were also provided with an RSA smart-card, for increased security. It was therefore decided to extend the reach of this kind of authentication to the remote interactive connections. We assumed that the generation of the asymmetric RSA private and public keys and the certificate management would be carried out via a Web browser. Therefore we decided to use as local PSE (Personal Security Environment) for each user a file fully compliant with the PKCS#12 standard [Pkcs99] and automatically accessed by the client applications. This file would store all the cryptographic material needed by the secure applications: the user’s private key and public-key certificate as well as the certificate chain of the trusted CA hierarchies. We therefore implemented X.509 secure clients and servers for the TELNET and FTP protocols, with servers available only for Unix environments and clients available for both Unix and Windows. Security was provided by layering the protocol on top of a TLS (Transport Layer Security) channel [DiAl99]. This provided us with several security features: •

X.509 based server authentication, so that the user doesn’t have to trust any more the host banner to identify it

•

X.509 based client authentication, which is optional in TLS channels but we required to access any server in our environment

•

automatic data integrity and privacy (based on fast symmetric algorithms) in a way transparent to the layered applications

The implementations are based on the free software library OpenSSL [OpenSSL], formerly known as SSLeay. This is a powerful toolkit that can be used to add SSL and TLS support to a variety of applications based on TCP/IP. However the implementation process was not straightforward and raised several issues. In the implementation of the TELNET client, we analysed various open source distributions. We found a lot of obsolete implementations that were inappropriate for the most recent programming toolkits. Finally we found TeraTerm [TeTe99], a recent and well coded implementation of a TELNET client that provides a nice API that can be used to add various functionalities through plugins. Unfortunately the API doesn't permit access to the low level details of the communication protocol and this was required to add support for TLS. Therefore we couldn't simply write a TLSplugin for TeraTerm, rather the modification of the core module was required. Another problem faced in the implementation of both applications is that the OpenSSL library has been originally written for Unix systems, and its Windows version doesn't fit well with application based on the Microsoft Foundation Classes. A lot of work was then required to make the library work with such Windows applications. The TELNET application (shown in Figure 9) is graphical one, as this needed to perform terminal emulation. In addition, a simple interface allows the user to enable TLS on the connection, specifying the username on the remote server, the location of the PKCS#12 file containing her PSE, and the file where the chains of trusted CA’s certificate is kept.

Figure 9, TELNET interface to TLS parameters On the server side of the implementation, the most relevant aspect is the definition of an Access Control List (ACL) that maps the Distinguished Name contained in the X.509 certificate presented by the user onto a local OS identity (i.e. username). This is useful in order to avoid a double authentication of the user: in our idea the authentication based on the X.509 certificate should completely replace the traditional one based on username and password. If the client does not specify a username to be used, the server checks its ACL that might contain a reference to the default username for the owner of the certificate presented by the client. To implement this ACL, we currently use a file that maps each Distinguished Name onto one or more local usernames. This file is digitally signed by the system administrator to prevent forgery and manipulation. The certificate acts as the principal for authentication, and the local identity used to access the system is determined using the ACL. If the ACL contains more than one entry, or no entries at all are present for a specified Distinguished Name, a login process is emulated asking for the username (but not the password) that will be actually used to access the system. This feature has been easily achieved for the FTP server, because the login process is embedded within the FTP daemon and was therefore very easy to modify to use the identity derived from the TLS client authentication. More problems were encountered in replacing the login process used by the TELNET daemon as it usually relies on the standard system login process. We particularly had this problem in the implementation of the TELNET server for Athena systems [ChGe90], where the login process is kerberized. In this case, it seemed to be more convenient to offer a double authentication mechanism: first-level access is granted or denied by TLS client authentication based on the X.509 identity and then the username and password needed to activate the Kerberos principal are exchanged on an encrypted channel.

Both the TELNET and FTP clients have been developed with smart-card support: the private key of the user can be stored on such a safe hardware device that provides a better level of security for cryptographic material. Please note that the use of smart-card doesn't affect in any significant way the performance of the application, because the hardware device is used only during the TLS handshake phase that happens only once during the login process. We used a Schlumberger CryptoFlex card that provides RSA and triple DES encryption capabilities. The card was used to store the private and public parameters of the RSA user’s key, together with her certificate kept in a plain file. We slightly modified the OpenSSL library in order to intercept the call to the RSA encryption functions and map them onto the RSA API provided with the smart-card. We are currently integrating LDAP support in the clients and servers to better manage a global ACL for all the servers and to retrieve the status of the certificates involved in the communications (i.e. to check for certificates that have been suspended or revoked).

5. Conclusions and future work In this paper we have presented the main results of the Demostene research project currently carried on by two Italian universities in collaboration with Public Administration offices. The feedback of our users, i.e., of the administrations, is positive in that the provided study seems to meet their requirements in the view of a total integration of existing systems for data and document exchange. The issue of system usability, flexibility, and performance remains to be tested and future work includes such evaluation. In particular, further work on JavaGlad regards the treatment of authorisations on heterogeneous data sources: databases, html pages, document and XML formats. Moreover, we plan to extend the tool to handle authorisations on workflows, i.e., on processes of the Public Administration that can be modelled as distributed workflows. Here problems of authorisations of agents/roles have to be treated, more that problems of data security. A preliminary proposal has been studied using authorisation triggers that react to security violation events and tested using standard Workflow Management Systems. On the side of providing secure remote access and file transfer facilities to the public administration offices, the work done shown that public key certificates can be used as the unifying authentication principal for accessing all the resources of an information system. The wide diffusion of devices such as the smart cards will be of great help for the diffusion of this technology and will provide an unified identification mechanism for an even wider set of applications.

Acknowledgements The work described in this paper was funded by CNR. The authors wish also to thank the many people from the Italian Public Administration that contributed by setting the security requirements for the distributed applications, and the general support of AIPA (Autorità per l’Informatica nella Pubblica Amministrazione).

References [CaFu95] S. Castano, M. G. Fugini, G. Martella, P. Samarati, “Database Security”, AddisonWesley, 1995 [CaDe98] S. Castano, S. De Capitani di Vimercati, M. G. Fugini, “Automated Derivation of Global Authorisations for Database Federations”, Journal of Computer Security, Vol. 5, No. 4, IOM Press, 1998

[ChGe90] G. A. Champine, D. E. Geer, W. N. Ruh, “Project Athena as a Distributed Computer IEEE Computer, pp. 40-51, Sep. 1990 [DiAl99] T. Dierks, C. Allen, “RFC 2246: The TLS Protocol 1.0”, IETF – Request For Comment, January 1999 [OpenSSL] The OpenSSL project http://www.openssl.org/ Cryptography Standards (PKCS), Version 1.0, June 1999 ftp://ftp.rsa.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf [TeTe99] TeraTerm Pro http://hp.vector.co.jp/authors/VA002416/teraterm.html