implementing a public-key infrastructure … · implementing a public-key infrastructure for the...

BULETINUL INSTITUTULUI POLITEHNIC DIN IAŞI Publicat de

Universitatea Tehnică „Gheorghe Asachi” din Iaşi Tomul LVII (LXI), Fasc. 3, 2011

SecŃia AUTOMATICĂ şi CALCULATOARE

IMPLEMENTING A PUBLIC-KEY INFRASTRUCTURE FOR THE ACADEMIC ENVIRONMENT

BY

MARIUS MARIAN∗∗∗∗ and ANDREI PÎRVAN

University of Craiova,

Department of Computers and Information Technology Received: August 23, 2011 Accepted for publication: September 14, 2011

Abstract. This paper presents a pilot deployment and implementation of a

public-key infrastructure within the IT academic environment of University of Craiova. PKIs are both useful and complex security-enabling instruments. Without a careful analysis and planning, it becomes difficult to find a way to alleviate its complexity and impact on end users and decision makers. Best practices concerning PKI can be derived from precedent and alternative experiences, and therefore they can help throughout the PKI setup and maintenance.

Key words: public-key infrastructure, security services.

2010 Mathematics Subject Classification: 91G20.

1. Introduction The need to protect information in transit is justified today by the

overwhelming means of communication available today and by the continuously increasing amount of critical data that is no longer processed on paper. The educational environments make no exception. ∗Corresponding author: e-mail: [email protected]

Marius Marian and Andrei Pîrvan

144

Our paper presents the implementation of a pilot infrastructure that was built, tested and currently is in operation within the Faculty of Automation, Computers and Electronics of the University of Craiova. This public-key infrastructure (PKI) will allow us to further analyse the security requirements and also the reaction of the local community that will use this security infrastructure. This analysis will be the test bed for the eventual growth of the PKI at a wider level by incorporating new certification authorities pertaining to other faculties or universities manifesting interest for the adoption of this security paradigm.

2. The Security Issues

After an internal security evaluation of the local IT environment, we have

found out that most of our academic IT services (dedicated local area networks, individual e-mail accounts, file-/web-servers, critical administrative applications and services) provided by and within the university are authenticated by means of usernames and passwords. Concerning confidentiality and privacy, we have discovered that just very few of the administrative services and none of the e-mail accounts are taking care of this aspect. Integrity-checking or time-stamping services are also not available on a large scale within our IT environment. Furthermore, there is not enforced an automatic traceability of individual user responsibility for events taking place from within our IT environment. Although within our university networking infrastructure we have moderate up to highly protected areas, we still lack security at individual level.

A large part of this delicate and sometimes embarrassing situation derives from the fact that the security issue was not tackled in a holistic manner right from the start (i.e. when the on-line services were introduced). It is probable that this slow, prudent adjustment to the new security reality is the case with most of our large institutions in the public sector.

An important thing would have been a security policy for the entire IT environment of the University of Craiova, but this is still lacking due to the diversity and geographical distribution of the participants (20 faculties and 9 special-purpose departments in two cities and multiple distinct locations). All these participants are subordinated to the University, but they enjoy a significant level of administrative autonomy that has made difficult so far enforcing such a centralized security policy.

Even so, the security issues remain and have to be solved even without a centralized security policy.

Another interesting example for our proposal concerns the Students’ Evidence service which basically provides to students their academic status (number and types of exams passed, scheduled exams, grades obtained for each exam, etc.). Such a service requires a consistent level of privacy and confidentiality. Currently, the students accessing this service are identified by means of their personal numeric

Bul. Inst. Polit. Iaşi, t. LVII (LXI), f. 3, 2011

145

identifier (PNI). This solution was chosen because of the ease in management. The problem with the PNI is that it is a governmentally-assigned number and according to the latest Romanian laws concerning citizens’ privacy rights, it should remain private and be allowed for processing only when two conditions are met: first, it exists an explicit written agreement from the owner and second, when a law has already described and allowed that type of processing of the PNI. None of these conditions are met and therefore the Students’ Evidence service must change as soon as possible the approach for identifying its users. An immediate solution would be at central level to start assigning new electronic identifiers for all students by using the students’ registration numbers (matriculations).

Last but not least important is the issue of institutional e-mail. Here too, after conducting an internal verification we have discovered that on one side, user authentication is based on username and password, and on the other side, the issues of confidentiality and privacy are in most cases neglected. The e-mail servers used do support these security features, but they are neither used nor enforced. In an open educational IT environment in which most of the employees and students are using wireless connectivity, leaving the traffic unprotected may become dangerous. E-mail messages can be intercepted and faked by third parties causing thus moral, economic and professional prejudices to the entitled/authorized peoples. One immediate solution for the administrators was to tunnel – via the SSL protocol – the communication between the client mail user agent and the server. Nevertheless, another sensitive problem may appear. Most e-mail servers today are handling and storing personal accounts by leaving the message data in clear. This is an issue if an attacker captures the root credentials of that server. In such a case, e-mail accounts of employees of a public institution can be vandalized, or only data mined (moreover, malevolent service administrators may abusively use their privileges to read the messages of higher-positioned colleagues in order to gain unauthorized information or even sell certain sensitive information).

It becomes evident that a security infrastructure is necessary. And PKIs protect well applications demanding a high degree of security such as web services-based information processing systems, instant and e-mail messaging, and digital data signing. Moreover, PKIs support other security mechanisms such as firewalls, virtual private networks, and directories.

3. The Implementation

3.1. Basic Concepts

Asymmetric cryptography is a robust and mature technique, dating from the

mid ‘70s. In it, each participant holds a pair of cryptographic keys: one public (known by all other parties) and one private. This particular feature gave impetus and wide acceptance within the user community to this technique. The presence of a pair


146

of keys is the reason why authentication and digital signature can be easily achieved by the participating entities. Other security properties such as confidentiality, integrity, and non-repudiation are also derived. Moreover, the fundamental issue of symmetric cryptography (i.e. secret key distribution) is here avoided. On the downside, it is generally recognized that public-key cryptographic algorithms are more complex, require more computational resources, produce larger outputs and demand longer times than traditional cryptography for basic operations such as encryption and decryption.

Up to a certain point, the distribution of public keys seemed to give space to masquerade attacks against asymmetric cryptography. Digital certificates containing the value of the public key and the identity of its owner, signed by a trusted third party (TTP) were proposed to mitigate this problem.

There are several standards that specify the format of public-key certificates. Among them, ITU-T Recommendation X.509 (ITU-T Recommendation X.509, 2005) is the most popular and is frequently employed in a multitude of other protocols and applications. This standard specifies a model of certification authorities that issue certificates for subordinated CAs and end entities (individual users, servers, network devices, etc.). Usually, a digital certificate issued by a CA will contain the public key, the identity of the entity owning the corresponding private key, the validity period and the serial number of the certificate, the name and the digital signature of the issuing CA, and a specific set of certificate extensions.

The set of people, procedures, software, hardware used to create, manage, store, distribute, revoke and use digital certificates is called a public-key infrastructure (Shirey, 2000).

3.2. Types of Certificates

Our pilot CA will issue only a small subset of possible digital certificates.

First of all, the format of these certificates is conform with the standard X.509 version 3, and similarly, the format for the certificate revocation lists is X.509 version 2. There will be issued client certificates, VPN certificates, SSL certificates, and less frequently, code signing certificates. Client certificates are used by individuals affiliated with the university. They will always contain the category of the subscriber (didactics, administration and support, students), and also her e-mail address. The VPN certificates are useful in establishing secure virtual networks using IPsec and they will mainly contain the IP address of the participating device/system and also the e-mail address of its human administrator. The SSL certificates will be used by the university’s web-servers (also for the web-mail servers) for their own authentication and they will facilitate the enforcement of SSL tunnels between the client browsers and the server. Just as the previous category, these certificates will contain the DNS name of the server and also the e-mail address of the administrator. The code-signing certificates will be issued for certain development projects within the university perimeter.


147

There is however one more type of certificates that we currently do not intend to approach. The so-called qualified certificates are conforming to the EU directive 1999/93/EC (EU Electronic Signature Directive, 1999). These certificates require that the issuing CA to be ascertained and authorized in operation by a state authority (i.e. in our case the Ministry for Communications and Information Society). Qualified certificates require particular fields to be present and also fulfilment of specific technical constraints for the issuer during the certificate creation and signing.

3.3. Selecting the Software Technology

We have opted for an open-source PKI solution due to the budget

limitation. There are several distributions available: − DogTag (Redhat Fedora Project, Dogtag certification system,

available on-line at http://pki.fedoraproject.org/wiki/ PKI_Main_Page), − EJBCA PrimeKey (open-source PKI, available on-line at http://www.

primekey.se), − NewPKI (open-source project, available on-line at http://www.

newpki.org), − OpenCA (open-source project, available on-line at http://www.

openca.org), and − OpenXPKI (open-source project, available on-line at http://www.

openxpki.org). Of these we have focused on the three most popular implementations:

DogTag, EJBCA, and OpenCA. DogTag Certificate Systems (DCS) is a PKI management software

system developed by RedHat, and made publicly available. Unlike other PKI solutions, DCS employs Network Security Services (NSS) instead of the popular OpenSSL crypto-library. A modified version of DCS is employed by the US Department of Defense and handles approximately 10 million certificates. DCS is made up of 6 subcomponents:

− The Certificate Authority (CA) is responsible for the creation, issuance, renewal, revoking and publishing certificates and certificate revocation lists (CRL);

− The Data Recovery Manager is responsible for the management, storage and recovery of the private keys;

− The On-line Certificate Status Protocol Manager is an alternative to the static CRLs and is in charge with status notification for end-entities during the certificate validation process;

− The Registration Authority (RA) is in charge with the registration of certificate subscribers;

− The Token Processing System offers token usage support to the RA interfacing the smart-card managers with the other sub-systems.


148

The second open-source PKI solution comes from a Swedish company called PrimeKey Solutions AB. This is developed in Java and is platform independent. The application is conform with the majority of current PKI standards, and also with Common Criteria requirements (Part. 1, Part. 2, Part. 3, 1999). It has a wide range of features and is very well suited for large communities of subscribers. For the future extension of the project, we consider this solution to be the perfect candidate.

The last PKI solution analysed was OpenCA. This is a collaborative effort aimed to provide a framework for PKI studying and development of associated utilities. It offers support for the essential standards necessary for PKI operations, and in the same time it keeps the simplicity of the entire solution. This is the reason why we have chosen for our first implementation this solution. It fits well for a small to medium PKI community of subscribers as is the case with our implementation. Furthermore, starting with a simpler implementation allows building up the knowledge and experience in operating a PKI for the team in charge.

3.4. Structure of OpenCA

The OpenCA solution is designed so that to be easily adapted to any

hierarchical organization. One such example is given in Fig. 1.

Fig. 1 − An example of OpenCA components and design. The CA component is in charge with creation and revocation of

certificates, and also for issuing CRLs. The RA can handle a variety of certificate signing requests (CSR). These CSR can be edited, approved, and deleted. The RA can also generate the pair of cryptographic keys for smart-cards, on behalf of the subscriber. The LDAP (Semersheim, 2006) interface is implemented to separate the management of the LDAP component from all


149

other software components since not all LDAP functionalities are necessary all the time to PKI administrators. The Public interface in Fig. 1 represents the only interface available to PKI users. Some of the functionalities of this interface include: generation of the cryptographic pair and of the corresponding CSR (by means of various web browsers), handling of CSRs for servers in PKCS#10 format – (Nystrom & Kaliski, 2000), certificate installation, CRL installation, certificate search, and certificate revocation. The Node interface is used for the database management and also for the data exchange between the different levels of the PKI hierarchy. Typical operations performed with this interface include database initialization, information back-up and recovery, and also synchronizing the data between different levels of the hierarchy.

Another interesting component of OpenCA is the batch system (Welter, 2004). This automatizes the different processes taking place within the PKI reducing thus the chances for the end-users to make mistakes. The batch system is based on a finite state machine defining states, functions and flows. At each step, the automaton reads the user’s configuration, verifies his status, computes the next function to be run and returns the execution result. The functionalities automatized by this system are: generation of the CSR, signing of the CSR, generation of a certificate revocation request (CRR) and revoking of certificates. The possible states and transitions of the system are depicted in Fig. 2:

Fig. 2 − States and transitions of the OpenCA batch system. Regarding the actual implementation, the OpenCA PKI solution does

not have a monolithic structure. Instead it uses and relies on several open-source software products:

− The Apache HTTPD server used for accessing the application’s components by admins and end-users. The webserver is configured to use the mod_ssl interface in order to provide strong cryptography for the


150

communication; − The OpenSSL cryptographic library, including its open-source

implementation of the SSL/TLS protocol. All OpenCA cryptographic operations are using OpenSSL function calls;

− Perl programming language is used for writing the code of all OpenCA components;

− OpenLDAP, an open-source implementation of the LDAP protocol, necessary when LDAP is employed for distribution or storing of CRL and certificates;

− MySQL or PostgreSQL are two popular open-source database management systems. OpenCA must be configured to use one of them for storing the PKI data.

Fig. 3 exemplifies the workflow of objects within the application. Essentially, it represents the typical operations of a PKI.

Fig. 3 − Flow of objects in OpenCA.

3.5. Setup and Administration

For the implementation, we have chosen a hierarchical organization,

using a root CA that will issue certificates only for the subordinated top-level CAs. The main reason for this is to allow for extension of the PKI (to other faculties of our university and even to other universities within the national education network), and also for a certain flexibility in the management of the PKI achieved via delegation of responsibility.

The root CA is installed on an off-line workstation. On this same workstation is also installed the first subordinated CA (dedicated to the


151

community of the Faculty of Automation, Computers and Electronics of the University of Craiova). This subordinated CA will handle certificates for the local community of subscribers (students and professors) and also for other entities (e.g. network devices, servers, etc.).

On a second, on-line workstation, we have installed the public interface of the subordinated CA that will take care of all certificate signing requests (CSR) and all certificate revocation requests (CRR), plus the CRLs of the CAs. A scheme of the two installed PKI components is presented in Fig. 4.

To manage the actual PKI implementation based on OpenCA, one may use one of the two available methods: either by means of the web interface or via direct editing of the configuration files. The web interface allows nevertheless access to the most frequent options used during the operation of a PKI. Furthermore, the team has contributed to the OpenCA project by providing a version of the solution in Romanian. The initial configuration of the components was made via file editing. These configuration files are all either in XML or in an OpenSSL-specific format.

An optional component of a PKI is the OCSP responder (Myers et al., 1999) used throughout certificate validation. Instead of downloading – during each certificate verification the entire CRL that may contain revocation information about all CA issued certificates and subsequently looking up within this list for a specific certificate, relying parties can query directly this OCSP responder for revocation status of individual certificates. Moreover, the OCSP responder may be providing fresher information than the static CRLs. In our implementation, we have installed a separate daemon for this protocol, the application being developed by the same OpenCA project. To operate the OCSP responder, it has to be configured with a special server certificate containing an extension that specifies to replying parties the capability of signing OCSP responses.

3.6. Performance

The OpenCA PKI solution is based on OpenSSL (a widely-used

cryptographic library available on-line at http://www.openssl.org) for all that concerns the cryptographic operations. Therefore, it makes sense to consider that the synthetic performance of the application will be similar to that of the crypto-library for these resource-consuming operations.

From an end-user point of view, the delay in execution of crypto-ops is negligible, however for the administrators of the solution this may become of importance especially when working with large volumes of information. In the following test, we have used a notebook computer with 4 GB of RAM memory, and a Intel Core 2 Solo at 1.4 GHz running Debian Linux OS. The test was done for 100 users using the batch system provided by OpenCA. Running one process at a time, for every user in the list led to the values depicted in Table 1.


152

Table 1 Testing OpenCA Performance

Operation Average Time

[min:sec]

Create_pin 0:27

Check_pin 1:44

Check_key_params 0:09

Create_key 2:05

Check_key 1:45

Backup_key 2:05

Check_csr_params 0:09

Create_csr 2:03

Complete_csr 0:12

Check_csr 0:12

As mentioned earlier, the results are close to the performance of

OpenSSL. For example, if the first operation (create_pin) were to be executed in shell using the appropriate OpenSSL commands would lead to a value of 23 seconds. However, the create_key operation which involves in the first place a set of several verifications and a PIN decryption before actually executing the intended operation, is run almost twice as fast in command line.

We have found that the time spent on running the application perceived by the administrator is depending on the used hardware and grows linearly with the number of executed operations.

3.7. Problems Encountered

The problems met during the setup and running of our PKI

implementation are divided in two categories. The first category concerns the location. Up to this moment, there is not

a fully-dedicated perimeter for the CA hardware within our faculty. The machines for the CA front-end and CA back-end are located within an enclosed perimeter in one of the faculty’s laboratories. But the laboratory is frequented by a considerable number of students and faculty’s employees that may represent a risk to the physical security of the machines. The laboratory is not endowed at this moment with an automatic system of alerting and reacting against fire. There are fire extinguishers in the room, but this requires human intervention in situ. The same applies to other natural hazards (i.e. earthquakes, flooding, etc.). The Certificate Policy and the associated Certification Practice Statement state that the CA infrastructure will recover as soon as possible after a natural hazard or a physical attack.


153

Fig. 4 − PKI installed components.

The second class of problems concerns the software. There are three subcategories we have identified through the setup and

deployment of the PKI solution: 1. Problems that were reported on the OpenCA mailing lists and which

were solved by means of fixes and updates to the code. Here, we exemplify the internationalization problem and the patch for the Romanian language added to the application.

2. Problems that are still debated on the discussion forum and for which a solution has not yet been found. Here, an example is the use of the specific Romanian diacritics for the names of the subscribers. This is considered however a minor drawback given that the Romanian language in Internet-related environments is still neither regulated nor used properly.

3. Problems that are not yet raised in the project forum, but for which a solution was identified. These problems and their solutions will be communicated directly to the development team of the OpenCA project. They mainly regard the incomplete translation of the various functions implemented in Perl and also the management of the assurance levels for the server certificates.

4. Future Activities

One of the issues that will be tackled is the LDAP support in our PKI

implementation. LDAP directories are meant to disseminate the public information of the PKI. Relying parties will be able via LDAP to search and download subscribers’ certificates before sending encrypted messages or verifying digital signatures. Additionally, certificate revocation lists can be also published here.


154

Another activity will be to rectify the problem of using Romanian diacritics within digital certificates (mainly for the Distinguished Name field of a public-key certificate).

A third activity will be the extension of the public-key infrastructure first to all personnel of the faculty and then to the other faculties within our university. Once the mass of subscribers will grow, we will be able to better approximate the performance of the solution.

5. Conclusions

A pilot PKI based on OpenCA was implemented as part of the security

infrastructure of the University of Craiova (ROCA – Romanian Certification Authority available on-line at http://ca.ucv.ro). After the deployment we can confirm that public-key infrastructures are both useful and complex technologies, and require a large amount of time for building up the know-how. For an administrator to understand and customize OpenCA for a specific PKI implementation, she must cover multiple fields of expertise (e.g. programming, system administration, cryptography and information security, project management, etc.).

Without a careful analysis and planning, it becomes difficult to find a way to alleviate its complexity and impact on end users and decision makers. Best practices concerning PKI can be derived from precedent and alternative experiences, and therefore they can help throughout the PKI setup and maintenance.

Acknowledgments. This work was supported by the strategic grant

POSDRU/89/1.5/S/61968, Project ID61968 (2009), co-financed by the European Social Fund within the Sectorial Operational Program Human Resources Development 2007 – 2013.

REFERENCES

*** Common Criteria for Information Technology Security Evaluation, Part. 1:

Introduction and general model, version 2.1 (1999).

*** Common Criteria for Information Technology Security Evaluation, Part. 2: Security

functional requirements, version 2.1 (1999).

*** Common Criteria for Information Technology Security Evaluation, Part. 3: Security

assurance requirements, version 2.1 (1999).

*** Directive 1999/93/EC of the European Parliament and of the Council of 13

December 1999 on a Community framework for electronic signatures.

*** ITU-T Recommendation X.509, Information Technology, Open Systems

Interconnection - The Directory: Public-key and attribute certificates frameworks (2005).


155

*** OpenCA guide, available on-line at http://www.openca.org/projects/openca/docs/

openca-guide.pdf (2010). Myers M., Ankney R., Malpani A., Galperin S., Adams C., X.509 Internet Public Key

Infrastructure Online Certificate Status Protocol (OCSP), IETF RFC 2560 (1999).

Nystrom M., Kaliski B., Public Key Certificate Standard 10 (PKCS#10): Certification Request Syntax Specification, IETF RFC 2986 (2000).

Oliver Welter, OpenCA Batch System, OpenCA workshop 2004. Semersheim J., Lightweight Directory Access Protocol (LDAP): The Protocol, IETF

RFC4511 (2006). Shirey R., Internet Security Glossary. Internet Engineering Task Force Request for

Comments (RFC) 2828 (2000).

IMPLEMENTAREA UNEI INFRASTRUCTURI CU CHEIE PUBLICĂ PENTRU MEDIUL ACADEMIC

(Rezumat)

Lucrarea de faŃă prezintă etapele de planificare, modelare, implementare şi

testare ale unei infrastructuri de autentificare a utilizatorilor în cadrul mediului IT al unei instituŃii de învăŃământ superior din România. Infrastructurile cu cheie publică reprezintă instrumente puternice şi complexe care facilitează securitatea informatică. Fără o analiză atentă, o planificare judicioasă şi o implementare strictă a tuturor aspectelor ce privesc desfăşurarea în plan operaŃional a acestor instrumente, complexitatea acestor tehnologii şi impactul lor asupra utilizatorilor finali, precum şi a factorilor de decizie implicaŃi pot fi greu de asimilat, de utilizat şi în final, de acceptat. Lucrarea încearcă să sintetizeze experienŃa căpătată şi bunele practici desprinse de autori pe parcursul punerii în funcŃiune şi a menŃinerii în operaŃie a acestei infrastructuri cu cheie publică.

implementing a public-key infrastructure … · implementing a public-key infrastructure for the...

Documents