pki as a service - kth · today a leading provider of open source enterprise pki, with a product...

PKI as a Service

Deploying Public Key Infrastructure as a Cloud Service

J O A K I M W Å N G G R E N

Master of Science Thesis Stockholm, Sweden 2011

PKI as a Service

Deploying Public Key Infrastructure as a Cloud Service

J O A K I M W Å N G G R E N

Master’s Thesis in Media Technology (30 ECTS credits) at the School of Media Technology Royal Institute of Technology year 2011 Supervisor at CSC was Hannes Ebner Examiner was Johan Stenberg TRITA-CSC-E 2011:024 ISRN-KTH/CSC/E--11/024--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc

PKI AS A SERVICE – Deploying Public Key Infrastructure as a Cloud Service

ABSTRACT The subject of this thesis is Public Key Infrastructure, PKI, as a Service and its focus is to evaluate the possibility to deploy a Public Key Infrastructure as a Cloud service. This is interesting since more and more organizations are moving their services and infrastructure to the cloud to benefit from the possibilities and advantages of cloud services and avoid problems with having own infrastructures. It is also interesting since the cloud could utilize the distributed architecture of PKI and in this way increase the reliability and availability and decrease the response times for validation of certificates.

The problems examined are if it is possible to deploy such service and to what extent the service can be considered secure. The thesis takes on the constructive research method to analyze existing constructs, to form a proposed solution and to envisage and meet issues of the proposed solution. The thesis concludes it is possible to deploy such a service, although, security cannot be fully guaranteed. The trust in the system is dependent on the handling of the private keys and the trust cannot be established without strict and beneficial agreements.

The task of this master thesis was performed at PrimeKey Solutions AB in Stockholm, Sweden during the period September through March. PrimeKey is today a leading provider of open source enterprise PKI, with a product called EJBCA licensed under the LGPL.

PKI SOM MOLNTJÄNST

– Driftsättning av certifikatinfrastruktur i molnet

SAMMANFATTNING Ämnet för denna rapport är certifikatinfrastruktur, PKI, som molntjänst och dess fokus ligger i att utvärdera möjligheten att driftsätta en certifikatinfrastruktur i molnet. Detta är intressant eftersom fler och fler företag flyttar sina tjänster och infrastrukturer till molnet för att tjäna på möjligheterna och fördelarna med molntjänster och samtidigt undvika problem med egna infrastrukturer. Det är även intressant eftersom molnet kan utnyttja den distribuerade strukturen hos PKI och på så sätt öka pålitligheten och tillgängligheten samt minska svarstiderna för validering av certifikat.

Problemen undersökta är om det är möjligt att driftsätta en sådan tjänst och till vilken nivå tjänsten kan anses säker. Rapporten använder en konstruktiv forskningsmetod för att analysera existerande konstruktioner, att formulera en lösning samt att förutse och bemöta problem med den föreslagna lösningen. Slutsatsen är att det är möjligt att driftsätta beskriven tjänst men att säkerheten aldrig helt kan garanteras. Företroendet till tjänsten beror på hanteringen av de privata nycklarna och ett förtroende kan inte etableras utan strikta och fördelaktiga avtal.

Arbetet med denna rapport genomfördes hos PrimeKey Solutions AB i Stockholm under perioden september till mars. PrimeKey är idag en ledande leverantör av PKI programvara inom öppen källkod med en produkt vid namn EJBCA som är licenserad under LGPL.

ACKNOWLEDGEMENTS I would like to thank everyone that has in some way helped me or contributed in my work to write this thesis. First of all, I would like to thank my supervisors, Hannes Ebner at KTH and Tomas Gustavsson at PrimeKey Solutions. Secondly, I would like to thank everyone at PrimeKey Solution for taking me in and offered their help and expertise in various matters and discussion. Lastly, I would like to give special thanks to Johan Eklund at PrimeKey Solutions for many long discussions on security, PKI and everything else, for peer review and tips on progression and much more. Johan’s commitment and passion for security has helped me through many tough moments during the process of working with and writing this thesis. Thank you and thank you all.

TABLE OF CONTENT

1 Introduction ........................................................................................................................................ 1

1.1 Background ................................................................................................................................. 1

1.2 Purpose ........................................................................................................................................ 3

1.3 The Problem ................................................................................................................................ 3

1.4 Aims ............................................................................................................................................ 4

1.5 Restrictions .................................................................................................................................. 4

1.6 Audience ...................................................................................................................................... 4

1.7 Common Acronyms .................................................................................................................... 4

1.8 Structure ...................................................................................................................................... 5

2 Methodology ....................................................................................................................................... 6

2.1 Literature Study ........................................................................................................................... 6

2.2 Analysis ....................................................................................................................................... 6

2.3 Prototype ..................................................................................................................................... 7

2.4 Reliability and Validity ................................................................................................................ 7

3 Theory ................................................................................................................................................ 8

3.1 The Cloud ................................................................................................................................... 8

3.2 Cryptography ............................................................................................................................ 11

3.3 Public Key Infrastructure ........................................................................................................... 14

3.4 PKI as a Service ......................................................................................................................... 21

4 Profiling EJBCA ................................................................................................................................ 26

4.1 Software Environment ............................................................................................................... 26

4.2 Structure .................................................................................................................................... 27

4.3 Available Interfaces and Protocols .............................................................................................. 29

4.4 Relevant Features ....................................................................................................................... 30

5 Analysis ............................................................................................................................................. 32

5.1 The Suitability of EJBCA as Cloud PKI Software ...................................................................... 32

5.2 Issues of the Cloud Based PKI ................................................................................................... 33

5.3 Necessary Changes to EJBCA .................................................................................................... 35

6 Design & Implementation ................................................................................................................. 36

6.1 Use Cases ................................................................................................................................... 36

6.2 Network Architecture ................................................................................................................ 38

6.3 Central Server ............................................................................................................................ 39

6.4 Logical Architecture ................................................................................................................... 40

6.5 Certificate Contents ................................................................................................................... 41

6.6 Graphical User Interface Prototype ............................................................................................ 41

7 Evaluation ......................................................................................................................................... 45

7.1 Core Ideas .................................................................................................................................. 45

7.2 Test Environment ...................................................................................................................... 46

7.3 Result ........................................................................................................................................ 47

8 Discussion ......................................................................................................................................... 51

8.1 EJBCA Profiling ........................................................................................................................ 51

8.2 Analysis ..................................................................................................................................... 51

8.3 Design & Implementation ......................................................................................................... 53

8.4 Proof of Concept ....................................................................................................................... 54

9 Epilogue ............................................................................................................................................ 55

9.1 Conclusions ............................................................................................................................... 55

9.2 Final Discussion ........................................................................................................................ 58

9.3 Future Work .............................................................................................................................. 59

10 References ......................................................................................................................................... 60

11 Appendixes ........................................................................................................................................ 61

11.1 Bash Script to Generate Database Model ................................................................................... 61

11.2 XSL Document to Transform XML to DIA .............................................................................. 62

11.3 Use of JQuery Validation Plug-In and Custom Validation Rules ............................................... 66

11.4 Glossary ..................................................................................................................................... 68

PKI as a Service Introduction

1

1 INTRODUCTION

The question is not whether security is necessary, but how to implement it. (Housley & Polk, 2001)

1.1 BACKGROUND This chapter covers the initial background of the cloud, Public Key Infrastructure and cryptography, and an introduction to the thesis subject, PKI as a Service.

1.1.1 THE CLOUD Cloud computing is the next, but probably not final, step in the evolution of computing. In this chapter the history of the cloud is outlined and some typical cloud services are described to ease the understanding of what cloud services are.

1.1.1.1 History of the Cloud Cloud computing can be described as the next step in the evolution of computing. Modern computing as we know it started with mainframes, which were huge computers used by companies to perform various calculations. Then there was a paradigm shift to the client-server model in which thin clients or terminals were used to access a local server for computing tasks. Later the idea of mainframes was reincarnated in the form of personal computers. Personal computers were small, fast and available to everyone and once again local computing resources were used. Cloud computing is the latest paradigm shift in the evolution of computing. One might argue that cloud computing is just a reincarnation of the client-server model, but there are some key differences. Barnatt (2010) writes that “yesterdays dumb terminals were dependent on a very specific small-scale computing infrastructure. In contrast, most cloud computing appliances will not depend on any specific local server or mainframe, or indeed any dedicated local computing resource at all”.

The analogy of the cloud comes from decades of network diagrams where the Internet was metaphorically illustrated by a cloud. The Internet is represented as something fluffy and white in which no one knows what happens in order to abstract the complexity of the Internet. (Barnatt, 2010)

Later, the cloud as a metaphor has been combined with computing which produces much confusion. How can the Internet be computing? When we talk about the cloud today we really mean cloud computing and here definitions of the cloud differ. One might define it narrowly as computing using virtual servers made available by a third party via the Internet, and others might define it wider as a virtual computing platform where everything outside of your own borders is the cloud. (Rittinghouse & Ransome, 2010)

Definitions of the cloud will be discussed later in chapter 3.1.1.

1.1.1.2 Services in the Cloud There is a wide range of cloud services available today. Most applications used locally on many computers have at least one cloud based counterpart. Google is one of the biggest providers of cloud services today. Google provides numerous cloud services but the most common are Gmail, Google Calendar and Google Docs. These services are all free and have a clear purpose of use. Gmail is an email service, Google


2

Calendar is an online calendar service and Google Docs is a word, spreadsheet and presentation editor. (Barnatt, 2010)

There are of course several of cloud service providers other than Google on the Internet. Among them are Zoho, Amazon and Adobe. Adobe provides a cloud based version of Photoshop called Photoshop Express and Amazon provides whole infrastructures as a cloud service. Every web host can even be described as a provider of cloud services. They usually provide a bundled service with database, web server and email.

1.1.2 CRYPTOGRAPHY Cryptography is a term with Greek origins and translates to secret writing. The meaning of the word is the art of transforming messages to make them secure and immune to attacks. All cryptographic algorithms can be divided into two categories; symmetric and asymmetric cryptography. (Forouzan, 2007)

Symmetric key cryptography is also called secret key cryptography in which only one secret key is used and the key must be know by both communicating parties. Asymmetric cryptography is also known as public key cryptography where each party has a set of two related keys. One is called the public key which is public and can be known by anyone and the other is called private key and it must be kept private, secret and known only by the owner.

Cryptography and cryptographic algorithms will be described further in the chapter 3.2.

1.1.3 PUBLIC KEY INFRASTRUCTURE Communication on the Internet today needs to meet a number of requirements that often can be taken for granted in the real world. These requirements are that the conversation must be secret if it is intended to be and no other should be able to understand it, a message should not be altered between mouth and ear, both parties should be who they claim to be and neither party should later be able to deny the content of the message. These requirements of secure communication on the Internet correspond to the aims of confidentiality, integrity, authentication and non-repudiation. (Forouzan, 2007)

PKI is a framework to satisfy the aims of secure communication in a potentially hostile network such as the Internet. It consists of hardware, software, policies and procedures to manage, create, store, revoke and distribute keys and digital certificates. (Choudhury et al., 2002)

PKI relies, as the name implies, on the use of public key cryptography. Private keys are among other things used to make the cornerstone in secure communication, namely digital signatures, and public keys are among other things used to validate them. Public and private keys are also used in several other scenarios such as encryption, decryption and establishing secure communication channels between parties.

1.1.4 INTRODUCING PKI AS A SERVICE PKI as a Service is intended to be a public key infrastructure in the cloud as a cloud service. Customers will be offered a possibility to sign up for the cloud service and get an own root in the infrastructure. From that root they will be able to build their own infrastructure to distribute digital certificates for various purposes.

The solution will ease the deployment of a PKI for the customers since there will not be any requirements of new hardware purchases or deep understanding of all PKI components and requirements. There are of


3

course numerous other benefits with cloud services and they will be discussed later in this thesis. There are also restrictions and issues with cloud services such as security, reliability and availability. With a cloud based PKI with private keys hosted outside of the domain of the customer, the customer cannot be fully confident the keys are not used to sign illicit certificates.

1.2 PURPOSE The purpose of this study is to evaluate the possibility of a virtual cloud based Public Key Infrastructure as a Service in regards to security and availability. This study focuses on how the service could be implemented to meet all the criteria of PKI while harnessing all the possibilities of a cloud service and adapting to the limitations of the cloud.

1.3 THE PROBLEM In the scope of this thesis, the problem is needed to be defined. This chapter handles the problem definition and the research questions used to help solve the problem.

1.3.1 PROBLEM DEFINITION PKI as a cloud service is a two part problem; one part reliability and availability and one part security and trust. PKI as a system is entirely based on trust; who trusts whom and to what extent? A PKI also needs to be reliable and available when certificates are to be issued and validated. These two areas are the basis for the greatest concern of organizations migrating to cloud services. Can security really be guaranteed and will the service always be available?

The problem is if a PKI – entirely based on trust – could be implemented as a cloud service, in which – in many opinions – security, trust and availability cannot be fully guaranteed.

1.3.2 RESEARCH QUESTIONS What is Public Key Infrastructure? What are the essential components of PKI? What are the criteria of the different components? How can the components be managed?

What is a cloud based PKI? Does it already exist a cloud based PKI? Is there a need for a cloud based PKI? Who is the customer alternatively the user of this service?

How can a cloud based PKI be implemented? How is PrimeKey’s system, EJBCA, currently deployed? What changes could be made to PrimeKey’s current system to adapt it to a cloud service? How can services between the different components be automated?

These research questions above will help find an answer to the most vital question of this thesis: To what extent can a cloud based PKI be secure and trusted?


4

1.4 AIMS The aim of this study is to write a recommendation for a future implementation of a cloud based PKI, to prove some functionality can be implemented and to build simple prototype of the graphical user interface from which the cloud PKI can be managed. The aim is also to determine parts that fall outside of the scope of this study and where further studies are required.

1.5 RESTRICTIONS This study is restricted to not handle server hardware or configuration needed to deploy a PKI. It is also restricted to not deal with load balancing of the servers. The intended prototype is restricted to a simple prototype where most settings will only be available in a few preconfigured options. The graphical user interface of the prototype will be web based and will not be restricted to conform to design standards of human computer interaction.

1.6 AUDIENCE The intended audience of this study is Chief Technology Officers, Security Officers, PKI users, system administrators, students majoring in computer science and people with general interest in IT security.

1.7 COMMON ACRONYMS This is a list of the most common acronyms used in this thesis. All other acronyms used are in the Glossary in Appendix 11.4.

Acronym Meaning Description CA Certificate Authority Authority that issues certificates and

vouches for the certificate contents CRL Certificate Revocation List List of revoked certificates EJBCA Enterprise Java Bean Certificate Authority Enterprise PKI software offered by

PrimeKey Solutions AB GUI Graphical User Interface Graphical interface from which the user

can interact with the software HTTP Hypertext Transfer Protocol Common protocol used for data transfer in

various networks OCSP Online Certificate Status Protocol Protocol to remotely validate a certificate PKI Public Key Infrastructure Infrastructure to support the use of

certificates RFC Request For Comment Detailed documents of Internet standards SSL Secure Socket Layer Protocol to encrypt communication

between two entities


5

1.8 STRUCTURE The following is the structure of the thesis.

Chapter 2. Methodology This chapter handles the methodology used in the process of working with this thesis.

Chapter 3. Theory In this chapter the theory of the cloud and cloud services, the basics of cryptography and PKI are

described. The chapter also contains an overview of the service with reference to similar services and requirements on such services.

Chapter 4. Profiling EJBCA EJBCA is an acronym for Enterprise Java Beans Certificate Authority which is the open source

enterprise PKI solution offered and developed by PrimeKey Solutions AB. In this chapter EJBCA is analyzed in regards to software environment and available features and protocols.

Chapter 5. Analysis This chapter contains an analysis to determine if EJBCA is suitable to use as PKI software in a

cloud based PKI. Furthermore, it addresses issues of the cloud based PKI and determine necessary changes to EJBCA.

Chapter 6. Design & Implementation The Design & Implementation chapter of this thesis is based on the result of the previous analysis

and comprise of use cases, network and logical architecture design, a simple mockup prototype of the GUI and a proposal of recommended certificate content.

Chapter 7. Evaluation In this chapter a Proof of Concept is designed and tested to illustrate the possibility to build the

proposed solution.

Chapter 8. Discussion In this chapter the prerequisites, results and implications of previous chapters are discussed.

Chapter 9. Epilogue The Epilogue chapter contains the conclusions drawn in this thesis, a final discussion and

recommended future work.

Chapter 10. References The list of all sources used in this thesis in accordance with the Harvard System.

Chapter 11. Appendixes Appendixes contain scripts used in this thesis and the glossary of all acronyms used.

PKI as a Service Methodology

6

2 METHODOLOGY The methodology of this thesis is based on a substantial literature study and analysis of already existing structures and components. The method used is the constructive research method where the key idea is the construction. Dodig Crnkovic (2010) writes that the construction is “based on the existing knowledge used in novel ways, with possibly adding a few missing links”.

Dodig Crnkovic (2010) continues: “The construction proceeds trough design thinking that makes projection into the future envisaged solution (theory, artifact) and fills conceptual and other knowledge gaps by purposefully tailored building blocks to support the whole construction”.

The solution in constructive research entails constructing a practical, theoretical or both practical and theoretical object that “solves a domain specific problem in order to create knowledge about how the problem can be solved”. As for the construction, it is not mainly discovered as it is designed and developed. (Dodig Crnkovic, 2010)

The research of this thesis is divided in three main phases: literature study, analysis and prototype.

2.1 LITERATURE STUDY The first phase in the research is the literature study as an empirical investigation of the research problem. Dodig Crnkovic (2010) writes that “only when sufficient understanding of the research problem and the domain is obtained, one can start addressing a Software Engineering problem by Constructive Research method”.

In this study, substantial focus is placed on the literature study. The literature used is both in physical form as loans from libraries and in digital form as e-books. The literature is the basis for the theoretical chapters regarding theory and theoretical outline of the service. It is also used to answer the research questions of what PKI and cloud based PKI is. Furthermore, it is used to fully grasp the gargantuan field of Public Key Infrastructure and Cloud services. The literature study is performed during the first seven weeks of the thesis project.

2.2 ANALYSIS The analysis is performed in two phases. In the first phase the PKI software EJBCA, which is developed by PrimeKey Solutions AB, is analyzed. The method of analysis comprise of deploying the software in a controlled environment and testing the functionality of the application from the administrator graphical user interface and from the other interfaces available. Afterwards, the code of the application, the database and the structure are examined to find possible and required improvements.

In this phase Design Research will be used as Constructive Research, which “involves the analysis of the use and performance of designed artifacts (constructs) in order to understand, explain and improve designed systems”. (Dodig Crnkovic, 2010)

PKI as a Service Methodology

7

The second phase comprise of determining the suitability of EJBCA as PKI software of a cloud based PKI by comparing the available features with the functionality of PKI and of cloud services. This is used as a base for the prototype.

2.3 PROTOTYPE The analysis eventually leads to a prototype. The prototype consists of a theoretical description of the architecture, requirements of the system and a simple prototype of the web interface to show the typical functionality the cloud service should provide.

The method of prototyping the web interface can be compared to Extreme Prototyping in Software prototyping where development is performed in three phases. The prototype will only reach the second phase in which the views are constructed and are fully functional without any underlying infrastructure to support the operations.

The prototype is evaluated by a proof of concept method to verify that the core ideas are feasible. The core ideas to be tested are discussed later in chapter 7.

2.4 RELIABILITY AND VALIDITY Reliability of the study will be increased through the overlap in the chosen literature. At least three books in each subject, Cloud Computing and PKI, are chosen and the consensus of the information will increase reliability. All the books are published by large publishers and have undergone quality reviews which therefore will increase the validity of the study.

PKI as a Service Theory

8

3 THEORY The theory chapter contains a good base regarding the Cloud, Cryptography and Public Key Infrastructure. Furthermore, the theory also contains a theoretical outline of similar services and general requirements found on such services. The theory is a result from the literature study and is the basis for succeeding chapters.

3.1 THE CLOUD This chapter handles the theory regarding the cloud and cloud services and includes the definition of the cloud used in this thesis, benefits, complications and the compartmentalization of the cloud.

3.1.1 DEFINING THE CLOUD There is no univocal definition of what the cloud is. The cloud is and is defined differently depending on the individual relation to the cloud and the qualities the cloud possesses. In the scope of this thesis a definition of the cloud needs to be decided on. To help define the cloud, Barnatt (2010) has specified a number of principles or characteristics of the cloud. Cloud computing is:

Dynamically scalable – if you need more computing resources it will dynamically be available. This can be compared to the power grid where you draw as much electricity as you need at a given moment.

Device-independent – no matter the device, as long as it is connected to the internet and usually has a web browser, the cloud is always available. There are of course other ways to interact with the cloud but a web browser is the most common way.

Task-centric – the usage model is based on what the user want to achieve. No installation required before using the cloud service. In most cases the user is only required to go to the site and register for an account.

Supplied over the Internet – the servers are located outside of your network and it is required to have an Internet connection to access the resources.

Payable on per usage basis – Usually there is no fixed costs with cloud computing, only the variable cost based on how much you use. This could also be compared to the power grid where you pay for as much electricity you consume.

The definition of the cloud that this thesis will follow will adhere to all these characteristics except payable on per usage basis. The economy of the cloud falls outside of the scope of this thesis and will therefore not be needed in the definition. The definition also states that the cloud is located around the third party servers in which the service resides. In this definition the Internet as a whole is not defined as a cloud; each cloud service provider has their own cloud. The cloud has what appears to be a single entry point for all users and underneath lays an advanced infrastructure which could be made up of a large distributed network. The user will in this case not be aware of the location of the server and can in some instances be communicating with a server in USA and in others with a server in Europe. The cloud should also in this definition support multi-tenancy, where there can be a large number of users using the cloud without any knowledge about each other in any way.


9

3.1.2 COMPARTMENTALIZATION OF THE CLOUD Cloud services can be classified in three different main types based on which level of the server the user has control over or in other words, the qualities of the cloud. The lowest level and with the most freedom is Infrastructure as a Service, IaaS. IaaS vendors offer physical servers as a service or a virtualized infrastructure of servers. These servers can run any platform and application. The middle level which is called Platform as a Service, PaaS, and these vendors offer a specific platform as a service which can run any number of applications it is set up to do. (Barnatt, 2010)

The last and most interesting level in the scope of this thesis is called Software as a Service, SaaS. This is a term denoting all the applications that are available in the cloud. All of the services shown in chapter 1.1.1.2 were examples of applications or Software as a Service.

Figure 3:1 Difference in control in Cloud levels (Jansen & Grance, 2011: Figure 1)

Figure 3:1 illustrates the difference in control from the point of view of the provider and the subscriber. The hardware and facility are always in control by the provider.

Figure 3:2 Layers of Cloud levels (Barnatt, 2010)


10

Figure 3:2 shows further how the layers of services are organized and an example of level of control in the layer. In PaaS, a subscriber cannot choose the operating system of the servers, but the subscriber can choose what application to run on the platform.

Software as a Service can be further divided into categories but they are all still applications. Examples of those are Storage as a Service, Communication as a Service, Security as a service or basically Anything as a Service depending on what task is centered in the application. (Rittinghouse & Ransome, 2010)

Software as a Service is the most interesting level in this thesis since the service outlined is basically an application in the cloud. The other levels would be interesting if the application was meant to be placed on outsourced servers like Amazon Elastic Cloud servers.

3.1.3 BENEFITS OF THE CLOUD There are several benefits to cloud services, for both clients and providers. For clients or customers there are low barriers to entry and easy deployment of new software. Instead of buying software and licenses for a whole corporation the customer can set up an account and start using the services at once. If the service is satisfactory more accounts can be set up due to the large scalability of the cloud service. With traditional software the software needs to be purchased and installed locally on the computers on which it will be used. It is a substantially bigger work load to install software on a number of computers instead of just signing up for an account through an online form. (Barnatt, 2010)

With cloud services the client would not need any extra and specific hardware. Moreover, the client is not needed to perform maintenance and support the hardware or software as this is performed by the provider. This leads in turn to a smaller IT-staff or an IT-staff available for other more important responsibilities. Together with no high software purchases and no hardware purchase the monetary risk of starting with cloud services is substantially lower. (Velte, Velte & Elsenpeter, 2010)

Cloud services are also device-independent and will work with any computer. They are therefore easier to use since a familiar work station can be used. Staff using the system is also usually familiar with the World Wide Web and browsers, which make the applications even easier to use. Since the application is available online through any connecting device, the service has a global availability. Moreover, as the application resides online, collaboration is made possible.

The process of upgrading and updating of the software is a benefit for both the provider and user. The hardware and software can be upgraded and updated in small and regular patches without any visible downtime for the user and without any effort from the user. The provider can easily control and update software on their servers which would not be possible in the user’s local application. Providers are very inclined to update the software to have happy customers. Otherwise they will switch provider if it is possible.

There are other benefits for the provider. The provider has full control over the infrastructure which makes optimization of the servers to fit the application provided straightforward. That is relevant both for the choice of hardware and other software in the machines. Since the provider has full control over the servers in which the application resides, the user behavior can be studied to find new desires that can be met. This cannot be done with traditional software if the traditional software not is configured to be malware and spy on the user.


11

There are also benefits to market and distribution of cloud services. Traditional software needs to be packaged, manufactured, marketed and distributed to the world. A cloud service is only available online and can be distributed by using only a link. (Velte, Velte & Elsenpeter, 2010)

Furthermore as providers have high demands regarding security, they should have the possibility to use various logging and monitoring. The cloud provider should use network monitors called sensors to detect and report suspicious traffic to the security personnel. (McDonald, 2010)

3.1.4 COMPLICATIONS OF THE CLOUD There are some concerns that should not be taken lightly when moving to a cloud service. Once the data has been moved to a cloud provider, control over it has been lost. The user cannot tell where the data resides physically and cannot be fully confident the data is handled with care in a secure manner. This is reflected in the foremost concern with cloud services in a survey conducted by the IDC enterprise panel in August 2008. Almost 75 % of the 244 IT-executives and CIOs asked ranked Security as the foremost concern when moving to a cloud services. Performance and Availability came second with 63.1 % each. (Rittinghouse & Ransome, 2010)

Furthermore, when the data has been moved to or created in the cloud, there are concerns about who really owns the data. For instance, if the subscription to the cloud service is cancelled, the customer cannot be fully confidant the data is removed. Also, if the customer wishes to switch cloud provider, there are concerns about if it is even possible as the provider might lock in the customer with various methods. These methods could entail using non standardized methods of storing data which would make it hard to move the data. (Velte, Velte & Elsenpeter, 2010)

Although providers work hard to ensure security, the cloud provider is more likely to be attacked due to value concentration. As the value of the data in the cloud increases, so will the inclination of attacking the provider and stealing the data. It can be compared to robbing banks instead of single citizens. It is harder to achieve and be successful, but if you are successful you will earn substantially more. (Jansen & Grance, 2011)

Users of the cloud service must trust the provider to implement every security measure required. In order to establish trust in security, availability, performance and other vital components of a cloud service the provider must offer a Service Level Agreement, SLA. The SLA is a document agreed upon at the time of registration that binds the provider to keep a certain level of their service until the agreement period is over. (Jansen & Grance, 2011)

Providers are very much aware of the complications and concerns of their services and works constantly to improve the quality and security of their services. Among others things they usually employ IT-security staff 24 hours a day every day to cope with any upcoming problems.

3.2 CRYPTOGRAPHY Cryptography is, as previously stated, originally a Greek word and translates to secret writing. In this chapter the two categories of cryptography technologies and some common algorithms of them will be described. This chapter also describes how the technologies are used together and what hash functions are.


12

3.2.1 SYMMETRIC CRYPTOGRAPHY Symmetric cryptography is also known as secret key cryptography. Algorithms that use only a single key belong to this category. The same secret key is used by both communicating parties; the same key is used both for encrypting and decrypting.

One of the earliest cryptography schemes known is Caesar cipher which is a shift cipher and uses a symmetric key scheme. In Caesar cipher, a key is chosen between 1 and the number of characters in the alphabet. Each character in the message is then changed to the character at key distance. With a key of 3, the character A would become D and so forth. When decrypting an encrypted message, the receiver changes each character to the character 3 steps before in the alphabet.

The symmetric key algorithms used today are far more advanced and encrypts blocks of data in several rounds with different block sizes and key sizes. Some of the common ones are Triple Data Encryption Standard (3DES), Advance Encryption Standard (AES), International Data Encryption Algorithm (IDEA), Blowfish, CAST-128 and RC5. (Forouzan, 2007)

3.2.2 ASYMMETRIC CRYPTOGRAPHY Asymmetric cryptography is also known as public key cryptography. In public key cryptography two different keys are used instead of one as in symmetric key cryptography; one key is used for encrypting and one other key is used for decryption. These keys are generally referred to as private and public keys. The private key is known only to the owner of the key pair while the public key is public and can be known by anyone.

One of the first and most used algorithms for asymmetric cryptography is RSA, named after its inventors Ron Rivest, Adi Shamir and Len Adleman. In RSA, two large unequal prime numbers p and q are chosen and multiplied to make n. Then a random integer e is chosen such that

𝑒 ≡ 1 �𝑚𝑜𝑑 (𝑝 − 1)(𝑞 − 1)� 1 < 𝑒 < (𝑝 − 1)(𝑞 − 1)

and d is calculated such that

𝑒𝑑 ≡ 1 �𝑚𝑜𝑑 (𝑝 − 1)(𝑞 − 1)�

The private key which is kept secret consists of the numbers d and n and the public which is public to anyone consists of the numbers e and n. Encryption and decryption of a message M are made by 𝐸(𝑀) = 𝑀𝑒 𝑚𝑜𝑑 𝑛 = 𝑆 and 𝐷(𝑆) = 𝑆𝑑 𝑚𝑜𝑑 𝑛 = 𝑀 where S is the encrypted message and M the plain text message.

RSA relies on the fact that prime factorization of very large numbers is close to impossible and very time consuming. There are several schemes designed to break RSA encryption but with bigger and bigger prime numbers and padding it is deemed impossible for any algorithm to break the encryption. Other examples of asymmetric cryptography algorithms are the Diffie-Hellman, mostly used for key exchange and generating a symmetric session key, and the Digital Signature Algorithm, DSA, used for signing and verifying a signature. (Forouzan, 2007)


13

3.2.3 SYMMETRIC AND ASYMMETRIC ENCRYPTION Encrypting a message with an asymmetric scheme is much more time consuming than encrypting it with a symmetric scheme, but it is considered much safer. Since symmetric key schemes use the same secret key at both the sender’s and the receiver’s end the key needs to be shared among them. An eavesdropper can intercept the key during transfer and easily understand the secret conversation. Also if the same key is used for a long time the eavesdropper can find out the key by comparing all the encrypted messages.

To solve this problem a session key is used for symmetric cryptography and asymmetric cryptography is used to share the session key. Below, in Figure 3:3, is a simple example of this scheme.

Figure 3:3 Combining symmetric and asymmetric cryptography (Choudhury et al., 2002: Figure 1-9) Figure is modified by author to correct error in key labels

Alice encrypts the message with a randomly chosen key and then encrypts the random key with Bob’s public key. The encrypted message and the encrypted random key are then transferred over the Internet to Bob. When Bob receives the encrypted message he decrypts the random key with his private key and decrypts the message with the random key. (Choudhury et al., 2002)

3.2.4 HASH FUNCTIONS A hash function is a function used to create “a compressed image of a message that can be used as a fingerprint”. (Forouzan, 2007: p. 965) The compressed image is also known as a message digest. The message digest should be a unique representation of the original message without the possibility to restore the message from the digest.

A hash function must meet three criteria to be eligible. These are one-wayness, weak collision resistance and strong collision resistance. One-wayness is needed to ensure the message cannot be recreated from the message digest. Collision resistance is needed to ensure that two messages cannot have the same message digest. The difference between weak and strong collision resistance is that weak collision resistance protects against creating another message with the same digest given the digest and strong collision resistance protects against one user creating two different messages with the same digest. (Forouzan, 2007)

An example of a hash functions is the Message Digest Algorithm 5, MD5. This algorithm is however not considered safe to use any longer as it does not uphold the criteria of a hash function. The MD5 hash function is not as collision resistant as it first was believed to be. Another example of a hash function is the Secure Hash Algorithm 1, SHA-1, which satisfies all three criteria. It produces a 160 bit value which can be seen as a 40 character long string in hexadecimal base.


14

An example of hash values is the SHA-1 hash of the string Example of hash which is 3c35225cedb37edd66fa518f266ec67b7aabc2a716.

3.2.5 CRYPTOGRAPHIC ATTACKS There are numerous types of attacks on cryptographic systems trying to break the encryption or to intercept the communication. Some form of attacks will be mentioned in this chapter.

The most basic form of attack is the Brute Force Attack, in which every key that could possibly exist is used to decrypt the message until a readable message appears. The number of attempts trying to decrypt is proportional to the length of the key; the longer the key is, the more attempts needed to break the encryption. This type of attack is extremely time and resource consuming but with some advanced tricks, which will not be examined, the process can be sped up. (Choudhury et al., 2002)

Another common attack is the Man in the Middle Attack. In this attack an attacker can position itself between the communicating parties when they are establishing the connection and creating the session key. One scenario can be that Alice wants to communicate with Bob and the malicious Eve is in the middle. Alice believes she is communicating and agreeing on keys with Bob when she is really communicating with Eve and Eve is forwarding the messages to Bob. Eve has then the possibility to alter the messages anyway she likes without either Alice or Bob finding out. This type of attack can be prevented by authenticating both parties. (Forouzan, 2007)

There are two types of attacks specific for the RSA algorithm. One is already outlined above and it is prime factorization. The private key that corresponds to a public key can easily be found if the attacker is first able to factorize n back to its two prime factors. The act of prime factoring an extremely large number is however deemed to be almost impossible with the current technology and within a reasonable time frame.

Another attack specific for the RSA algorithm is the Cycle Attack. As RSA is based on cyclic groups in discrete mathematics, it has a weakness in iterating encryption. Without going into further detail, the unencrypted message can be found by re-encrypting the message over and over again with the public key. The number of rounds is proportional to the key length. Though with very large keys, this attack is impractical since the number of iterations is enormous.

3.3 PUBLIC KEY INFRASTRUCTURE PKI is a framework to satisfy the aims of secure communication in a potentially hostile network such as the Internet – confidentiality, integrity, authentication and non-repudiation. It consists, as stated earlier, of hardware, software, policies and procedures to manage, create, store, revoke and distribute keys and digital certificates. This chapter will describe more what PKI is, the components included and how it works.

3.3.1 PKI IN A NUTSHELL PKI relies on the use of public key cryptography. In the early days public keys were distributed on bulletin boards and then there was no way to ensure which key belonged to which user. Housley & Polk (2001) writes that “certificates were invented to solve this problem. They bind an identity and a public key.” PKI


15

came about when there was a need for “an infrastructure to support certificate generation, distribution and revocation”. (Housley & Polk, 2001)

Certificates alone were not a sufficient solution. In order to ensure the right public key is bound to the right identity a trusted third party must vouch for the binding. In PKI this trusted third party is called a Certificate Authority, CA. A certificate is trusted when a trusted third party has signed the certificate with the trusted third party’s private key.

J. R. Binder (in Vacca, 2004) writes that: “The whole concept of a PKI is based on trust. You trust the issuing certificate authority (CA). If you have no faith in the issuing CA, then you cannot trust any of the certificates that they have issued, or the organizations to which they were issued. This is not the fault of the organizations, but of the CA itself.” (Vacca, 2004: ch. 1.3)

A user has to trust the third party in order to trust the certificate. This is not durable since every user needs to trust every third party who issues certificates to users who the first user wishes to communicate with. To solve this problem the Certificate Authorities are ordered in infrastructures where they sign each other as trusted. A user can trust a certificate issued by a third party if the third party is trusted or any of the parent authorities is trusted. If a Certificate Authority has a certificate signed by another Certificate Authority it is a subordinate CA, commonly known as a sub CA, and if the Certificate Authority has a self signed certificate it is called root CA.

Figure 3:4 Hierarchical tree of trust (Choudhury et al., 2002: Figure 3-7)

UserX and UserY in Figure 3:4 can trust each other since they share a parent CA. A certification path can be built from UserX to UserY by validating certificates from CA-3 to CA-1 to CA-4 to CA-7. There are some constraints in building certification paths such as Certificate Policies, CPs, and this will be discussed later. It is worth mentioning that certificate authorities also can be organized in mesh, bridge or hybrid structures apart from hierarchical. (Choudhury et al., 2002)


16

3.3.2 CERTIFICATES AND DIGITAL SIGNATURES As stated earlier, certificates bind an identity to a public key. Choudhury et al. (2002) writes that “Any process of authentication protects two parties against a third party. However, this process does not protect the parties against each other”. Certificates are used to ensure that both parties are who they say they are; to authenticate the identity of the communicators.

In order to bind an identity to a public key a trusted third party has to vouch for that the information in the certificate is correct. When the information is proven to be correct a certificate can be issued. To prove the certificate is trusted and to prevent any changes to the certificate after it has been issued, the certificate authority calculates a hash value of the certificate content and then signs the hash value with its own private key. Digital signatures as the one described is a calculated hash value that is encrypted with the private key. The signature can then be verified by decrypting with the public key and calculating the same hash value. (Forouzan, 2007)

Certificates are based on standards and the most common standard and the only one discussed in this thesis is the X.509 standard for public key certificates. Housley & Polk (2001: p. 75) writes that a typical X.509 certificate contains

Version number – a number indicating version used in certificate. Current version is 3. Serial number – a unique number generated by the Certificate Authority. Signature – algorithm used to sign the certificate. RSA with SHA-1 for example. Issuer – name of the authority that issued the certificate, formatted as a Distinguished Name. Validity – two dates indicating the certificate not valid before and after specified dates. Subject – information about the certificate holder, formatted as a Distinguished Name. Subject public key – the public key of the certificate holder. Signature algorithm – same algorithm identifier as in field Signature. Signature value – the value of the hashed and signed certificate. Optional extension – can contain anything the issuer want.

The Distinguished Name, DN, is a comma separated string of key value pairs. An example of a Distinguished Name is

CN=Joakim Wånggren, givenName=Joakim, O=KTH, OU=CSC, L=Stockholm, C=SE

There are several other keys that can be used in a Distinguished Name not mentioned here.

The optional extension can contain information about what type of functions the certificate is allowed to be used for. For instance, there is one extension to mark that the certificate is authorized to be used for encryption only. It can also contain information about what or who the subject is: a CA certificate, an end entity certificate or a system certificate. Furthermore, it can contain additional names and identity information, key attributes, policy information and additional information of where validation information can be found. (Housley & Polk, 2001)

Certificates have numerous areas of usage. Among other things they are used for establishing a secure communication channel between two parties, identifying users or servers and signing documents or requests to be sent. For instance, every time a client accesses a webpage using the Hypertext Transfer Protocol over Secure Socket Layer/Transport Layer Security, commonly known as HTTP over SSL/TLS


17

or HTTPS, there is a process called handshake between the client and the server in which the server certificate is sent to the client and a client certificate might be sent to the server.

3.3.3 PKI AND THE AIMS OF SECURE INTERNET COMMUNICATION The four aims of secure communication on the Internet are as stated earlier: confidentiality, integrity, authentication and non-repudiation. Authentication is the procedure to verify the identity of a user. There are three different factors authentication can be based on. These factors are something the user knows, something the user possesses and something the user is.

Something the user knows could be a password that is a shared secret between the user and the verifying party. This is the weakest form of authentication since the password can be stolen through, for example, a dictionary attack or sniffing the network. Something the user possesses could be a physical token like a credit card, a passport or something digital and secret like a private key. This authentication form is usually combined with something the user knows to form a two-factor authentication. For instance, a credit card and a PIN are something possessed and something known. Something the user is could be something biometric like a fingerprint, DNA or a retinal scan which is unique for the user. (Vacca, 2004)

Figure 3:5 shows a simple process of how confidentiality, integrity and authentication can be provided using asymmetric and symmetric cryptography along with a hash function. This process does however not provide non-repudiation as the action of sending the message can be denied.

Figure 3:5 Providing confidentiality, integrity and authentication (Choudhury et al., 2002: Figure 1-19)

Confidentiality is provided by encrypting the message and digital signature with a symmetric secret key. This key can either be agreed upon during a handshake or sent along with the message encrypted with the public key of the receiver.

Integrity and authentication are provided by calculating a hash value from the message and then encrypting it with the sender’s private key. Integrity of the message is protected by the ability to notice if the message has been changed and authentication is provided by that only the public key of the sender can decrypt the hash value. This scheme provides only one factor authentication by something the user possesses, the private key.

Non-Repudiation is a bit troublesome. Non-repudiation can be provided either by sending the message to a trusted third party which will add a timestamp and store the message or by the fact that the certificate authority has records of who owns the private key corresponding to the public key at any given moment.


18

Either way there should not be any possibility of denying previously sent message. To support full non-repudiation and it is recommended that the client generates both keys and keeps the private key secret without sending it across any network. Consequently, neither the CA nor any eavesdropper will know the private key, just the public key. (Choudhury et al., 2002)

3.3.4 COMPONENTS OF PKI Public Key Infrastructure is usually illustrated as nodes in a tree-like structure to illustrate the relationship between the different nodes, as can be seen in Figure 3:4. Each node, called issuer or confusingly enough CA, has a number of functions it has to perform and is known by its name and its private key. One single component cannot handle all the functions in a secure manner. Consequently, the functions or the responsibilities of the issuer are delegated to other components designed to perform a few functions well. Housley & Polk (2001) groups each issuer into four basic functional components:

Certificate Authority, CA Registration Authority, RA The repository The archive

The responsibilities of the CA can to some extent be delegated to three other components of the node and these components can be distributed to other servers as long as they can authenticate themselves. The CA is responsible for all the functions which make PKI function. The responsibilities are according to Housley & Polk (2001):

Keep its private key secret Verify certificate information before it is issued Ensure that all certificates and Certificate Revocation Lists, CRLs, conform to its profile Accurately maintain the list of certificates that no longer can be trusted Distribute its certificates and CRLs Maintenance of sufficient archival information to establish the validity of certificates after they

have expired

To keep its private key secret is the most vital responsibility. A stolen private key would make it possible to issue illegal certificates to imposters and this will lead to the collapse of the node and the revocation of all the certificates it has issued. (Housley & Polk, 2001)

Choudhury et al. (2002) append PKI clients and digital certificates to the list of components in a public key infrastructure. PKI clients are the users of the certificates that is produced and signed by a CA. These clients are regular users browsing a secure webpage or identifying themselves online with a digital certificate or One-Time passwords generated with the private key.

There are also two documents that are vital to a PKI. These are called Certificate Policy, CP, and Certification Practice Statement, CPS. Housley & Polk (2001) writes that “the CP is a high-level document that describes a security policy for issuing certificates and maintaining certificate status information”. The CP is a document containing information about all the operations of the CA and the responsibilities of the users for requesting, using and handling certificates and keys. The CPS describes how the CP is implemented in the CA. The Certificate Policy is among other things used for establishing


19

certification paths and cross-certification. The strictness of the CP determines how much trust can be put in to the certificates issued from that CA.

3.3.5 MANAGEMENT, VALIDATION AND REPOSITORIES Housley & Polk (2001) writes that the foremost responsibility of the CA is to keep its private key safe and secure. In order to do this the CA insulates itself while it also has to tend to its other responsibilities of issuing certificates and maintaining list of issued and revoked certificates. Protocols are needed to communicate with the CA to provide it with information about validation and contents of certificate to be issued. These protocols constructed to manage and communicate with the CA and the components of PKI can be divided into categories of management protocols, certificate validation protocols and repository protocols.

Some of these protocols are set by the Internet Engineering Task Force, IETF, in documents called Request for Comments, RFCs. An RFC describes method and behavior of, for instance, a protocol or a standard which may later be adopted as an Internet Standard. For further reading, the RFC with specified number can be downloaded from the IETF web page found in the reference list. (Internet Engineering Task Force, 2010)

3.3.5.1 Management Protocols Management protocols are used to communicate with the CA in order to issue and revoke certificates. Choudhury et al. (2002) states the commonly used management protocols in PKI as:

PKCS#7, the Cryptographic Message Syntax Standard PKCS#10, the Certification Request Standard Certificate Management Protocol, CMP Certificate Management using CMS (Cryptographic Message Syntax), CMC Simple Certificate Enrollment Protocol, SCEP

There will not be any in depth analysis of these protocols apart from that PKCS#7 and PKCS#10 both has some limitations and complement each other well, hence they are often combined. The combination is used by the other protocols. Moreover, CMP provides a complete security solution for PKI transactions, but is deemed extremely complex. CMC provides the same basic functionality as CMP and is a less complex protocol. SCEP is an application-specific protocol, developed by Cisco Systems, which only issues certificates to network device. (Choudhury et al., 2002)

3.3.5.2 Certificate Validation Protocols To validate the certificates, the valid before and valid after dates are compared to the current date and afterwards the certificate is checked so that it has not been revoked by the issuing CA. If the certificate has been revoked there is a reason for the revocation stated and the client can decide whether to trust the certificate or not. To be able to perform this validation there is a need for standards and protocols to make the revocation information available.

At first there is the Certificate Revocation List, CRL, which is more of a standard than a protocol. The CRL is a periodically generated list of all certificates revoked and the reason for revocation. Different versions of CRL have been developed as the specification of the X.509 certificate standard changed. The latest version is version 2 and its content is version, signature, issuer, this and next update date, the list of


20

the revoked certificates and optional extensions. The signature and issuer fields are used since the CRL is signed by an authorized signer of those certificates, for instance the issuing CA. (Housley & Polk, 2001)

One problem with the CRL is the size of the CRL as the number of revoked certificates increases. In order to keep the size down, the CRLs can be distributed partially by using Delta CRLs, detailed in RFC 3280, which only contains all updates since the last update. (Choudhury et al., 2002)

Instead of checking the certificates validity by using the CRL one can also use the Online Certificate Status Protocol, OCSP, detailed in RFC 2560. The basics of OCSP is that a client asks the OCSP responder if specified certificate is valid and the OCSP responder sends back a signed response with the status of the certificate as good, revoked with reason or unknown. The response also includes the date the certificate revocation information was updated and when the next update is expected. (Housley & Polk, 2001)

3.3.5.3 Repository Protocols Housley & Polk (2001) write “a PKI relies on a repository to store and distribute certificates and CRLs”. Furthermore, the repository “is known by its address and its protocol”. (Housley & Polk, 2001: p. 126)

Any protocol that can distribute binary data can be used as a repository protocol. For instance, the Hypertext Transfer Protocol, HTTP, or the File Transfer Protocol, FTP, can be used to distribute certificates and CRLs. However, in PKI the traditional repository is the Directory which is “an online database of arbitrary information”. (Housley & Polk, 2001: p. 127)

The common Directory in PKI is the X.500 Directory which uses the Directory Access Protocol, DAP, and the Directory Service Protocol, DSP. The downside to the X.500 Directory is that the DAP is considered to be too cumbersome which is why the Lightweight Directory Access Protocol, LDAP, was developed and detailed in RFC 4510. (Housley & Polk, 2001)

3.3.6 ATTACKS ON PKI Any system is to some extent vulnerable to common cryptographic attacks. Some systems are more vulnerable than others. PKI can be considered protected against most common attacks. The usage of certificates and Certificate Authorities in PKI make it almost impossible to use a Man in the Middle attack if both parties authenticate themselves with certificates. Brute Force Attack and RSA specific attacks can still be made but the certificates will have expired and the keys will be changed before any keys will be found on the condition that the keys are sufficiently long. (Choudhury et al., 2002)

PKI is vulnerable to other forms of attacks. PKI is, as any other online system, vulnerable to the Denial-of-Service Attack where the service is made unavailable by overflowing the network. The even worse kind is the Distributed Denial-of-Service Attack, DDOS, where computers can be organized in a so called BotNet and are all sent to attack one single server. This makes the service unavailable for everyone and can even break the servers and open security holes. (Velte, Velte & Elsenpeter, 2010)

The prime threat to PKI is a stolen or a compromised private key. If a private key of a CA is stolen that CA will be forced to get revoked along with all the certificates it has issued. If the CA has issued certificates to any sub CAs the sub CA certificate must be revoked along with all the certificates the sub CA has issued. The further up the in the hierarchy a CA is compromised, the more certificates will have to be


21

reissued. Hence, the root CA is very sensitive and will need the most security. A compromised root CA will collapse the entire tree of CAs. (Choudhury et al., 2002)

The private key can be stolen by either an external or an internal attack. An external attack is when a hacker from the outside is trying to break into the system and somehow copy the key or issue illicit certificates to be used to access other secure resources. This is harder to achieve if the key is kept in a secure device instead of in soft mode, in a software based key store. A malicious external attacker could also break the system and make it unusable as a form of denial of service. An internal attack is when someone, an employee for instance, steals the key from the physical servers. A form of internal denial of service attack would be to sabotage the physical servers. (Vacca, 2004)

3.3.7 PHYSICAL SECURITY In order to ensure the private key of the CA is kept secret the CA must be protected. Protection from hackers and from the Internet is not enough. The servers on which the CA is kept must be physically secured from attacks. As the root CA is the most sensitive it must be heavily protected.

First of all, the servers should be in a secure location where no one without the right security clearance can access. This could entail using 24 hour surveillance and access controls with biometrics. The servers should also be secured against natural disasters such as flooding, power outages and to some extent earthquakes. Environmental protection and access control is detailed more in chapter 3.4.3.4.

The private key of the CA needs to be stored in a safe manner while it still has to be available to sign certificates. It can be stored either in soft mode as a file in a key store or in secure device. To store the key in soft mode is not considered safe as it can be copied by a hacker. The most secure way to store the key is to have a separate box where the key is generated and all encryption is performed. This box is commonly known as a Hardware Security Module, HSM. (Vacca, 2004)

There are different kinds of HSM, classified to uphold different standards and have different abilities. Some basic characteristics of a HSM are that it can hold one or more private keys and encrypt data sent to it. The private key never has to leave the HSM to be used and is kept safe inside. One standard set for HSMs is the 140 series of the Federal Information Processing Standards version 2, FIPS 140-2. It has four levels of security where the requirements are increased for each level. For example, a device which conforms to FIPS 140-2 Level 3 is among other things tamper-evident, tamper-resistant and requires authentication to use. (Vacca, 2004)

As an example of a HSM is the Ultimaco SafeGuard CryptoServer Se-Series which can sign up 12800 RSA signatures per second with key length of 1024 bits and up to 2000 Elliptic Curve signatures per second with 160 bit key length. It can also hold about 5000 RSA key pairs with certificates with key length of 2048 bits. The number of keys depends entirely on HSM and the key length.

3.4 PKI AS A SERVICE PKI as a Service is intended to be a public key infrastructure in the cloud as a cloud service. Customers will be offered a possibility to sign up for the cloud service and get an own root in the infrastructure. From that root they will be able to build their own infrastructure to distribute digital certificates for various


22

purposes. This chapter handles similar services found in the literature study, the believed users of the system and the theoretical requirements of a PKI cloud service.

3.4.1 SIMILAR SERVICES There are similar services that can be denoted PKI as cloud services which were unknown until the end of the literature study. These services have not been given a sufficient amount of time to be analyzed and are therefore nearly only mentioned apart from one.

M. Fratto (in Vacca, 2004) writes about three services which have substantial similarities with cloud services without stating that they are cloud services. The three services Fratto discusses are VeriSign OnSite, Entrust Technologies Entrust@YourService and Baltimore Technologies Managed PKI Service. The first has changed name to VeriSign Managed PKI and has no trial version. The second service provided by Baltimore Technologies seems to have disappeared as the company was split up and sold piece by piece. The third and last one has changed name to Entrust Managed Services PKI and offers a 60-day trial period. Other services found are TrustCenter which is a part of Symantec and OpenTrust and their service called Trust as a Service, TaaS.

Entrust Managed Services PKI 60-day free trial version is the only service shallowly examined. Since it was a trial version of the system it seems the full feature list was not supported.

Entrust Managed Services PKI has a web interface to manage the PKI and the end entities in that PKI. Apart from the web interface, manual and automatic enrollment for certificates is supported. Certificate request can be made by PKCS#7 and PKCS#10 and certificate revocation can be controlled with CRL and OCSP. The service is also said to support the ability to build complex PKI by creating new sub CAs and new root CAs and cross certifying back and forth. (Vacca, 2004) (Entrust, 2011)

The trial version does not support adding multiple CAs in any form. One root CA is provided with the ability to issue a small number of certificates. The certificates in turn could not be issue in other formats than Entrust specified formats as Entrust desktop store or Microsoft Windows security framework certificate store. In other words, Entrust controls how and where the certificates are stored and created.

Entrust ensures high availability of their service, a 99.5 percent or greater uptime. This is experienced by the author not be true when testing the trial version of the service. Other downgrading features of the Entrust services are that the web interface seems to be incredibly slow and it uses Java applets to function properly.

One other service provider that might sprout up in the near future is Symantec. Symantec has bought VeriSign and PGP Corporation and is believed by J. Oltsik to have all the components to build a successful global and cloud based PKI with end-to-end trust between any clients. Only the future will tell what Symantec might do with their new acquirements. (Oltsik, 2010)

3.4.2 APPLICATION USERS To be able to make a simple design is it first recommended to outline the intended customer or user of the system. The intended customer of a cloud based PKI is a company that has a need for a public key infrastructure but does not have the competence, time or capital to implement an internal PKI. The customer is furthermore familiar with some cloud services and the benefits incorporated but do not fully


23

understand every aspect of PKI and certificates. The customer could also be a company who has the resources to build an internal PKI but is not willing to take the monetary risk required without first examining the technology. The customer is looking for a system where security, availability, reliability and performance are key components.

The user of the system is believed to be a familiar user of the World Wide Web and browser but a novice in PKI. The user knows what they want to use the certificates for and knows there must be information about who the certificate belongs to inside. The user is also aware of that the certificates can and should be validated to ensure the certificate content is not modified or forged.

3.4.3 THEORETICAL REQUIREMENTS The theoretical requirements of a cloud based PKI are divided into categories of software, hardware, policies, procedures and environment. The categorization is not unlike the categorization of PKI itself and neither are the requirements.

3.4.3.1 Software Software requirements incorporate both software based security and interfaces supported by the application. Furthermore, the software should support high availability and scalability. A baseline requirement is that a customer must only be allowed to see and use their own Certificate Authorities. There must be a complete separation between CAs belonging to different customers. It would be a disaster if one customer would be able to issue certificates from another customer CA. The customer must be authorized to use a specific CA.

The software must support authorization as well as authentication. The software should always know who the client is and if the client is allowed to perform a certain task. In order to be secure there cannot be any points of access for unauthenticated and unauthorized clients. Consequently, there cannot be any security holes to minimize the risk of a hacker accessing the system.

Other than software security, VeriSign, Inc. (in Vacca, 2004) states six business practices important to an enterprise PKI. Three of these are related to software: PKI functionality, ease of integration and availability and scalability. VeriSign, Inc. writes in regards to PKI functionality:

“For strong security, easy administration, and hands-on control of certificate management, an enterprise PKI must be based on a modular design that includes reliable, high-performance support for certificate issuance and life-cycle management, protocols and processing capabilities for diverse certificate types, comprehensive administration functions, records retention, directory integration, and key management.” (Vacca, 2004: ch. 10.3)

Modular design of a system means the system must be divided into standalone modules which can be created and used independently from each other. Modules can be changed, removed and added without disrupting the rest of the system. An enterprise PKI must also support easy integration to other systems and not lock in user to specific proprietary software. In others words, the interfaces and all data generated and responded must follow standards and protocols for PKI.

The PKI must also be available to its user community at all times. Consequently, the software must be extremely stable and cannot break to ensure high availability. Though, if the direful would happen there


24

must be a backup system to be used instead. The software must also support high scalability due to for instance the number of certificates issued and the number of Certificate Authorities in use. There are several different techniques to achieve a scalable solution and the software should support most of them. Among these techniques is virtualization, database clustering and so on.

There will also be need for software other than PKI software to ensure security. Among these are operating systems, databases and firewalls. In any cloud service there is also a need for substantial logging of various events to detect errors and intruders. Furthermore, software for network monitoring should be used to detect suspicious traffic and report it to the security personnel. (McDonald, 2010) (Velte, Velte & Elsenpeter, 2010)

The software should also, which is not discussed in this thesis, support some form of key escrow or key recovery to enable the possibility to find a key that has been lost if this is a customer requirement.

3.4.3.2 Hardware As the private key is the most sensitive information in a PKI it has to be kept secure. The best way to keep it safe is to keep it in a Hardware Security Module, as explained in chapter 3.3.7. The HSM will keep the private key locked inside and will perform all the signing of certificates. It will not allow the private key to be copied or moved and it will not let the key be stolen by force.

Other than keeping the private key safe, there is a need to have backup system in case of failure. Additional servers as hardware backup are mandatory to be able to ensure high availability. There should also be servers for data backup ensuring no data is lost in case of hard drive failure. The backup should also be kept offsite to ensure that they are “available to reconstruct the CA if other physical controls have failed”. (Housley & Polk, 2001: p. 192)

The network in which the servers are located needs to be protected against outside attackers. This can be done both by software based and hardware based firewalls. The servers in one location should be located behind a firewall and should not share this firewall with any devices to minimize the noise in the network. The more noise, the harder it is to detect an intruder. (McDonald, 2010)

The servers must use stable and high performing components that would not break easily and would be able to cope with increased traffic and operations. Vital components in these servers will be the Random Access Memory and the speed and configuration of the processor.

The servers must also have a stable and high performing connection to the Internet. This must be protected by the hardware based firewall. High performing in this case is a Gigabit network to limit the effects of a DDOS-attack and provide fast responses. This connection also needs to have a backup in case of failure, preferably from another Internet Service Provider.

3.4.3.3 Policies and Procedures To establish trust in the system there will be a need for a strict Certificate Policy and a strict Certification Practice Statement. One CP can have multiple CPS which described the practices required by the CP. A baseline recommendation is to provide one CP and multiple CPSs to satisfy the customers various requirements.


25

One item described in the CP and CPS is how the keys will be generated and stored. To prove the key is handled correctly one can perform a key ceremony which is a procedure to generate and set the key in the HSM. The ceremony can be monitored by the customer and an authorized auditor to ensure the key is not copied or in any other way handled incorrectly. To perform a key ceremony with the customer present could pose as a problem for a cloud service since the customer is not aware of where the physical servers are located. Furthermore, the service might use pre-generated keys in a secure HSM which could be a problem for new customers since the key ceremony already has been performed.

To ensure the CP and CPS are strictly followed the services will need to be audited by an authorized auditing firm at a regular basis. The auditing is one of the most important procedures to establish and maintain the trust between the service and the customers. (Vacca, 2004)

It is also important for a cloud service provider to offer a Service Level Agreement, SLA, which the customer must accept to become a customer. The SLA binds the provider to provide a certain level of the service, regarding for instance availability, possible down times, minimum performance data and possible compensation if the SLA is breached. (Rittinghouse & Ransome, 2010)

3.4.3.4 Environment Environmental requirements incorporate the requirements of the location where the servers reside. These are physical security requirements in regard to accessing server rooms, protection against fire and other disasters, and protection against other possible failures.

First of all, the server halls must be protected with authentication and authorization mechanism to prevent non-authorized access. The location should only be accessible using a three-factor authentication using for instance biometrics, a photo id and a key code. There could also be criteria of two person presence to access the machines to prevent attacks where there is only one attacker. To prevent any non-authorized persons from accessing the secure location there should also be constant monitoring and guards present. (Housley & Polk, 2001)

Secondly, the server halls must be protected against fire and other disasters as flooding. It is very important to have functional smoke detectors, fire alarms and sprinklers preferably not dispensing water. To prevent fire from breaking out and to keep the servers from overheating, sufficient cooling must be supplied. The servers should also be located in a location unlikely to suffer from earthquakes and other natural disasters. In the event of a power outage there should be a backup generator to provide electricity to the servers until the power is restored. (Rittinghouse & Ransome, 2010)

PKI as a Service Profiling EJBCA

26

4 PROFILING EJBCA EJBCA is the name of the open source enterprise PKI solution which is offered by and mainly developed by PrimeKey Solutions AB. It is an acronym for Enterprise Java Beans Certificate Authority. EJBCA is licensed under the Lesser General Public License, LGPL, which means that EJBCA is free to modify, use and with some restrictions distribute.

EJBCA is a leading product in open source enterprise PKI solutions and have users all over the world. Among official customers in Sweden are the Swedish National Police Board and Bankgirocentralen BGC.

4.1 SOFTWARE ENVIRONMENT EJBCA, as the acronym indicates, is written in Java Enterprise Edition and utilizes since of version 4.0 Enterprise Java Beans version 3.0, EJB3.0. Allamaraju et al. (2004) state:

“EJB components are designed to encapsulate business logic, and to protect the application developer from having to worry about system level issues. Those issues include transactions, security, scalability, concurrency, communication, resource management, persistence, error handling, operating environment independence, and more”. (Allamaraju et al., 2004: ch. 18.1)

To further explain the concept of EJBs one can relate them to a table and a row in the database. Benefits to this are that no SQL has to manually written since EJB can automatically construct SQL for most common operations in a moderately optimized manner. EJB applications can be deployed in any platform that supports the EJB specification. The platform is an application server which has an EJB container.

Every Java Enterprise application needs an application server to be executed in. An application server is a software framework used in, among other languages, Java to execute applications, handle connections to the database and web clients, and contain business logic. As seen in Figure 4:1 a Java Enterprise application server consists of a Web Container and an EJB Container.

Figure 4:1 Architecture of an Application Server (Allamaraju et al., 2004: ch.1)


27

EJBCA can, depending on distribution, be executed and function well on most common application servers. EJBCA version 4.0 performs well on JBoss Application Server by Red Hat and Glassfish Application Server by Oracle. (PrimeKey Solutions AB, 2011)

All data used by EJBCA is stored in a database. Examples of data used are data for the CAs, all users and all issued and revoked certificates for each CA. All tables in EJBCA can be seen in the database model in Figure 4:2. Currently, there are many database applications available, both proprietary and open source, and EJBCA can function with most common ones such as MySQL, Oracle, DB2, PostgreSQL, MSSQL and many more.

The flexibility of the EJBCA software environment and the applications it uses makes it possible for it to function and perform well on any operating system where a compatible Java Development Kit, JDK, is available. Preferably the operating system should be a server edition optimized for servers. Though, the best configuration can be achieved by running EJBCA in JBoss Application Server with MySQL as database on a machine running Ubuntu as the operating system. (PrimeKey Solutions AB, 2010)

4.2 STRUCTURE The structure of EJBCA can be viewed from different perspectives. EJBCA as a whole is based on a modular design where packages can be modified and whole components can be moved to other servers. This is one benefit of using Java Enterprise and EJBs. The overall structure is also built in accordance with the design pattern Model-View-Controller, MVC, which is a common pattern for separating the presentation layer, the business logic layer and the data storage layer. MVC defines the relationship between the layers as the Controller controls the Model and the View. The View is only allowed to retrieve information from the Model and all other operations must go through the controller.

The EJBs in EJBCA consists of three Java interfaces, an entity bean and a stateless session bean. In general there are only two interfaces, one local and one remote, per EJB. The third interface in the EJBCA case is a parent interface and the local and remote interface inherits from it. The difference between an entity bean and a session bean can be seen as the session bean performs operations on a database table as a whole and the entity is represented as a single row in that database table. Furthermore, the session bean can only be used by a single client at the time, which means there will be multiple session beans when there are multiple clients. The number of entity beans is not in relation to the number of connected clients as the session beans. The design pattern of using a session bean in front of and protecting the entity bean is called Session Bean Façade. (Allamaraju et al., 2004)

The workings of the EJB container simplify the process of creating the database structure. When the EJBs are deployed the container creates every database table and column specified in the EJBs. In the EJBCA database there are currently 26 tables with 206 columns in total, all with corresponding beans to manage the table. However, two columns in each table are used to mark version for compatibility between different versions and row protection as integrity check of that row.


28

Figure 4:2 Database model of EJBCA


29

Figure 4:2 shows a model of the database created and used by EJBCA. The database model was generated by exporting the MySQL table structure to XML and then transforming the XML with XSLT to a diagram model executable in DIA diagram editor. Usable Bash Script and XLS document can be found in appendixes 11.1 and 11.2.

Relations between tables drawn are not explicitly defined in the database. The relations are more ad hoc as the data from one row in a table is used when a new row is created in another table and this is handled by the EJBs. It should also be noted that all relations between tables are not drawn. Primary keys of the tables are marked with a hash sign, #, and foreign keys are marked with plus sign, +. The tables marked in gray are database tables for hard tokens, key recovery and user sources for batch enrollment. These tables represent services of EJBCA which are not handled in this thesis and will therefore not be further examined.

The relations in the database show that the table CAData has precedence to many other tables as its primary key, caId, is a foreign key in several other tables. The relations also shows in which order each table must be populated to add a CA and an administrator of that CA. First of all, the CA must be created as a row in the CAData table and secondly the two profiles in EndEntityProfileData and CertificateProfileData must be created. Next the user must be added to UserData and when the certificate is retrieved a row in CertificateData will be added. To add the user as an administrator four more tables need to be populated. The tables AdminGroupData and AccessRulesData can be populated as soon as the CA is created but the administrator cannot be added to the AdminEntityData until the certificate is issued and the column matchWith is filled with appropriate value from one the certificate DN fields, preferably the serialNumber field in the certificate as it should be unique.

Other than above mentioned tables are tables for log configuration and entries, global configuration, publishers and queues to be published, services and approvals. Most of them are self explanatory apart from services and approvals. The table ServiceData is populated with so called cronjobs which are snippets of code to run in an interval and the table ApprovalData is populated with pending actions waiting to be approved by one or more administrators.

4.3 AVAILABLE INTERFACES AND PROTOCOLS Interfaces and protocols available are a vital factor of any PKI software. Without the correct protocols there will not be any clients able to use the infrastructure. EJBCA supports a number of protocols used in a Public Key Infrastructure. The protocols can be divided in the same categories as in chapter 3.3.5, as management, validation and repositories.

As management protocols, EJBCA supports SCEP and a subset of CMP, detailed in RFC 4210 and RFC 4211, which means that PKCS#7 and PKCS#10 are also used. In addition to these protocols, EJBCA has a Web Service interface which uses SOAP over HTTP for remote administration and integration and an API for an external RA. This means any device or client can request a certificate from EJBCA, either by one of the protocols or by the Web Service.

As far as validation goes, EJBCA support CRL and Delta CRL generation and OCSP in accordance with RFC 2560 and RFC 5019. Any device or client can validate a certificate signed by a CA in EJBCA, either by checking the CRL or sending an OCSP request to an OCSP responder. The validation services in


30

EJBCA can be grouped together to an authority called Validation Authority, VA, which can serve OSCP responses, CA certificates and CRLs.

As repository, EJBCA supports distribution of CA certificates and CRLs over HTTP along with certificate retrieval from the public web page, as detailed in RFC 4387. EJBCA can also have multiple publishers for certificate and CRLs in for instance LDAP. Furthermore, EJBCA supports authentication and publishing of certificates to Microsoft Active Directory. (PrimeKey Solutions AB, 2010)

4.4 RELEVANT FEATURES The features available EJBCA are ever changing and more and more is added every new version. The available protocols and interfaces discussed in the previous chapter are extremely relevant features. However, there are other relevant features available in EJBCA.

The infrastructure is an important feature of any PKI. In EJBCA multiple CAs can be created both as root CAs and sub CAs, which makes it possible to build several complete infrastructures within a single instance of EJBCA. It is also possible to build complex infrastructures by tying the CAs together in mesh and bridge architectures by requesting and issuing cross certificates. Moreover, the CA can be configured to function as a fully audited CA or as a high speed certificate factory just issuing certificates. As for storing the private key of the CAs, EJBCA supports either in soft mode in a key store or in a HSM. The only requirement regarding the HSM is that it has to have “a good PKCS#11 library”. PrimeKey Solutions AB (2010) states EJBCA has support for following HSMs: nCipher, PrimeCardHSM, SafeNet ProtectServer, SafeNet Luna, Utimaco CryptoServer, AEP Keyper, ARX CoSign. (PrimeKey Solutions AB, 2010)

Logging is another important feature of PKI. EJBCA supports a customizable log with internal log messages configurable in different languages and signing of audit logs.

EJBCA supports a distributed infrastructure as CAs can be on other servers and even from other providers by cross certification. In addition, other components such as RA and OCSP can be moved to external sites to provide an even more distributed infrastructure. Even the Validation Authority serving OCSP, CA certificates and CRLSs can be externalized to a standalone service to provide security, high performance and availability.

For certificates there are a number of relevant features, including various algorithms, key lengths, type of certificates and exportable formats. As for algorithms, EJBCA supports RSA with key length up to 8192 bits, DSA with key length 1024 bits and Elliptic Curve DSA, ECDSA, with named curves. Moreover, EJBCA supports multiple hash algorithms such as MD5, SHA-1 and SHA-2. Two types of certificates can be created, namely the X.509 Certificate and the Card Verifiable Certificate, CVC. These certificates can be exported in three different formats: PKCS#12 – the Personal Information Exchange Syntax Standard, JKS – Java Key Store, and PEM – Privacy Enhanced Mail. (PrimeKey Solutions AB, 2010)

There are numerous settings of the CA, profiles and certificates available and vital to any PKI, including key length and algorithms to use, certificate validity period, CRL validity period, allowed key usage and required fields in the certificate. All these settings and many more are controllable and modifiable in EJBCA by creating a CA and creating two different profiles. The profiles are called Certificate Profile and


31

End Entity Profile and are used to for instance restrict the type of certificates and settings available from an issuing CA.

As an extra security measure, approval mechanisms can be configured in the profiles to require certain actions to be approved by one or more other administrators.

To manage EJBCA the clients need administrator certificates as the connection to the server is HTTP over SSL with both client and server certificate exchange. This provides authentication as the identity of the client can be proven and authorization as access rules can be set for that client. In EJBCA administrators are organized in administrator groups with members and access rules and privileges for that specific group. The access rules can be set in a basic mode as roles including CA administrator, RA administrator and supervisor or they can be set in advanced mode where every point of access can be specified.

EJBCA also has a feature to run so called services automatically at any interval in time. There are a number of predefined services to automatically generate a fresh CRL or to renew a CA service at a given periodic interval. In addition to predefined services, custom workers can be written to make EJBCA run any snippet of code periodically or at a given moment. This can be used to for instance send revocation information to an OCSP responder asynchronously.

One important feature available, but not handled in this thesis is regarding key recovery. EJBCA has a “key recovery module to store private keys for recovery for selected users and certificates”. (PrimeKey Solutions AB, 2010)

There are also downsides to EJBCA which were discovered during the analysis phase. One downside is that EJBCA requires a certificate issued from a specified CA to establish a HTTP connection over SSL when an administrator logs in to the administrator GUI. This by itself is a security benefit as full authentication and authorization can be used, but the specified CA certificate needs to be stored in a trust store in the application server and this trust store is only loaded once as the application server starts up. The ramification of this is that all administrator certificates need to be issued from one or more predefined CAs since another CA certificate cannot be imported without restarting the application server and disrupting the service for other users.

Another downside to using EJBCA is the administrators GUI itself. The GUI is too complex and hard to understand. PKI is considered to be complex and the interface for working with PKI will also be complex, but it can be made easier if a Human Computer Interaction expert would design it. One example of annoying behavior and design in EJBCA is the client side validation which communicates with alert boxes and can produce, if not careful, ten to twenty alert boxes describing empty required fields or illegal input. Another example is that the GUI uses HTML frames which are not suitable for all window sizes and consequently makes scrolling and hidden content a problem.

PKI as a Service Analysis

32

5 ANALYSIS The analysis of this thesis analyzes the suitability of using EJBCA as the PKI software in a cloud service. Furthermore, the analysis handles issues found in deploying a cloud based PKI, both in general and in regards to EJBCA.

5.1 THE SUITABILITY OF EJBCA AS CLOUD PKI SOFTWARE EJBCA is the only PKI software examined in this thesis on grounds of three reasons. Firstly, building PKI software from scratch was early discarded as it is a far too complex system to build within a limited time frame. Secondly, no other widely used open source PKI software was found. Open source is required to able to analyze and modify the software and the wide usage is required to assume the software is secure enough. Lastly, EJBCA is the PKI software provided by the employer and is within their expertise.

Even though the lack of other software examined, EJBCA still has to be deemed suitable to use a PKI software in a cloud based PKI. The criteria of determining the suitability of EJBCA is derived from the software theoretical requirements set in chapter 3.4.3.1.

EJBCA is secure in the sense that it requires authentication and authorization to create, view, modify and delete data from both the administrator GUI and through request in available protocols. Furthermore, it is based on a modular design for strong security, easy administration and easy integration. This also provides a better understanding of the code and changes to be made as the components are in modules.

Other criteria set are that the software should be able to issue diverse certificate types and be able to export the certificate in multiple formats. EJBCA supports two types of certificates, one of which is the most common X.509 certificate. It also supports several certificate export formats to provide easy integration with various devices.

As for protocols, three categories of protocols were set in chapter 3.3.5, which are recommended for any PKI. These categories were management, validation and repository. EJBCA follow standards for management through SCEP and a subset of CMP, validation by CRL, delta-CRL and OCSP, repository over HTTP and publishing to LDAP and other directories. Furthermore, it has web services which can be extended to provide full remote administration. At this point the protocols available are deemed sufficient to support a cloud services.

The most vital responsibility of a CA and therefore the PKI software is to keep the private key safe. Hence, the PKI software must be able to function well with HSMs. EJBCA can function well with many different HSMs for safe storage and usage of private keys.

Among the important features of a cloud service are that it is dynamically scalable, always available and task-centric. To provide a task-centric service, options and functions need to be abstracted to some extent. EJBCA can abstract many options and configuration of functionality by constructing automated services to be run in interval or by an event trigger. A task-centric solution would automate as much as possible to abstract the full complexity away from the user. The scalability and availability of the system are discussed later in 5.2.1.


33

A fundamental requirement of PKI software is that it needs to be as secure as it can be. However, it cannot be easily proven that EJBCA is sufficiently secure. This thesis will assume that EJBCA is sufficiently secure on the grounds of its wide use in production by numerous customers. EJBCA is used by various governments and federal institutions among others, and if it was not considered secure it would not be used.

5.2 ISSUES OF THE CLOUD BASED PKI The analysis has so far shown that EJBCA is suitable to adapt to for a cloud service as it supports all protocols and standards appropriate for a cloud based PKI software. It has support for most common management protocols, validation services and repositories. It can issue more than one type of certificate and the certificates can be exported in several different formats. EJBCA is based on a modular design and can be decentralized to provide high performance and availability and security. It can also function well with most common HSMs to store and use the private keys. However, there are still concerns about how separation between customers can be achieved and how private keys can be stored and used to support dynamic scalability and mobility in the cloud.

5.2.1 STORING PRIVATE KEYS IN SCALABLE AND MOBILE SYSTEMS In a distributed PKI, trust can be given to other components by issuing certificates for specific purposes. For instance, the CRL and OCSP responses are signed responses but they do not have to be signed by the CA from which the certificates are issued. The CA can delegate this responsibility by issuing certificates to other components as CRL signer certificates and OCSP signer certificates.

The private keys of the CA, the CRL signer and the OCSP signer can be kept safe and secure in a HSM where encryption and signing can be performed. However, there are problems regarding the scalability and availability of the system if all keys are kept in a single HSM in a single location. To provide scalability and high availability, the system also has to provide mobility. If the service in one location unexpectedly fails, the service must seamlessly move to another location to always be available.

As stated earlier, a HSM can contain a large number of keys depending on the key length and can perform up to a certain number of signatures every second depending on the quality and therefore the price. Also, in a cloud service it would be preferable to be able to set up a CA without waiting for any required action from the provider. Thus, the private key should already exist or be automatically generated in a secure manner on demand.

The three factors to consider when designing the system are scalability, mobility and automation. A solution must be able to add more CAs on demand, be relatively consistent in required time to sign certificates and always be available. Hence, the solution must support the CA operations being movable to another less strained server if the number of requested signatures increases beyond the limit of the HSM or the service unexpectedly fails. To able to move all CA operations to another server, all data regarding that CA must be moved between databases and the private key has to be moved or be the same at the new location. However, there exists no sufficiently secure procedure to move private keys between HSMs autonomously. Therefore, the same private keys must be predefined in HSMs at all available locations of that CA.


34

The ability to move the CA to another location and to bind private keys on demand provides scalability in the number of signatures the system can handle. The scalability of the number CAs at one location is relative to the number of keys the HSM is able to store. If one HSM can store up to 5000 private keys, the only solution that provides scalability is to add another HSM as the keys are starting to run out.

5.2.2 CERTIFICATE AUTHORITY SEPARATION One essential requirement of a cloud based PKI is that one customer should only be able to see and use its own CAs. Consequently, there must be separation between CAs and customers. Regarding the separation of CAs or the separation between customers has three different approaches been considered.

The first approach was to introduce a new table in the database named CustomerData containing a primary ID and other appropriate customer information as contact information. The ID would be used as a foreign key in table CAData and all other tables not containing any relation to that table. This approach was discarded by the requirement to separate the database and move more and more tables to a central server, governing the other servers. It was also discarded on the basis of the complexity of the solution as major changes to EJBCA would have to be done. Preferably should only minor changes be done to EJBCA, but the idea of a central server governing several EJBCA servers remained.

The second approach was to restrict access to other CAs than the customers own by using the built in support for administrator entities and access rules. By using the built in support, groups and roles can be configured to allow full access or only partial access to CA functions or RA functions. As an example, administrator certificates for GUI access issued by a so called Login CA could be used to alter the CA while certificates from the sub CA could be used only to request user certificates. The separation of the CAs would only exist in EJBCA which would only be secure if the administrator groups, entities and access rights are strict and flawlessly implemented. This second approach was eventually chosen as the final approach to solve the problem.

The third approach was virtualization of servers to contain one instance of EJBCA containing a single CA. This is approach would be the most secure as complete separation between CAs is guaranteed as each CA resides in a private virtual machine. This approach was also discarded due to the hardware requirements and lack of scalability as the number of CAs would grow. Each CA in its private EJBCA instance in the virtual machine with application server and operating system would require at least 1 GB of RAM each. The servers would quickly run out of memory. The idea of having virtual machines in a server remained but only to an extent of a small number of virtual machines in one physical machine and several CAs in one instance of EJBCA. This would be preferable as relational databases do not function well with larger number of records. The use of virtual servers would divide the number of records in the database in different machines.

5.2.3 PROVIDING SECURE AUTHENTICATION AND AUTHORIZATION One issue of using EJBCA as a base is, as previously mentioned, that only a number of predefined CAs can issue certificates to administrators due to the trust store in the application server. Other CAs issuing administrator certificates can be added but that requires restarting of the application server. This can, however, be solved by constructing a patch for the application server to make it use a dynamic trust store. The purpose of this is to give each customer a dedicated CA to issue certificates to its administrators. However, it is uncertain if the benefits of having a dedicated administrator CA are greater than the


35

workload of constructing the patch and the possible security threats this could aggravate. Consequently, this change is not recommended to perform.

5.3 NECESSARY CHANGES TO EJBCA Although EJBCA has been found to be suitable to use as PKI software in a cloud service, some changes are needed to adapt it to a cloud service. These changes include modifying the database, extending the web service and redesigning the appearance and functionality of the graphical user interface.

5.3.1 MODIFYING THE DATABASE AND EJBS One minor change is in the database and consequently the EJB and components using it. Figure 4:2 Database model of EJBCA shows that in the table UserData the only primary key is username, which is an arbitrary string set in the request. This is usually a short descriptive name of the user for whom the certificate is issued. As a single primary key it has to be unique in that table in the whole system. Hence, if one username is taken by one customer another customer separated from the first cannot use that username. The services should provide the customer with what appears to be a private PKI and the restriction of already taken usernames ruins that appearance. Also, if one username is unique in one instance of EJBCA, it might not be in another instance which would prevent mobility as the database row cannot be moved without modifying the data. The solution would be to both set the caId and username as a combined primary key or to add a user ID composed of a unique string as a primary key. The latter approach would be recommended to not destroy the current concept of the user as a holder of multiple certificates which each belongs to a CA.

5.3.2 EXTENDED WEB SERVICE The approach on PKI as a cloud service discussed in previous chapter on separating the CAs requires a central server to govern all underlying EJBCA servers. However, EJBCA is not built to support full remote administration from a central server through a web service. It is however built to support full remote administration through Remote Method Invocation, RMI, but it is cumbersome to configure in a secure manner. If required remote administration must be available in a secure manner the web services used to communicate with the servers must to be extended or rewritten to support operations such as CA and profile creation and management. In addition, to avoid the central server being overloaded and to provide short response times between client and GUI, the GUI should be externalized from the central and reside on multiple servers. Hence, there will be a need for a second web service between the GUI server and the central server.

5.3.3 GRAPHICAL USER INTERFACE One major change or complete rebuilding needed is for the Graphical User Interface. Cloud services are defined in this thesis to be task-centric, centered on what the user wants to achieve. The GUI of EJBCA is currently not task-centric. Furthermore, the GUI should be easy to use and understand and the EJBCA GUI fails on this point too. The solution would be to rebuild the GUI to be task-centric around a few use cases of PKI software and be available both in a basic and in an advanced mode to suit all users. Since the GUI will communicate with the central server through a web service, the GUI can be written in any language that supports messaging in SOAP and secure connection handling with SSL sockets.

PKI as a Service Design & Implementation

36

6 DESIGN & IMPLEMENTATION The design of this system is based on the result of the study and comprise of use cases, network and logical architecture design and a simple mockup prototype of the GUI. This chapter describes one of many possible solutions of designing the system. The design of this system does not include recommendation of contents of CPs, CPSs and SLAs, though there are of vital importance to PKI, in particular, a cloud based PKI.

6.1 USE CASES The proposed solution is task-centric as of the principle in the cloud definition. The task of the users is to create and manage a service which can issue certificates to any number of clients. There are two main goals of communication with the application, certificate issuance and certificate validation. To achieve these goals there must first be a service to issue certificates. In addition, there must be administrators to manage the application, which in turn must be managed. It also important to provide information about to whom certificates have been issued and how many certificates that have been issued and revoked. The usage of the application is therefore divided into five use cases: management of services, end entities and administrators as well as viewing of logs and statistics.

6.1.1 MANAGEMENT OF SERVICES, CAS The management of services entails creation, editing and removal of Certificates Authorities. Creating a CA and the steps involved include, as outlined in chapter 4.2, creating a CA with various settings and creating a Certificate Profile and an End Entity Profile with other numerous settings. This procedure is complex and has several potential risks of error. In addition, it cannot be considered task-centric.

The use case of creating a CA is in this design correspondent to creating a service. The service will in turn issue certificates. The creation of the service should for a task-centric cloud service be based on the intended purpose of the certificates it will issue. Also, it should be made simple enough to avoid forcing the intended user of the system to fully understand the underlying workings of PKI.

For instance, if the certificate purpose is to encrypt emails, one simple choice in a dropdown menu should be sufficient to load all recommended settings which are optimized for email encryption. The user would then be able to set a recognizable name of their service and choose for how long the issued certificate would be valid. Moreover, additional Distinguished Name fields could be added and set to modifiable or not and required or not. Validation of input should be performed both dynamically client-side with JavaScript and server-side by the server. There can be additional choices regarding for instance location. The user could be given the possibility to choose the physical location of the server, for instance to minimize response times. The server can then create the CA and the profiles using data supplied by the user and its predefined recommended settings for the chosen service.

After the service is created the server could automatically configure administrator rights and scheduled tasks to publish certificate revocation information and custom workers to notify certificate revocation. When the service is up and running the user would be able to add end entities and administrators.


37

6.1.2 MANAGEMENT OF END ENTITIES, CERTIFICATES Management of End Entities is management of the users and their certificates. The management entails adding and removing an End Entity which correspond to issue and revoke a certificate. Editing an End Entity is not required as the content of the certificate cannot be changed without reissuing the certificate.

Issuing and revoking a certificate should be performable both from the GUI and by sending a formal request in any of the supported protocols. To use these protocols or the GUI the requester must be authenticated and authorized; ergo, the requester must possess an administrator certificate. The workflow of revoking a certificate from the GUI should be made easy and clear but the action should require multiple confirmations since the action is undoable. To find certificates to be revoked the archive of certificates must be searchable by for instance Distinguished Name and serial number. The workflow of issuing a certificate should be as straightforward as just adding the required values in the certificate contents and letting the client retrieve the certificate. The certificate could also be generated when the client retrieves it to let the client generate the public and private keys to provide non-repudiation.

6.1.3 MANAGE ADMINISTRATORS The management of administrators entails adding and removing administrator by requesting administrator certificates from predefined administrator CA and requesting revocation from the same CA. To edit an administrator would be to change the privileges of that administrator and there would not be a need to reissue the certificate.

When adding or editing an administrator there must be roles to set the privileges of that administrator. The user should be able to choose if the new administrator will be able to manage CAs as a CA administrator, to manage End Entities as a RA administrator, both CA and RA administrator or just a supervisor. The rules must also apply to specific service as one RA administrator should not be able to issue certificates from more than one service.

6.1.4 VIEW LOG Logging is an important part of any cloud service or PKI. However, to make logs usable by the users of a cloud service it must be made simple enough and only contain events the user is interested in. The main interest in the logs is believed to be events such as creation, editing and removal of services and issuance and revocation of certificates.

As for information in each service event, it is essential to show who created, altered or removed a service and at what time. Information regarding certificates should answer the questions: who issued or revoked the certificate, for what reason was it revoked, when was it issued or revoked, to whom was it issued or whose certificate was revoked, and from which service was it issued or revoked. The information should be presented in an easily readable manner with the option to limit or sort the logging events. The log should also be exportable in signed formats as the customer might need to store it in other systems. Also, the log should be secure and trusted to not be modified by anyone.

6.1.5 VIEW STATISTICS Statistics is one important feature of any system. As billing in a cloud service is based on per usage it is preferable to provide detailed statistics about how many certificates that have been issued and revoke, how many certificates from each service and how many OCSP responses that have been generated and sent.


38

6.2 NETWORK ARCHITECTURE The network architecture of the system is based on distributed servers. At one end there are servers containing the administrators GUI and the web services to communication with the central server and at the other end are the EJBCA servers containing the EJBCA instances. As Figure 6:1 shows are there multiple instances of administrator GUI servers and EJBCA servers.

Figure 6:1 Network architechture of proposed network design

The multiple Admin GUI servers are distributed instances of the same application and the client connects to its closest Admin GUI to achieve the shortest response times. Figure 6:1 is, however, a simplification of how the network architecture can look.

In this design, the clients connect to the Admin GUI with its certificate issued from the EJBCA Login CA and establish a secure channel with HTTPS. If the client is authenticated and authorized, it can compose a request which will be sent from the Admin GUI to the central server in a web service. The central server validates the request, reformulates the request and sends it to a specific EJBCA server through another web service. The central server contains templates of services and profiles which are further explained in succeeding chapter to reformulate the request.


39

The RAs are Registration Authorities which can be separate boxes in the customer’s possession that communicates with the infrastructure. This scheme is designed so that the customer has a box from which it can request certificates by first asking the central server where their CA is located and the sending a certificate request to the specific CA. The customer acts as a Registration Authority and is responsible for the correctness of the information in the request. The RA boxes also have to have a specific certificate to be authenticated and authorized to make such a request and provide the user certificate.

An example of how to create a CA in this design is that the user adds the service from the Admin GUI by choosing type, validity period and other fields to be used in the certificate the service will issue. The Admin server will package the request and send it to the central server as a SOAP message in a web service. The central server authenticates and validates the request and chooses an EJBCA server. The central will then construct a number of requests regarding creating a CA with recommended settings of that type of service and CRL life span calculated from validity period, creating Certificate Profile with validity period of certificates and End Entity Profile with all Distinguished Name fields. The central server will also request a CA certificate for the service from the root CA of the customer. When this is done the central server adds an administrator group giving the administrator access to the newly created CA and creates scheduled task to publish CRL and custom workers to send revocation information to an OCSP publisher when a certificate is revoked.

6.3 CENTRAL SERVER The central server can be consider to be a bottle neck in the system as all management of services will be processed and forwarded from the central. Also, the central server will get queries from the RA about the location of the CA the RA should use. Hence, the central must be extremely stream lined to be able to perform its task in a secure, fast and reliable manner.

The central server must contain a database to store information. Required information in the database is information regarding the logical address of the physical server, the customer, the CAs and the templates from which recommended settings can be loaded.

Figure 6:2 Simple database model of central database

Figure 6:2 shows a simple database model of the database as a minimum requirement of its content for easy accessibility. Other solutions might be to have all templates on the Admin GUI servers to make them more accessible and limit the reformulation of the request in the central server to a minimum. However, if


40

any changes are done to the templates, all templates on all servers must be updated instead of just on one central server. The templates could however be cached in the Admin GUI server and at a regular basis be fetched from the central server.

The central server of this design also has to choose an EJBCA server to add the CA to. This can be done with three different approaches. The CA can be created in a single random server, a single specific server in a location chosen by the user or in multiple servers with the same DN and same private key of the CA in each server. The latter provides a very redundant and available solution and can be supplied by using predefined keys in the HSM. All three approaches are possible and can be implemented for different customers depending on their requirements.

As previously stated, the central server communicates with the Admin GUI servers and the EJBCA servers through a web service using SOAP over HTTP. The communication between the Admin GUI servers and the central is kept relatively simple, only containing CRUD (Create, Retrieve, Update, Delete) operations of services and reading of log and statistics while the communication between the central and EJBCA servers is a bit more complex as CRUD should be applied to CA, profiles, administrator rights and scheduled tasks.

Searching and retrieving certificate data to view or to revoke are operations that need to be supported and they depend on the creation scheme of the services. If the CA only exists in one server, the searching, viewing and revoking can be done through an HTML iframe. However, if the CA exists in multiple servers the searching needs to be handled by the central server and the result sent to the client. Revocation requests can then be sent directly to the specific EJBCA server in a web service or in CMP.

6.4 LOGICAL ARCHITECTURE The logical architecture of the solution can be illustrated as a three tier hierarchy of the CAs of two different customers, CompX and CompY.

Figure 6:3 Certificate Authority architecture

Figure 6:3 shows the architecture of the two customers CompX and CompY. CompX has two services for SSL-certificates and Email encryption certificates. Each service can be multiplied to exist in multiple instances of EJBCA to provide high availability and low response time. Although the factories appear to be


41

different, they can be configured to appear as one single CA from an outsider’s point of view by sharing the Distinguished Name and private key since the CA is known by its name and its private key.

6.5 CERTIFICATE CONTENTS The certificates issued will have the typical content of a X.509 certificate detailed in chapter 3.3.2 and additional recommended fields added by the application. The customer can add fields to be in the certificate at the time of creation of the service. These fields will be used in the Subject field as Distinguished Name and along other additional extension fields which are not in a certificate by default.

The application will add fields to the certificate regarding allowed key usage, extended key usage and location of CRL distribution and OCSP responders. Also, the application will set the asymmetric key algorithm used and hash function along with the key length to be used. The idea is to get a complex full certificate by automatically setting most fields in the application instead of requiring the user to add them.

6.6 GRAPHICAL USER INTERFACE PROTOTYPE The administrator GUI can be distributed and written in any language as it only communicates with the central server with SOAP over HTTP. The basic constraints are that it can handle SOAP and opening a secure communication channel using HTTPS.

To illustrate this, the prototype was written in PHP, styled with CSS and using JQuery as JavaScript framework and JQuery Validate to perform client side validation. JQuery Validate contains rules for basic validation as required fields and numerals, but does not contain validation rules for input as Distinguished Name fields. However, JQuery Validate supports adding custom methods and rules of validation to achieve this.

Working with the administrators GUI should be easy and understandable. Instead of adding a CA with complex settings, the users add a service based on what the certificates are going to be used for. Recommended settings for that usage mode is loaded and some extra information fields about the subject can be added.

Figure 6:4 shows how a service can be added. First the user selects from a dropdown menu the type of service and then the user names the service.


42

Figure 6:4 Mockup of prototype in HTML – Add Service

Additional DN fields can also be added by choosing them in the dropdown menu and they are added to the HTML dynamically without reloading the web page.

Figure 6:5 Mockup of prototype in HTML – Add Service, add Distinguished Names

The text field for each DN is used to set the default value of the DN. For instance, if a company is going to issue certificates to all its employers it would be suitable to set the company name as Organization and removing the checkbox Modifiable. This would lead to that all certificates from the service would contain the company name in Organization.

The HTML form displayed in Figure 6:4 and Figure 6:5 needs to be validated client side to skip an extra roundtrip to the server every time validation is needed and to minimize the data load in the network by


43

preventing erroneous requests from being sent. The client side validation in the prototype is performed by the JQuery Validation plug-in with the capability to use predefined rules and custom rules for validation.

Figure 6:6 Mockup of prototype in HTML – Add Service, Error

Special rules in this prototype are used to validate Distinguished Names, IP-addresses and other special formatted fields such as gender. For instance, Figure 6:6 shows an error dynamically appearing in the Organization field as the ‘+’-sign is used which is not allowed un-escaped in the Distinguished Name in accordance with RFC 2253. The error is clearly marked with red background and border of the text field and red error description below the field. The custom rules written for the JQuery Validation plug-in to be used in EJBCA are in Appendix 11.3.

Once all errors are fixed, the request is sent to the central server in a SOAP message and the central server configures the service as explained earlier. When the service is correctly configured, End Entities can be added either by the GUI or one of the supported protocols. Figure 6:7 shows how an End Entity can be added from the GUI. An End Entity is added by selecting the service from which the certificate will be issued and then filling in all the fields. The form of adding the End Entity resides in the specific EJBCA server of that service and is loaded to the Admin GUI by an HTML iframe. To be able to have a correctly formatted and fully functional interface in the iframe, the current GUI of EJBCA needs to be rebuilt or an additional GUI suitable for the iframe needs to be developed.


44

Figure 6:7 Mockup of prototype in HTML – Add End Entity

The adding of the End Entity also needs to be validated and the same rules apply to this form as the add service form.

Figure 6:8 Mockup of prototype in HTML – Add End Entity, Error

Errors showing in this form are the Common Name field which was required and left empty, and the password confirmation field which did not match the password field. The username and password are used for creating a user and afterward letting the client retrieve the certificate by supplying the username and password.

The mockup shows how the interface could work with some functionality in a basic mode. An advanced mode could be supplied for advanced user but this is not included in the current prototype.

PKI as a Service Evaluation

45

7 EVALUATION The prototype is evaluated with a proof of concept method in which the core ideas are tested. To begin, the core ideas need to be set. Afterwards, the test environment is specified and the result described.

7.1 CORE IDEAS The use cases of the prototype where set to be management of services, certificates, administrators and viewing of log and statistics. These can also be translated to core ideas to be tested. The most essential idea is the management of services. Services should be addable, editable and removable. From the provider point of view, the services should also be moveable to provide scalability and availability.

A basic proof of concept of the prototype is to test if services can be added and moved remotely from an instance of EJBCA. These operations are currently not supported in the available web service. However, the operations are available by enabling Remote Method Invocation, RMI, and using the remote interface of the EJBs. RMI does not support authentication with certificate to establish SSL connection and can therefore not be used in production, but it can be used in a proof of concept. The methods used in RMI can later easily be implemented in a web service with authentication and authorization if the proof of concept is successful.

The responsibility of the central server is to keep track of in which servers services exist and bind customers to different services. The central server also contains templates of the services. The proof of concept can assume there is only one customer as adding more customers is trivial. It can also be assumed that only one template of services is needed as adding other templates are even further trivial. Furthermore, using a graphical user interface and a web service to communicate with the central will not provide any further proof to the concept of the service and will therefore not be used. Instead the central server will be operated from an integrated Command Line Interface, CLI.

Figure 7:1 Proof of concept architecture


46

Figure 7:1 shows the architecture needed for the proof of concept. The EJBCA instances use HSMs to store and use private keys. The HSMs are clones of each other to contain the same key information. As this is a proof of concept, actual HSM are not used. The HSMs are actually SafeNet ProtectServer HSM Emulators which support the same operations as an actual SafeNet HSM.

7.2 TEST ENVIRONMENT The test environment needs to be set to conduct the test. The environment can be divided in a physical machine and virtual machines. Table 7:1 shows the software used in the physical machine.

Type Software Operating System Ubuntu v. 10.10 with Linux Kernel 2.6.35-27 Application Server JBoss Application Server v. 5.1.0 Database MySQL v. 5.1.49-1ubuntu8.1 Java OpenJDK 6 – JDK & JRE v. 1.9.7 PKI Software EJBCA v. 4.0 alpha 2 Virtual Machine Software Kernel-based Virtual Machine, KVM, v. 0.12.5

Table 7:1 Software in test environment, Physical Machine

The Virtual Machine Software is used on the physical machine to create and manage the virtual servers. The hardware specification of the virtual machines is shown in Table 7:2.

Option Specification Processor 2x Intel Core i7 @ 1.6 GHz 64 Bit Random Access Memory, RAM 2 GB Hard Disk Drive Size 8 GB

Table 7:2 System specifications, Virtual machines

The virtual machines also need software to function. The software used in the virtual machines is shown in Table 7:3.

Type Software Operating System Ubuntu v. 10.10 with Linux Kernel 2.6.35-22 Application Server JBoss Application Server v. 5.1.0 Database MySQL v. 5.1.49-1ubuntu8.1 Hardware Security Module SafeNet ProtectServer HSM Emulator v. 3.33 Java OpenJDK 6 – JDK & JRE v. 1.9.5 PKI Software EJBCA v. 4.0 alpha 2

Table 7:3 Software in test environment, Virtual Machines

The software in the virtual machine has not been updated since the creation of the machines while the physical machine has been continuously updated. This is not considered to have any impact on the result of the test.

Relevant configuration of the virtual machine software is needed. First of all, the HSMs are clones of each other containing 2 active slots with 5 RSA key pairs in each slot. The keys are 2 default keys and 2 sign keys with key length 2048 bits and a slot test key with key length 512 bits. One CA in this scenario uses 1 default key, 1 sign key and the common test key. Hence, there can be 2 CAs using each slot and a total of


47

4 CAs in the proof of concept. Furthermore, the application servers are configured at startup to except RMI connection from any client.

The central server in the scenario is located on the physical machine using all the libraries used by EJBCA Command Line Interface. The physical machine also contains a running instance of EJBCA containing the predefined CA whose CA certificate is trusted by the other EJBCA instances to support administrator login.

7.3 RESULT The central server is basically a Command Line Interface which operates upon the libraries used by EJBCA CLI. However, the CLI of EJBCA does not support multiple RMI hosts. Thus, two helper classes were extracted and modified to support adding of multiple RMI hosts at runtime. The effect of this is that the central application can operate on multiple instances of EJBCA in different physical or virtual machines.

Afterwards, the application was written to support creation, listing, removal and copying of Certificate Authorities in and between the different EJBCA instances by supplying a number of arguments and a reference to the server. The proof of concept is based on the ability to create and move CAs between different EJBCA instances.

To be able to illustrate the proof of concept a snippet of the output log of each operation will be provided. The input provided by the user is marked in italic and underline.

cli | create | list | copy | remove | exit: list Basic view? true Server 1: CA Name CA id CA Type SHA-1 of Public Key Verified? CompXRoot -466654864 ROOTCA ec9f6245c7b5c1a2e03945b302d7b37404fb48d3 CRL Verified LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated Server 2: CA Name CA id CA Type SHA-1 of Public Key Verified? LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated

Log 7:1 Initial listing of Certificate Authorities

Log 7:1 shows the initial listing of the CAs on both servers with name, id, type of CA, a hash of the public key of the CA and an indication if the supplied public key corresponds to the private key in the HSM. The verification of the CA is based on first generating a CRL and signing it with the private key and then verifying the CRL signature with the public key. This will prove that if two CAs have the same hash of the public key and both CRLs are verified, the CAs use the same private key.

Log 7:1 also shows that Server 1 contains two CAs; the root CA of the company called CompXRoot and another CA called LoginCA1. The LoginCA1 is an external CA used as a predefined login CA for administrators as explained previously in this thesis. It is managed from a third server and cannot generate any CRLs or sign any certificates from the detailed servers as they do not have the private key. The CA certificate, which only contains the public key, is imported into the servers to be able to establish the SSL connection between the administrators and the servers. The LoginCA1 is thus not a managed CA of the servers although it is shown as a regular CA in the log.


48

7.3.1 CREATING CERTIFICATE AUTHORITIES There are numerous settings available when creating a CA. These settings entail for instance certificate type as X.509 or CVC, CRL issue interval, algorithms, key specifications and many more. The creation of CAs in this proof of concept assumes that only X.509 certificates can be created with minimal settings modifiable. Static values are used for company name and location, key length and storage, CA certificate validity period and the algorithms used. Furthermore, static values are used for every available setting except the Distinguished Name of the CA, which server it should be created on and which key in what HSM slot it should use. The choosing of keys should of course be handled by the server, but for easy understanding of the concept the choosing is handled by input from the user.

cli | create | list | copy | remove | exit: create Type of Service=SSL Common Name, CN=SSLCA HSM Slot=2 HSM Key=1 Server=1 Initializing CA Generating rootCA keystore: CA name: SSLbyCompX SuperAdmin CN: SuperAdmin DN: CN=SSLCA,OU=SSL,O=CompX,C=SE CA token type: org.ejbca.core.model.ca.catoken.PKCS11CAToken CA token password: hidden Keytype: RSA Keyspec: 2048 Validity (days): 3650 Policy ID: null Signature alg: SHA1WithRSA Certificate profile: SUBCA CA token properties: hidden Signed by: -466654864 Initalizing Temporary Authorization Module with caid=-2087205960 and superadmin CN 'SuperAdmin'. Creating CA... CAId for created CA: -2087205960 -Created and published initial CRL. CA initialized

Log 7:2 Creating a Certificate Authority

Log 7:2 shows the provided user input and the output of creating a CA. The input contains an indication of what type of service, the Common Name of the services, a server reference and references to the location of the keys it must use. The output shows that the CA was created with a number of settings and is a sub CA of the company root CA as it is signed by the root which can be seen by comparing the supplied CA id in “Signed by” and CompXRoot CA id in Log 7:1. The CA token type shows that the private keys are kept in a HSM since the token type is a PKCS#11 token.

cli | create | list | copy | remove | exit: list Basic view? true Server 1: CA Name CA id CA Type SHA-1 of Public Key Verified? SSLbyCompX -2087205960 SUBCA 17d16e5eff0292c7a76b98c5f9d04f3b1ef6a8eb CRL Verified CompXRoot -466654864 ROOTCA ec9f6245c7b5c1a2e03945b302d7b37404fb48d3 CRL Verified LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated Server 2: CA Name CA id CA Type SHA-1 of Public Key Verified? LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated

Log 7:3 List CAs after creation of CA

Log 7:3 shows the listing of CAs after the new CA has been created. It is a sub CA of the root CA and has it keys in the HSM and the public key is verified to correspond to the private key used to sign CRLs. This proves the first part of the concept; the ability to remotely create a CA that is a sub CA and uses a HSM.


49

7.3.2 MOVING CERTIFICATE AUTHORITIES The second part of the proof is to prove the ability to move a CA from one server to the other server. As the private keys cannot be moved, the private key must already exist in the new location. This is the primary requirement if movement of the CAs should be possible. Moving a CA from one location to another entails moving the CA certificate and all settings of that CA, and also binding the same private key at the new location to the CA. Using the CAs detailed in Log 7:3, the newly created CA SSLbyCompX can at first be copied to the new location.

cli | create | list | copy | remove | exit: copy CA Name=SSLbyCompX From Server=1 Move SSLbyCompX to other server CA info retrieved Certificate chain retrieved Copying CA to new location Copying additional CA settings Done

Log 7:4 Copy CA from one server to other

Log 7:4 shows the user input and the output of copying a CA between servers. As there only are two servers, it is not necessary to specify to which server to copy the CA.

cli | create | list | copy | remove | exit: list Basic view? true Server 1: CA Name CA id CA Type SHA-1 of Public Key Verified? SSLbyCompX -2087205960 SUBCA 17d16e5eff0292c7a76b98c5f9d04f3b1ef6a8eb CRL Verified CompXRoot -466654864 ROOTCA ec9f6245c7b5c1a2e03945b302d7b37404fb48d3 CRL Verified LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated Server 2: CA Name CA id CA Type SHA-1 of Public Key Verified? SSLbyCompX -2087205960 SUBCA 17d16e5eff0292c7a76b98c5f9d04f3b1ef6a8eb CRL Verified LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated

Log 7:5 List CAs after copy of CA

Log 7:5 shows the listing of the CAs after the CA SSLbyCompX has been copied to Server 2. It shows that both servers contain the fully functional CA. It can be proven that the same public key is used as the two hashes are the same and it can be proven the private keys are the same as the generated CRLs are verified by the corresponding public key. This proves the second part of concept; the ability to remotely move a CA to a new location while still using the same keys in HSMs and without having to reissue the CA certificate.

To complete the move of the CA, the central must be updated to direct traffic to the new location and the CA in Server 1 can be removed remotely.

cli | create | list | copy | remove | exit: remove CA Name=SSLbyCompX From Server=1 Retrieving CA id Removing CA Done

Log 7:6 Remove CA from server

Log 7:6 shows how a CA can be removed by specifying the CA name and the server to remove the CA from. Though, removal of the old CA is not always desired as two or more CAs with the same Distinguished Name and keys will appear as the same and can be used in load balancing and can provide low response times all over the world.


50

cli | create | list | copy | remove | exit: list Basic view? true Server 1: CA Name CA id CA Type SHA-1 of Public Key Verified? CompXRoot -466654864 ROOTCA ec9f6245c7b5c1a2e03945b302d7b37404fb48d3 CRL Verified LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated Server 2: CA Name CA id CA Type SHA-1 of Public Key Verified? SSLbyCompX -2087205960 SUBCA 17d16e5eff0292c7a76b98c5f9d04f3b1ef6a8eb CRL Verified LoginCA1 1014268170 ROOTCA ca17687982b9be5d908314c203ac89be8af55650 CRL Not Generated

Log 7:7 List CAs after removal of CA

Finally, Log 7:7 shows the listing of CAs after removal of the CA from Server 1. The CA in Server 2 will still be fully functional and a sub CA to the root in Server 1.

PKI as a Service Discussion

51

8 DISCUSSION The solution presented in this thesis is only one possible solution to the problem outline in this thesis. However, the requirements set are the same. Security and reliability are key components of a PKI in the cloud. This chapter discusses the prerequisites, results and implications of previous chapters.

8.1 EJBCA PROFILING Profiling EJBCA handles the software environment and structure of EJBCA along with protocols and relevant features for cloud service adaptation. Although the features were deemed sufficient for a cloud service, all features and protocols have not been tested in the process of this thesis. Furthermore, all functionality of EJBCA has not been tested.

Features, protocols and functionality that have not been tested have been stated as available based on feature statements of PrimeKey Solutions AB. All features and functionality cannot be tested as it would be too time-consuming for this thesis. In order to consider EJBCA sufficient, PrimeKey must be trusted to be used as source of reliable information. The information provided by PrimeKey can to some extent be trusted as the features, protocols and functionality stated as available is used in production by various customers.

However, features assumed available are not always available in the form in which they were assumed. For instance, EJBCA has the possibility to sign external CAs by issuing CA certificates to CAs on other servers. This process was assumed to be to some extent automatic when it in fact was not. The process of external signatures was based in generating a request, hand-deliver the request to the signer to be signed and then importing the signed response into the requesting machine. Although the design in this thesis relies on automatic external signatures, the design would still work as CA certificates can be generated, internally signed and imported to other machines as proven in chapter 7.3.2.

As for the structure of EJBCA, the testing was performed in EJBCA v. 4.0.0 alpha 2 which has been in development during the work in this thesis. The database model presented in chapter 4.2 might not currently be accurate since it is based on an earlier development version and the structure of the database might have undergone minor changes as development has progressed.

8.2 ANALYSIS The analysis chapter of the thesis handles three subjects; the suitability of EJBCA as PKI cloud software, issues needed to be discussed before the design phase and changes to current implementation needed for cloud adaptation. Although the issues have been discussed and to some extent resolved in chapter 5, the result of the analysis needs to be discussed.

EJBCA was deemed suitable to use as PKI cloud software on the grounds of supporting all protocols, features and functionality set to be required of a PKI deployment in this thesis. Furthermore, other software was discarded as candidates based on the complexity of such system, the open-source requirement, wide usage requirements and the availability of software and expertise. Although other software was discarded from the analysis, generalization of the result can still be done as the requirements


52

of such system are general. Any PKI deployment must support secure storage and usage of keys, separation of different CAs, support features and protocols deemed required and provide fully authenticated and authorized access to the infrastructure.

As for secure key storage and usage, the private keys must be generated and exist in a HSM. The limitations of the HSM lead to the requirement of CA operations being mobile in the system to be scalable in the cloud environment. To support mobile CA operations, the private key must exist in HSMs in multiple locations. The only other solution to this problem found is storing the keys in soft mode and exporting the CA with CA certificate and private keys across the network when it must be moved. However, storing keys in soft mode would compromise the trust in the system severely as soft keys could potentially be accessible by hackers and are not secure enough to send over a potentially dangerous network such as the Internet. Hence, the keys must be in HSMs. Though storing private keys in HSMs in multiple locations might be a potential risk too. By multiplying the key locations, the risk of key compromise is also multiplied. However, the risk of key compromise when storing keys in HSM is infinitely small, thus multiplication with a factor of 10 is still infinitely small.

The analysis handles CA separation by comparing three approaches to the problem. The resulting approach is to strictly separate all CAs with administrator access rights tables in the database. Consequently, all CAs in one server and archive of issued certificates from that server would exist in the same database. It is however unclear if the separation would be sufficient for the customers and if the database could handle the number of rows this would entail. As the number of rows in the database increases, the database operations decrease in speed. Ultimately the database would be rendered unusable. Since one CA can issue an almost unlimited number of certificates, the archive of issued certificate should be moved to a specific central archive optimized for large amount of data. Though, as a first draft of the service, a shared database in regards to certificates is sufficient. As for sufficient separation between customers in a shared database and through access rights, multi-tenancy in a shared environment is one extensively discussed topic of cloud services. Even if the less scalable approach of virtual server of every customer in all available locations would be used, the multi-tenancy issue would not be solved as there might be concerns on information spilling over from one virtual server to another in the shared physical environment. This issue cannot be easily solved and the only recommended solution is to guarantee privacy in the Service Level Agreement and to promise substantial compensation if it is breached.

To provide secure authentication and authorization, all web access and web service requests are in HTTPS with client authentication with administrator certificates previously issued and approved. To not be forced to restart the application server for every new customer, predefined login CAs must be imported into every instance of EJBCA to enable establishment of the SSL connection. This is proven to function properly in the proof of concept in chapter 7. The administrator certificate is validated at login by verifying the valid period and verifying the signature in the certificate. However, since the administrator certificate are issued from an external CA, the certificates are not in the database and cannot be internally validated to not be revoked. If an administrator certificate is revoked, the validation information must propagate through the whole system. This an issue overlooked in the analysis and the design. A solution is however not more complex than to send an OCSP request to an authorized OCSP responder to validate the administrator certificate against revocation.


53

8.3 DESIGN & IMPLEMENTATION The design of the system was to some extent based on use cases of PKI. The use cases were in regards to management of services, certificates and administrators and viewing of log and statistics. Furthermore, the use cases were simplified and fairly general to PKI. They were however not scientifically based or empirically derived as they were the believed use cases of such a system. Other use cases might appear if a full empirical study of the usage of PKI would be conducted. On the other hand, the Administrator GUI prototype was the only component entirely based on the use cases, which is only a minor portion of the study. Other components partially based on the use cases could easily be altered to support additional or modified use cases if such were found in an empirical study.

The design incorporates a couple of known issues that can become problems further along the way. First of all, the central server has not any knowledge of the HSM slots and keys. The solution relies on one CA being bound to one key in the HSM. The central therefore needs sufficient knowledge of what keys are taken, available or used before and needs to be regenerated. The structure of the central presented in chapter 6.3 does not provide the central with any information on keys. This is however considered to be a minor modification of the proposed structure.

Furthermore regarding the central, it can become a bottle neck in the system strangling the traffic by an overload of requests. All requests from the Administrator GUI servers regarding management of services, retrieving of log and statistics must go through the central server. Certificate issuance and revocation are not restricted to go through the central server as it can be done directly on the EJBCA servers through protocols such as CMP or a web service or by loading a HTML form through an iframe. In addition, all RA boxes will ask the central for IP-address or DNS-address of the EJBCA server it should send its requests to. The amount of traffic and the workload of the central service will increase as more and more customers sign up for an account and more and more clients connect.

One solution to minimize the bottle neck phenomena could be to distribute the responsibilities of the central server to several smaller servers. For instance, adding extra dedicated servers for handling service requests, logging and statistics requests and address lookup requests would improve the service.

The central server handles, what can be defined as, central management of all other servers. This makes the central more attractive for hackers to attack due to the value concentration in one single location. The central management has access to other servers since it must be able to choose a server and create a CA on that server. Hence, the central must possess a certificate which is authorized to perform sensitive operations on all servers. Furthermore, the central is attractive to deploy a Denial-of-Service attack on as a successful attack would deny service of the whole infrastructure. Sadly, there is no effective protection against DOS-attacks, other than protecting the underlying infrastructure from destruction by overflow of information. As for value concentration and protection against hackers, the central must be extremely secure but how this can be assured is left to security experts.

Another issue which also needs further investigation is how the RA boxes are performing the lookup. The initial idea was to redirect them to the correct resource using HTTP status codes in the 300-series as 302, 303 or 307. The assumption that this would work is based on that all the management protocols provided use HTTP as the channel of communication. However, these protocols all use POST as method of sending information to the servers and POST, in contrary to GET, cannot be automatically redirected


54

unless confirmed by the client. The client must therefore be configured to automatically look up the address of its CA at a regular basis, alternatively use protocols such as the Service Location Protocol, which is detailed in RFC 2165 and not covered in this thesis. To summarize, the RA boxes cannot be standard components from any manufacturer as they need special configuration to function with the cloud.

One other issue found is in regards to creating multiple roots. This is not an architecture issue as it is a prototype issue. The prototype only supports creating CAs as services certified by the customer root. As it is not an architectural issue it can be made available by providing an advanced mode in the GUI.

8.4 PROOF OF CONCEPT The Proof of Concept used in thesis is based on testing the core ideas of remotely creating and moving a CA from one server to another. Although the functionality of both concepts was proven, they were based on substantial simplifications of the service which might have implications on the result.

The first simplification of the test was the construction of the test itself. The test was constructed to prove the functionality of the two concepts and to disregard other concepts. This could imply the test was not objective as choices were actively made to achieve the desired result. However, one might also argue the test construction to be a “purposefully tailored building block to support the whole construction” as stated in the methodology of this thesis. The latter is the preferred argument.

However, other simplifications were made as the test uses RMI instead of web service stated in the design, a HSM emulator instead of a real HSM and the central is decreased to a basic CLI without any database and only one predefined customer with predefined settings. Furthermore, the concept only entails creating and moving the CAs and not any profiles, administrator access rights and certificate archive.

To use RMI instead of a web service for communication has severe implications on security. The communicating parties are not authenticated nor authorized and the communication is not encrypted. In addition, the whole system is made available to a remote application. However as stated in chapter 7, the method used in RMI can easily be implemented in a web services with authentication and authorization. As for a first Proof of Concept, the usage of RMI is adequate.

The test uses a HSM emulator instead of a real HSM to generate, store and use keys. The emulator was developed by a company manufacturing and selling HSMs. The emulator was used since a real HSM is far too expensive to purchase for the sole purpose of experimenting in the scope of this thesis. The HSM emulator is said to function as a real HSM if configured correctly. Though, no implications on the result of using a HSM emulator instead a real HSM can be discussed as no real HSM has been experimented with.

The result of the evaluation was that the two concepts were proven to function properly in the test environment. This was the expected and desired result of the test. Next step would be to remove various simplifications by completing the central with database, implement a web service instead of RMI and test the creation and moving of profiles, administrator access rights and certificate archive. However, moving the certificate archive would be less important to set up as the scalable solution would be to use a central archive or validation authority to which certificates are published.

PKI as a Service Epilogue

55

9 EPILOGUE This chapter contains the conclusions drawn in this thesis and the final discussion in which the method and restrictions are discussed. Furthermore, the chapter contains future work as recommendation of areas which are interesting to examine further before a cloud PKI deployment.

9.1 CONCLUSIONS The conclusions of this thesis entail the security and trust of the outlined system, a summary of the recommended modifications and modifications to previously set system design.

9.1.1 THE SECURITY OF A CLOUD PKI The security of any system is not a question of if the system is secure or not, it is a question of how secure it is or in other words, to what extent it is secure. Every system has flaws, either in the design or in the nature of the system, thus absolute security cannot be guaranteed for any system. Technologies and incentives to access or destroy systems emerge as technology moves forward and the value of the system increases. Hence, a system can only be classified secure to an extent or not secure at all. One critical factor in security is cost. To limit the incentives to break the system, the cost of breaking the system should be higher or equal to the value of the information the system is protecting.

The thesis has shown how a PKI as a Service can be deployed and the requirements of such services. It has also been proven that EJBCA is suitable to use as the base PKI software in a cloud deployment and that EJBCA supports two essential concepts of PKI as a cloud service, creating and moving Certificate Authorities. Though, the extent to which PKI as a Service can be secure relies on three factors:

The handling of any denial of service attacks The handling of data theft The handling of unauthorized usage

The handling of any denial of service attacks entails any attack that can make the service unavailable to the customer. This includes physical sabotage, natural disasters, power outages and overflowing the network with information to gain access or destroy the system. Other than environmental protection detailed in chapter 3.4.3.4, these kinds of attacks cannot be fully protected against. The only protection is to have policies and procedures to shield the system from restricted access and to prevent it from breaking.

The handling of data theft is in regards to the private key. The private keys are the most sensitive information in the whole system. Most other information is available in the certificate. If the private key of a CA is stolen, all user and CA certificates issued from that CA must be revoked, thus collapsing that branch of the hierarchical tree of CAs. To keep the private key safe and secure and consequently establishing a trust in the system, the private keys must be generated, stored and used in a HSM. Even if the private keys are kept in a HSM, the trust of the private keys relies on two criteria:

One key must be strictly bound to one CA which can only be used by an authorized client. The HSM must not in any way expose the keys, in reasonable time, if it is stolen.


56

The first criteria is in the control of the provider while second is the provider’s responsibility and in the control of the HSM manufacturer. Hence, the service provider must trust the HSM manufacturer to be able to ensure the customers the private keys are secure. Thus, it is vital to use a HSM with the appropriate security standard such as FIPS 140-2. Furthermore, to establish trust in the system and to ensure correct handling of the private keys, regular audits must be performed by an authorized auditor.

The handling of unauthorized usage is performed by the provider. In the service outlined in this thesis, no restricted action can be performed without an administrator certificate. It is in the responsibilities of the provider to ensure no unauthorized certificate can perform any restricted action. However, if an authorized certificate is used by an attacker from the users own computer or by a rouge administrator, it falls outside of the responsibility of the provider. However, the log will show who did what and when, thus the intrusion can be detected and the certificate can be revoked. Furthermore, operations can be set to require an approval by an additional administrator to prevent such attacks.

To summarize, the provider cannot guarantee absolute security other than to a certain extent. As the provider owns the infrastructure and therefore the private keys, the customer must trust the provider to follow set policies and procedures to keep the infrastructure as secure as possible. To establish the trust in the system which must come from the customers, agreements must be used to guarantee a certain level of service and security. Furthermore, to establish the trust regular audits must be performed which the customers can trust to be correct. The agreement also has to be beneficial for the customers. For instance, in the scenario of key compromise at the providers end the customer would receive a substantial compensation. Trust needs to come from the customers and to achieve a state where the provider can be trusted the incentives must be greater than the risks.

9.1.2 SUMMARY OF RECOMMENDED ACTIONS AND MODIFICATIONS One conclusion in this thesis is that EJBCA can be used as cloud PKI software. It has sufficient support for all required functions and can be considered secure enough. However, this thesis has also determined a number of necessary modifications and actions to adapt it to a cloud service.

The first modification is to extend the current web service to contain management of Certificate Authorities, Certificate Profiles, End Entity Profiles, administrator access rights. The server network structure depends on a secure communication channel through which the servers can communicate with the central server.

Moreover, administrator certificates need to be fully validated at login or at receiving a signed request. Full validation should preferably be done in the SSL handshake. By full validation, the dates and the signature are validated and the certificate is validated against revocation by an OCSP request and response. As the proposed solution use external CA certificate to establish the SSL connection, additional revocation validation is required.

Another modification is to rebuild the Graphical User Interface. In the proposed solution the GUI is extracted from the application and placed on separate servers. All communication is through web service or a HTML iframe. A GUI more suitable for a task-centric cloud service is needed to bring cloud PKI to a broader mass. Furthermore, the GUI of the EJBCA servers which are loaded into a HTML iframe need to undergo minor modifications to support better validation of input and abstract complex settings.


57

Further modifications discussed were to modify the database table userData as the arbitrary string username is the primary key and using a central archive of certificates. However, if a central archive is used and the CAs are configured not to store any certificate data, the database can remain unmodified. However, this solution would make it more difficult to search the archive. Nevertheless, the usage of the central archive is recommended.

The final recommended action is to construct a beneficial SLA. The application must be thoroughly analyzed to determine to what extent security can be assured. Afterwards, levels of compensations can be set to be profitable for both the provider and the customer, given the perceived risk.

9.1.3 MODIFICATIONS TO THE DESIGN The design constructed in chapter 6 has undergone some modifications throughout the process of this thesis. Taken into account the use of central archive or repository, the cloud will have four categories of points of entry. Figure 9:1 shows the four entry points.

Figure 9:1 The PKI cloud and entries

A client can manage the PKI through the Admin GUI, retrieve certificates from the Repository and validate certificates and retrieve CRLs from the Validation Services. The Service Locator is used by the RA boxes detail in chapter 6.2. Figure 9:2 further shows the final cloud network model.


58

Figure 9:2 The final cloud network model

The network model shown in Figure 9:2 has one key difference from the one constructed in the Design & Implementation chapter. The archive of certificates from each EJBCA server is extracted and placed in a central repository from which the certificates can be retrieved by the users. The local RA boxes still remain as a part of the design even though as discussed in chapter 8.3, the functionality of the boxes needs further investigation. Figure 9:2 shows the final network model of PKI as a Service constructed in this thesis and it is the recommended layout to use when deploying a Public Key Infrastructure as a Cloud Service.

9.2 FINAL DISCUSSION The method used in this thesis is the constructive research method, which can be read in chapter 2. The research method was chosen as traditional methods could not be applied to the specific case. Traditional research methods such as action research have the downside that they are not always as suitable to use in software engineering as constructive research. The first explicitly set method of the thesis was to use a qualitative deductive case study, but as the literature study finished and the problem was further clarified, the constructive research method was chosen instead to continue the work.

The workflow of this thesis has been to collect data through the literature study, analyze the existing constructs and to set a new idea from the knowledge obtained in previous phases. The new idea was then idealized with some simplifications in the proof of concept and proven to function as expected. The workflow is deemed to be consistent with one possible workflow of the constructive research method.


59

The method of evaluation was the proof of concept method in which the feasibility of two core ideas was tested. This entailed setting the ideas, constructing the system and persuasion of the proof by logs and output from the constructed system. This can be considered consistent with the proof of concept method.

Although the set method has been followed throughout the work with the thesis, there are areas in which more knowledge would have been desirable. As a consequence of the trouble with finding suitable literature, the literature concerning the cloud mostly handled demands on the provider and celebration of cloud services instead of really investigating different cloud technologies.

Finally, more effort and consideration should be taken to the restrictions of this thesis. The subject is in a complex area where restrictions are difficult. It is considered the thesis should have been more restrictive in various areas. However, it is difficult to add restrictions afterwards as substantial work has been done.

9.3 FUTURE WORK During the work with this thesis, fields which need further studies have been discovered. One field is the cross-certification and building additional certification paths dynamically. As it is a cloud service, it has the ability to cross certify the email authentication CAs from different customers under one central root email CA. In this scenario every customer that satisfies the criteria of the email certification will be offered to have the email CA certified and join the group of trusted email CAs. The implication would be that all customers in a group could send secure emails to each other and have access to the certificates and revocation information. The scenario relies on dynamically adding the certification path without having to reissue the certificates, which may or may not be possible. The key idea is that the different customers would have a common root that will be trusted by both.

One other field to look into is technologies for distributed networks. One technology found during the work is the Apache Hadoop project which provides among other things a distributed file system and a framework to map and reduce data to be sent across the different nodes in the network. Functions Apache Hadoop could provide can be used to distribute and store revocation information in OCSP servers.

Furthermore regarding OCSP responses, the number of requests to validate a specific certificate might be high at certain points in time. For instance, a CA certificate could be requested to be validated several times per second from different clients. To minimize the workload of the OCSP responder, caching of the result for some time could be used. However, OCSP use POST to send data which should not, in contrary to GET, be cached according to RFC 2616. Hence, further studies in the field of caching an OCSP response are required.

PKI as a Service References

60

10 REFERENCES Allamaraju, S., Avedal, K., Browett, R., Diamond, J. & more (2004) Professional Java Server Programming J2EE Edition, Berkeley: Apress.

Barnatt, C. (2010) A Brief Guide to Cloud Computing, London: Constable & Robinson Ltd.

Choudhury, S., Bhatnagar, K., Haque, W. & NIIT (2002) Public Key Infrastructure Implementation and Design, New York: John Wiley & Sons.

Dodig Crnkovic, G. (2010) 'Constructive Research and Info-computational Knowledge Generation', Studies in Computational Intelligence, vol. 314, pp. 359-380.

Entrust (2011) Managed Services PKI : Key Technical Features, 4Jan, [Online], Available: http://entrust.com/managed_services/key-technical-features.htm [18 Jan 2011].

Forouzan, B.A. (2007) Data Communications and Networking, 4th edition, New York: McGraw-Hill.

Housley, R. & Polk, T. (2001) Planning for PKI: Best Practices Guide for Deploying Public Key Infrastructure, New York: John Wiley & Sons.

Internet Engineering Task Force (2010) Request for Comments (RFC) Pages, 18Nov, [Online], Available: http://www.ietf.org/rfc.html [28 Jan 2011].

Jansen, W. & Grance, T. (2011) Guidelines on Security and Privacy in Public Cloud Computing, Gaithersburg: National Institute of Standards and Technology.

McDonald, K.T. (2010) Above the Clouds: Managing Risk in the World of Cloud Computing, Cambridgeshire: IT Governance.

Oltsik, J. (2010) Symantec + Verisign = Cloud Security, 20May, [Online], Available: http://www.networkworld.com/community/blog/symantec-verisign-cloud-security [3 Nov 2010].

PrimeKey Solutions AB (2010) EJBCA - Open Source PKI Certificate Authority, 23Dec, [Online], Available: http://ejbca.org/ [10 Jan 2011].

PrimeKey Solutions AB (2011) EJBCA Wiki, 5Jan, [Online], Available: http://wiki.ejbca.org/ [10 Jan 2011].

Rittinghouse, J.W. & Ransome, J.F. (2010) Cloud Computing: Implementation, Management, and Security, Florida: Auerbach Publications.

Vacca, J.R. (2004) Public Key Infrastructure: Building Trusted Applications and Web Services, Florida: Auerbach Publications.

Velte, A.T., Velte, T.J. & Elsenpeter, R. (2010) Cloud Computing: A Practical Approach, New York: McGraw-Hill/Osborne.

PKI as a Service Appendixes

61

11 APPENDIXES

11.1 BASH SCRIPT TO GENERATE DATABASE MODEL Executable script to generate XML file with all tables with structure in a database from MySQL and then transform it to executable DIA file. Originally written by alias wiselynx and script found at http://plindenbaum.blogspot.com/2008/10/creating-dia-diagrams-from-mysql-via.html [2010-11-17]. Minor modifications have been made by author.

Dia is a GTK+ based diagram creation program for GNU/Linux, MacOS X, Unix, and Windows, and is released under the GPL license. Available at http://live.gnome.org/Dia.

#!/bin/bash while getopts d:h:u:x:p: opt; do case "$opt" in d) database="$OPTARG";; h) host="$OPTARG";; u) user="$OPTARG";; x) xsldoc="$OPTARG";; p) password="=$OPTARG";; esac done if [ ! "$database" ]; then echo "Missing mandatory -d option (database name)" && exit 1 fi tables=$(mysql $database -h $host -u $user --password${password} -A -e "SHOW TABLES" | sed -e 's/\W//g' | grep -v "Tables_in_${database}") query="" for table in $tables; do query=${query}" DESC "${table}";" done xml="<root>"$(mysql $database -h $host -u $user --password${password} -A -e "${query}" -X | grep -v "<?xml")"</root>" echo $xml | xmllint --format - > ${database}.xml xsltproc ${xsldoc} ${database}.xml | gzip -c > ${database}.dia

62

11.2 XSL DOCUMENT TO TRANSFORM XML TO DIA XSL document to transform XML into executable DIA. Originally written by Pierre Lindenbaum and code fount at http://code.google.com/p/lindenb/source/browse/trunk/src/xsl/sql2dia.xsl [2010-11-17]. Modified by author to generate database classes instead of UML classes, with marked primary keys and nullable fields.

<?xml version='1.0' ?> <xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:dia='http://www.lysator.liu.se/~alla/dia/' version='1.0'>  <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>  <xsl:template match="/"> <dia:diagram> <xsl:comment> Generated with sql2dia.xsl Author: Pierre Lindenbaum PhD. [email protected] </xsl:comment> <dia:diagramdata> <dia:attribute name="background"> <dia:color val="#aaaaaa"/> </dia:attribute> <dia:attribute name="pagebreak"> <dia:color val="#000099"/> </dia:attribute> <dia:attribute name="paper"> <dia:composite type="paper"> <dia:attribute name="name"> <dia:string>#A4#</dia:string> </dia:attribute> <dia:attribute name="tmargin"> <dia:real val="2.8222000598907471"/> </dia:attribute> <dia:attribute name="bmargin"> <dia:real val="2.8222000598907471"/> </dia:attribute> <dia:attribute name="lmargin"> <dia:real val="2.8222000598907471"/> </dia:attribute> <dia:attribute name="rmargin"> <dia:real val="2.8222000598907471"/> </dia:attribute> <dia:attribute name="is_portrait"> <dia:boolean val="true"/> </dia:attribute> <dia:attribute name="scaling"> <dia:real val="1"/> </dia:attribute> <dia:attribute name="fitto"> <dia:boolean val="false"/> </dia:attribute> </dia:composite> </dia:attribute> <dia:attribute name="grid"> <dia:composite type="grid"> <dia:attribute name="width_x"> <dia:real val="1"/> </dia:attribute> <dia:attribute name="width_y"> <dia:real val="1"/> </dia:attribute> <dia:attribute name="visible_x">

63

<dia:int val="1"/> </dia:attribute> <dia:attribute name="visible_y"> <dia:int val="1"/> </dia:attribute> <dia:composite type="color"/> </dia:composite> </dia:attribute> <dia:attribute name="color"> <dia:color val="#d8e5e5"/> </dia:attribute> <dia:attribute name="guides"> <dia:composite type="guides"> <dia:attribute name="hguides"/> <dia:attribute name="vguides"/> </dia:composite> </dia:attribute> </dia:diagramdata> <dia:layer name="Background" visible="true"> <xsl:apply-templates select="//resultset"/> </dia:layer> </dia:diagram> </xsl:template>  <xsl:template match="resultset"> <xsl:variable name="tableName" select="normalize-space(substring(@statement,5))"/> <dia:object type="Database - Table" version="0" id="O0"> <xsl:variable name="width">5.5</xsl:variable> <xsl:variable name="height">3.0</xsl:variable> <xsl:variable name="x"> <xsl:value-of select="number($width) * number( position() mod 5 )"/> </xsl:variable> <xsl:variable name="y"> <xsl:value-of select="number($height) * round( position() div 5 )"/> </xsl:variable> <dia:attribute name="obj_pos"> <xsl:element name="dia:point"> <xsl:attribute name="val"> <xsl:value-of select="$x"/>, <xsl:value-of select="$y"/> </xsl:attribute> </xsl:element> </dia:attribute> <dia:attribute name="obj_bb"> <xsl:element name="dia:rectangle"> <xsl:attribute name="val"> <xsl:value-of select="$x"/>, <xsl:value-of select="$y"/>; <xsl:value-of select="$x + $width"/>, <xsl:value-of select="$y + $height"/> </xsl:attribute> </xsl:element> </dia:attribute> <dia:attribute name="elem_corner"> <xsl:element name="dia:point"> <xsl:attribute name="val"> <xsl:value-of select="$x"/>, <xsl:value-of select="$y"/> </xsl:attribute> </xsl:element> </dia:attribute> <dia:attribute name="elem_width"> <xsl:element name="dia:real"> <xsl:attribute name="val"> <xsl:value-of select="$width"/> </xsl:attribute> </xsl:element> </dia:attribute> <dia:attribute name="elem_height"> <xsl:element name="dia:real"> <xsl:attribute name="val"> <xsl:value-of select="$height"/> </xsl:attribute> </xsl:element> </dia:attribute>


64

<dia:attribute name="name"> <dia:string>#<xsl:value-of select="$tableName"/>#</dia:string> </dia:attribute> <dia:attribute name="stereotype"> <dia:string>##</dia:string> </dia:attribute> <dia:attribute name="comment"> <dia:string>#Table <xsl:value-of select="$tableName"/>#</dia:string> </dia:attribute> <dia:attribute name="line_color"> <dia:color val="#000000"/> </dia:attribute> <dia:attribute name="fill_color"> <dia:color val="#ffffff"/> </dia:attribute> <dia:attribute name="text_color"> <dia:color val="#000000"/> </dia:attribute> <dia:attribute name="normal_font"> <dia:font family="monospace" style="0" name="Courier"/> </dia:attribute> <dia:attribute name="abstract_font"> <dia:font family="monospace" style="88" name="Courier-BoldOblique"/> </dia:attribute> <dia:attribute name="polymorphic_font"> <dia:font family="monospace" style="8" name="Courier-Oblique"/> </dia:attribute> <dia:attribute name="classname_font"> <dia:font family="sans" style="80" name="Helvetica-Bold"/> </dia:attribute> <dia:attribute name="abstract_classname_font"> <dia:font family="sans" style="88" name="Helvetica-BoldOblique"/> </dia:attribute> <dia:attribute name="comment_font"> <dia:font family="sans" style="8" name="Helvetica-Oblique"/> </dia:attribute> <dia:attribute name="normal_font_height"> <dia:real val="0.80000000000000004"/> </dia:attribute> <dia:attribute name="polymorphic_font_height"> <dia:real val="0.80000000000000004"/> </dia:attribute> <dia:attribute name="abstract_font_height"> <dia:real val="0.80000000000000004"/> </dia:attribute> <dia:attribute name="classname_font_height"> <dia:real val="1"/> </dia:attribute> <dia:attribute name="abstract_classname_font_height"> <dia:real val="1"/> </dia:attribute> <dia:attribute name="comment_font_height"> <dia:real val="0.69999999999999996"/> </dia:attribute> <dia:attribute name="attributes"> <xsl:for-each select="row"> <dia:composite type="table_attribute"> <dia:attribute name="name"> <dia:string>#<xsl:value-of select="field[@name='Field']"/>#</dia:string> </dia:attribute> <dia:attribute name="type"> <dia:string>#<xsl:value-of select="field[@name='Type']"/>#</dia:string> </dia:attribute> <dia:attribute name="value"> <dia:string> #<xsl:value-of select="field[@name='Default']"/># </dia:string> </dia:attribute> <dia:attribute name="comment"> <dia:string>#<xsl:value-of select="field[@name='Field']"/>#</dia:string> </dia:attribute> <dia:attribute name="nullable"> <xsl:choose> <xsl:when test="field[@name='Null'] = 'YES'"> <dia:boolean val="true"/> </xsl:when>


65

<xsl:otherwise> <dia:boolean val="false"/> </xsl:otherwise> </xsl:choose> </dia:attribute> <dia:attribute name="primary_key"> <xsl:choose> <xsl:when test="field[@name='Key'] = 'PRI'"> <dia:boolean val="true"/> </xsl:when> <xsl:otherwise> <dia:boolean val="false"/> </xsl:otherwise> </xsl:choose> </dia:attribute> </dia:composite> </xsl:for-each> </dia:attribute> </dia:object> </xsl:template> </xsl:stylesheet>


66

11.3 USE OF JQUERY VALIDATION PLUG-IN AND CUSTOM VALIDATION RULES The JQuery validation plug-in is release under MIT/GPL licenses and can be found at http://bassistance.de/jquery-plugins/jquery-plugin-validation/.

To use the plug-in, JQuery is also needed and it can be found at http://jquery.com/. The following snippet adds a validation handler to all forms with the CSS class validate_form, specifies the error element as HTML span element and the placement of the element to be last in the DOM parent.

$(".validate_form").each(function() { $(this).validate({ debug: true, errorElement: "span", errorPlacement: function(error, element) { $(element).parent().append(error); } }); });

To add a validation handler to an input field there are different approaches. The one used in the prototype is adding a specific keyword to the attribute class in the HTML input field declaration. For instance,

<input type=”text” class=”required” />

This input field will be validated as a required field and cannot therefore be left empty when submitting the form.

The following methods are added to support validation of special cases. All are not specified in the mockup prototype.

$.validator.addMethod("confirm_password", function(value, element) { return this.optional(element) || $(this.currentForm).find(".password_to_confirm").val() == value; }, "Passwords do not match."); $.validator.addMethod("domain", function(value, element) { return this.optional(element) || /^((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$/i.test(value); }, "Not valid domain."); $.validator.addMethod("emailname", function(value, element) { return this.optional(element) || /^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))$/i.test(value); }, "Not valid email."); $.validator.addMethod("ipaddress", function(value, element) { return this.optional(element) || /^(((25[0-5]|2[0-4][0-9]|[1]?[0-9][0-9]?|0)\.){3}((25[0-5]|2[0-4][0-9]|[1]?[0-9][0-9]?|0)\.?)(:([1-9][0-9]*))?)|(([0-9a-fA-F]{0,4}:)+([0-9a-fA-F]{0,4}))$/.test(value); }, "Not valid ipaddress."); $.validator.addMethod("dateYMD", function(value, element) { return this.optional(element) || /^(19|20)[0-9]{2}(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01])$/.test(value); }, "Not valid date.");


67

$.validator.addMethod("dnval", function(value, element) { return this.optional(element) || !/([\u0022\u0023\u002b\u002c\u003b\u003c\u003e\u005c])/.test(value); }, "Not valid. Cannot use following characters: # + ; < > , \" \\"); $.validator.addMethod("hex", function(value, element) { return this.optional(element) || !/([^a-fA-F0-9 ])/.test(value); }, "Not valid hex"); $.validator.addMethod("gender", function(value, element) { return this.optional(element) || /^[MFmf]$/.test(value); }, "Only use M or F");


68

11.4 GLOSSARY Acronym Meaning Description AES Advance Encryption Standard Symmetric cryptography algorithm CA Certificate Authority Authority that issues certificates and

vouches for the certificate contents CLI Command Line Interface Text based interface CMC Certificate Management over CMS PKI management protocol CMP Certificate Management Protocol PKI management protocol CMS Cryptographic Message Syntax Standard for cryptographic messages CP Certificate Policy High-level document, vital to PKI,

describing what is done CPS Certification Practices Statement High-level document, vital to PKI,

describing how CP is implemented CRL Certificate Revocation List List of revoked certificates CRUD Create, Retrieve, Update and Delete Operations in the database DES Data Encryption Standard Symmetric cryptography algorithm, also

3DES with three encryption phases DH Diffie-Hellman Key agreement algorithm DN Distinguished Name Key value pair as per X.500 DOS Denial-of-Service Attack to flood the network, also

DDOS as a distributed form. DSA Digital Signature Algorithm Asymmetric cryptography algorithm ECDSA Elliptic Curve DSA Asymmetric cryptography algorithm EJB Enterprise Java Beans Component of Java Enterprise Edition EJBCA Enterprise Java Beans Certificate Authority PKI solution offered by PrimeKey

Solutions AB FTP File Transfer Protocol Common protocol used for file transfer

in various networks GUI Graphical User Interface Graphical interface from which the user

can interact with the software HSM Hardware Security Module Device to generate, store and use private

keys HTML Hypertext Markup Language Markup language used in web pages HTTP Hypertext Transfer Protocol Common protocol used for data

transfer in various networks HTTPS HTTP Secure HTTP over SSL/TLS IaaS Infrastructure as a Service Bottom level of cloud services IDEA International Data Encryption Algorithm Symmetric cryptography algorithm JKS Java Key Store Certificate exportable format LDAP Lightweight Directory Access Protocol PKI repository protocol LGPL Lesser General Public License Type of Open Source software license MVC Model View Control Design pattern MD5 Message Digest algorithm 5 Hash algorithm OCSP Online Certificate Status Protocol Certificate validation protocol PaaS Platform as a Service Middle level of cloud services PEM Privacy Enhanced Mail Certificate exportable format PIN Personal Identification Number A series of digits used as password PKCS Public Key Cryptography Standard Collection of cryptographic standards

set by RSA Security


69

PKCS#7 Cryptographic Message Syntax Standard PKI messaging standard PKCS#10 Certification Request Syntax Standard PKI messaging standard PKCS#11 Cryptographic Token Interface Token standard for key information PKCS#12 Personal Information Exchange Syntax Standard Certificate exportable format and soft

mode standard for key information PKI Public Key Infrastructure Infrastructure to support the use of

certificates RA Registration Authority Authority with delegated responsibility

to validate request content RFC Request For Comment Documents by IETF describing

Internet standards and protocol. RMI Remote Method Invocation Communication method of Java

Enterprise Edition RSA Rivest, Shamir, Adleman Asymmetric cryptography algorithm SaaS Software as a Service Top level of cloud services SCEP Simple Certificate Enrollment Protocol PKI management protocol SHA-1 Secure Hash Algorithm 1 Hash algorithm SLA Service Level Agreement High-level document detailing the level

of service the provider offers SOAP Simple Object Access Protocol, originally but

meaning later removed Protocol specification for exchanging data in a Web Service

SQL Structured Query Language Language to query databases SSL Secure Sockets Layer Protocol for encrypted communication XML eXtensible Markup Language Markup language for non binary data XSLT eXtensible Stylesheet Language Transformations Stylesheet language that transforms

XML to described format

TRITA-CSC-E 2011:025 ISRN-KTH/CSC/E--11/025-SE

ISSN-1653-5715

www.kth.se