204
Samuel Gheller Building of an infrastructure PKI used in an environment of a trading online system 1/204 Thesis Building of an infrastructure PKI used in an environment of a trading online system PROFESSOR: STEFANO VENTURA COMPANIES MANDATE: IT SOFTWARE – MILAN (ITALY) STUDENT: SAMUEL GHELLER – TR 2007 DATE: 23/12/2007

PKI_Thesis - Gheller Samuel

Embed Size (px)

DESCRIPTION

Thèse école d'ingénieur d'YverdonSoutien OCSP par Sylvain Maret

Citation preview

Page 1: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 1/204

Thesis

Building of an infrastructure PKI used in an environment of a trading online system

PROFESSOR: STEFANO VENTURA

COMPANIES MANDATE: IT SOFTWARE – MILAN (ITALY)

STUDENT: SAMUEL GHELLER – TR 2007

DATE: 23/12/2007

Page 2: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 2/204

Project scope The diploma thesis will be executed in a society, based in Milan, called IT Software. The definition of the project purpose has for a working title: "Building of an infrastructure PKI1 used in an environment of a trading online system"

Environment Currently, IT Software (www.itsoftware.it) develops and distributes trading online systems for its own clients, which are financial institutions. The enterprise wants to explore the possibility to use a PKI infrastructure to guarantee a stronger reliability in its client's authentication (with digital certificates for the clients). To this day, the system is based on a simple authentication solution dealing with logins and passwords. The project will implement a PKI based on open source software. Particularly, the student will: ٠ suggest and verify one or more architectural solutions ٠ define the procedure of attribution and revocation of certificates ٠ define the integration mode with the actual infrastructure ٠ explore, in terms of costs and technique, eventual biometrical authentication systems which

can be integrated within the defined PKI ٠ realize a demonstration based on open source products and showing the PKI solution

proposed. One of the most interesting aspects of this project resides in the good choice of the type of license open source to be used so that IT Software can deploy without constraints the suggested PKI-solution. The system could be integrated in a web-based infrastructure (most important) and also in client/server infrastructure (less important). Work will be divided in two distinguished parts: 1) Logistic and organisation aspects

- Written definition of the proposed architecture - Application installation and configuration on IT Software's infrastructure - Certificate checks and tests (attribution, revocation, etc.) - Written documentation of the executed activity - Documentation on the choices of the realized configuration and the motivation which

have brought about these choices

1 Public Key Infrastructure

Page 3: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 3/204

- Setting up of the organizational aspects (automatic procedures of attribution/revocation, backup/restore procedures, etc.)

2) Software integration Web-based integration example

- Certificate installation on commercial browsers like IE 6/7, Firefox 2 and check on the compatibility

- Web-based demo application using certificates - Check of the behavior in case of revocation

Page 4: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 4/204

Table of contents

PROJECT SCOPE................................................................................................................................................ 2

TABLE OF CONTENTS...................................................................................................................................... 4

TABLE OF ILLUSTRATIONS........................................................................................................................... 8

SUMMARY MANAGEMENT ...........................................................................................................................11

GOALS................................................................................................................................................................11 RESULTS AND STATE ..........................................................................................................................................12

THANKS...............................................................................................................................................................13

INTRODUCTION................................................................................................................................................14

PLAN.....................................................................................................................................................................15

< THEORY >........................................................................................................................................................17

1. SECURITY NOTIONS....................................................................................................................................18

2. CRYPTOGRAPHY..........................................................................................................................................19

2.1 SYMMETRIC KEY ENCRYPTION .....................................................................................................................19 2.1.1 Diffie-Hellman .....................................................................................................................................20

2.2 ASYMMETRIC KEY ENCRYPTION ...................................................................................................................21 2.3 HYBRID ENCRYPTION ...................................................................................................................................22 2.4 HASH FUNCTION ...........................................................................................................................................23 2.5 "MAN IN THE MIDDLE" ATTACK (MITM) .....................................................................................................24 2.6 TRUSTED THIRD PARTY ................................................................................................................................25

2.6.1 Captcha................................................................................................................................................25 2.6.2 Others precautions ..............................................................................................................................25

3. AUTHENTICATION ......................................................................................................................................27

3.1 SIMPLE AUTHENTICATION VS. STRONG AUTHENTICATION ............................................................................27 3.2 STRONG AUTHENTICATION ...........................................................................................................................28

3.2.1 One time Password (OTP)...................................................................................................................30 3.2.2 Token ...................................................................................................................................................30 3.2.3 CAP (Chip Authentication Program) ..................................................................................................32 3.2.4 CHAP (Challenge Handshake Authentication Protocol).....................................................................34 3.2.5 AAA protocols......................................................................................................................................35 3.2.6 PGP (hybrid encryption) .....................................................................................................................36 3.2.7 Kerberos ..............................................................................................................................................37 3.2.8 TLS (SSL) – HTTPS .............................................................................................................................39

4. PKI (PUBLIC KEY INFRASTRUCTURE) ..................................................................................................41

4.1 PKI OFFERED SERVICES ................................................................................................................................41 4.2 ELEMENTS MAKING A PKI............................................................................................................................41 4.3 PKI FUNCTIONS ............................................................................................................................................42 4.4 KEYS MANAGEMENT ....................................................................................................................................42 4.5 CERTIFICATION AUTHORITY (CA)................................................................................................................43 4.6 REGISTRATION AUTHORITY (RA) ................................................................................................................44 4.7 VALIDATION AUTHORITY (VA)....................................................................................................................45 4.8 CERTIFICATES ..............................................................................................................................................45 4.9 INTEROPERABILITY ......................................................................................................................................47 4.10 DIRECTORY ................................................................................................................................................47

5. BIOMETRICS..................................................................................................................................................49

5.1 GENERAL POINTS..........................................................................................................................................49

Page 5: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 5/204

5.2 TECHNOLOGIES ............................................................................................................................................50 5.2.1 Fingerprint ..........................................................................................................................................51

5.3 MARKET.......................................................................................................................................................53 5.4 LEGISLATION................................................................................................................................................54 5.5 COSTS EVALUATION .....................................................................................................................................55

6. DEMONSTRATION CASE............................................................................................................................56

7. ARCHITECTURAL STRUCTURE...............................................................................................................57

8. PKI IMPLEMENTATION .............................................................................................................................58

8.1 THIN CLIENT (WEB BASED) SOLUTION..........................................................................................................58 8.2 FAT CLIENT SOLUTION..................................................................................................................................59 8.3 RICH CLIENT SOLUTION ................................................................................................................................59

9. PKI COMPOSITION ......................................................................................................................................60

9.1 CHOICE OF THE SOFTWARE FOR KEY MANAGEMENT EXCHANGE...................................................................60 9.2 COMPARISON BETWEEN MICROSOFT CA AND OPEN CA..............................................................................61

< PRACTICE > ....................................................................................................................................................63

10. SET UP OF THE OPENCA PKI ENVIRONMENT ..................................................................................64

10.1 CONFIGURATION OF PKI SERVERS..............................................................................................................64 10.1.1 General ..............................................................................................................................................65 10.1.2 Apache2 modules configuration ........................................................................................................66 10.1.3 Apache configuration for PKI server.................................................................................................68 10.1.4 Databases creation ............................................................................................................................68 10.1.5 CA Configuration ..............................................................................................................................72 10.1.6 RA Configuration...............................................................................................................................72

10.2 CA INITIALIZATION ....................................................................................................................................74 10.2.1 Phase I: Initialize the Certification Authority ...................................................................................76 10.2.2 Phase II: Create the initial administrator .........................................................................................78 10.2.3 Phase III: Create the initial RA certificate ........................................................................................78

10.3 RA INITIALIZATION ....................................................................................................................................78 10.4 DATA EXCHANGE .......................................................................................................................................80

11. LOGISTICAL ASPECTS .............................................................................................................................82

11.1 INTERACTION WITH THE CLIENT .................................................................................................................82 11.2 WHO ARE THE CLIENTS? .............................................................................................................................82 11.3 ARCHITECTURAL IMPLEMENTATION...........................................................................................................84 11.4 FIREWALL CONFIGURATION........................................................................................................................84 11.5 DELIVERY MODE OF CERTIFICATE / KEY PAIR AND PIN CODE .....................................................................86

11.5.1 Export certificate onto a token ..........................................................................................................87 11.5.2 Necessary modification in mail account ............................................................................................88

12. OPENCA STRUCTURE ...............................................................................................................................90

12.1 PUBLIC INTERFACE .....................................................................................................................................91 12.2 CA INTERFACE ...........................................................................................................................................91 12.3 RA INTERFACE ...........................................................................................................................................91 12.4 NODE (CA-NODE AND RA-NODE) INTERFACE ............................................................................................92

13. PROCESS OF CERTIFICATE'S REQUEST.............................................................................................93

13.1 REQUEST OF CERTIFICATE FROM RA ADMINISTRATOR ...............................................................................93 13.2 APPROVAL OF THE REQUEST BY RA ADMINISTRATOR ................................................................................95 13.3 APPROVAL AND ISSUING OF THE CERTIFICATE BY CA ADMINISTRATOR .....................................................99 13.4 PUBLICATION OF THE CERTIFICATE BY RA ADMINISTRATOR ....................................................................101

14. PROCESS OF CERTIFICATE'S REVOCATION ..................................................................................103

14.1 BEGINNING OF REVOCATION PROCESS BY RA ADMINISTRATOR ...............................................................103 14.2 APPROVAL OF THE PROCESS BY CA ADMINISTRATOR...............................................................................107

Page 6: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 6/204

14.3 PUBLICATION BY RA ADMINISTRATOR.....................................................................................................108

15. WEB SERVER .............................................................................................................................................109

15.1 GENERATION OF WEB SERVER CERTIFICATE .............................................................................................109 15.2 SIGNATURE BY THE CA ............................................................................................................................109

16. FILE FORMATS .........................................................................................................................................112

16.1 ASN.1 (ABSTRACT SYNTAX NOTATION ONE)..........................................................................................112 16.2 FILES GENERATED BY THE PKI.................................................................................................................113

16.2 1 .DER (Distinguished Encoding Rules).............................................................................................114 16.2.2 .CER (Encoded Certificate) .............................................................................................................114 16.2.3 .PEM (Privacy-enhanced Electronic Mail) .....................................................................................114 16.2.4 Others formats .................................................................................................................................115

16.3 MOSTLY USED PKCS FORMATS TO EXCHANGE DATA...............................................................................115 16.3.1 PKCS # 7 .........................................................................................................................................115 16.3.2 PKCS # 10 .......................................................................................................................................115 16.3.3 PKCS # 11 .......................................................................................................................................115 16.3.4 PKCS # 12 .......................................................................................................................................115

17. INTEROPERABILITY INTER-PKI .........................................................................................................116

<BUILDING AND REALIZATION>..............................................................................................................119

18. APPLICATION CHECK OF VALIDITY OF THE CERTIFICATE WITH THE CRL .....................120

18.1 INTEGRATION MODE WITH THE ACTUAL INFRASTRUCTURE ......................................................................120 18.2 REQUEST TO A LDAP DIRECTORY ............................................................................................................120 18.3 REQUEST TO A CRL .................................................................................................................................121 18.4 REQUEST TO AN OCSP RESPONDER..........................................................................................................122

18.4.1 Building of OCSP architecture ........................................................................................................124 18.4.2 Static OCSP request ........................................................................................................................126 18.4.3 Dynamic OCSP request ...................................................................................................................127 18.4.4 Problems encountered .....................................................................................................................127 18.4.5 Kind of OCSP errors .......................................................................................................................128 18.4.6 Security considerations....................................................................................................................128 18.4.7 Alternative with SCVP .....................................................................................................................129

19. DATABASE MANAGEMENT...................................................................................................................130

20. MANAGEMENT OF LOGS.......................................................................................................................131

20.1 ADD LOGS ................................................................................................................................................131 20.2 BASH SCRIPTING.......................................................................................................................................133

20.2.1 ALERT .............................................................................................................................................133 20.2.2 NEWcrl ............................................................................................................................................135 20.2.3 CRLexpire........................................................................................................................................135

21. BIOMETRICS DEPLOYMENT ................................................................................................................137

21.1 MATCH ON CARD.....................................................................................................................................137 21.2 FINGERPRINT READER ..............................................................................................................................138 21.3 SMARTCARD.............................................................................................................................................139

21.3.1 Installation.......................................................................................................................................140 21.3.2 Profiles ............................................................................................................................................140 21.3.3 Fingerprint registering ....................................................................................................................142 21.3.4 Import of Certificate & Keys ...........................................................................................................143

21.4 TEST-BENCH.............................................................................................................................................145 21.4.1 Test 1 – Access to the web site with a certificate and a Match On Card process............................146 21.4.2 Test 2 – without the smartcard inserted or the fingerprint reader plugged-in ................................148 21.4.3 Test 3 – Fake finger .........................................................................................................................149 21.4.4 Test 4 – Revoked certificate .............................................................................................................150

22. BEHAVIOR OF THE SYSTEM WITH CERTIFICATES......................................................................152

Page 7: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 7/204

22.1 AUTHENTICATED STANDARD CERTIFICATE...............................................................................................152 22.2 AUTHENTICATED CERTIFICATE WITH MATCH ON CARD...........................................................................154 22.3 CERTIFICATE WITH OCSP CHECKING .......................................................................................................154

22.3.1 Web server side................................................................................................................................154 22.4 REVOKED CERTIFICATE TRYING TO CONNECT...........................................................................................155 22.5 NON-AUTHORIZED CERTIFICATE (PKI SERVER FILES PROTECTED) ...........................................................156

23. TASK’S PLANNING ...................................................................................................................................157

24. STATUS OF THE PROJECT.....................................................................................................................158

25. ENHANCEMENTS......................................................................................................................................160

CONCLUSION...................................................................................................................................................162

ANNEXES ..........................................................................................................................................................164

ANNEX 1 – PKCS STANDARDS ........................................................................................................................164 ANNEX 2 – BIOMETRICS, OTHER SOLUTIONS ....................................................................................................165

2.1 Hand .....................................................................................................................................................165 2.2 Face ......................................................................................................................................................166 2.3 Voice .....................................................................................................................................................166 2.4 Eye .......................................................................................................................................................168 2.5 Signature...............................................................................................................................................170 2.6 The dynamics of typing on a keyboard .................................................................................................171

ANNEX 3 – CONFIGURATION OF APACHE FOR PKI SERVER ..............................................................................173 ANNEX 4 – CONFIG.XML OF THE CA (THE GLOBAL CONFIGURATION FILE OF THE CA).....................................176 ANNEX 5 – APACHE CONFIGURATION FOR WEB SERVER (CHECK VALIDITY WITH CRL) ...................................191 ANNEX 6 – CONFIGURATION OCSP DAEMON.....................................................................................................192 ANNEX 7 – PERL MODULE MANAGING OCSP REQUEST TO THE VA .................................................................196 ANNEX 8 – ALERT BASH SCRIPT .....................................................................................................................197 ANNEX 9 – NEWCRL BASH SCRIPT...................................................................................................................198 ANNEX 10 – CRLEXPIRE BASH SCRIPT .............................................................................................................199 ANNEX 11 – LIST OF POSSIBLE CHANGES OF SMARTCARD'S PROFILE PARAMETERS ..........................................200

BIBLIOGRAPHY ..............................................................................................................................................201

BOOKS .............................................................................................................................................................201 DOCUMENTS ....................................................................................................................................................201 RFC’S ..............................................................................................................................................................201 INTERNET .........................................................................................................................................................201

LIST OF ACRONYMS......................................................................................................................................203

Page 8: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 8/204

Table of illustrations Figure 1: Symmetric encryption............................................................................................20 Figure 2: Diffie-Hellman Algorithm .....................................................................................20 Figure 3: Asymmetric key encryption ...................................................................................22 Figure 4: Hybrid encryption..................................................................................................23 Figure 5: Man in the middle attack .......................................................................................24 Figure 6: Example of a captcha request.................................................................................25 Figure 7: Different kind of strong authentication solutions....................................................29 Figure 8: Strong authentication pyramid ...............................................................................30 Figure 9: Passive token.........................................................................................................31 Figure 10: Time token ..........................................................................................................31 Figure 11: Counter token ......................................................................................................31 Figure 12: Smartcard ............................................................................................................32 Figure 13: USB token...........................................................................................................32 Figure 14: Chip Authentication Program ..............................................................................33 Figure 15: PGP encryption ...................................................................................................36 Figure 16: PGP decryption ...................................................................................................37 Figure 17: Kerberos mechanisms..........................................................................................38 Figure 18: PKI mechanism ...................................................................................................45 Figure 19: Use of a trusted third party...................................................................................46 Figure 20: X509v3 certificate ...............................................................................................47 Figure 21: Compromise between FRR and FAR ...................................................................50 Figure 22: Risks due to the chosen system............................................................................50 Figure 23: User registration process......................................................................................51 Figure 24: Fingerprint with minutiae and different kind of attention to detail........................52 Figure 25: Fingerprint capture ..............................................................................................52 Figure 26: Projection of biometry's market evolution............................................................54 Figure 27: Assets and drawbacks of the different biometry technologies...............................55 Figure 28: Thought architectural solution .............................................................................57 Figure 29: Thin client (web based) solution ..........................................................................58 Figure 30: Comparative Microsoft CA vs OpenCA...............................................................62 Figure 31: Perl's modules that need to be installed ................................................................66 Figure 32: Creation of two databases in pgAdmin.................................................................70 Figure 33: openca_ca schema creation with the relative SQL command generated................71 Figure 34: openca_ra schema creation with the relative SQL command generated ................71 Figure 35: CA initialization ..................................................................................................75 Figure 36: CA initialization - Phase I....................................................................................76 Figure 37: Tables created in CA's database at the initialization .............................................76 Figure 38: Generation of CA Certificate Request..................................................................77 Figure 39: DN of CA Certificate Request .............................................................................77 Figure 40: CA initialization - Phase II and III .......................................................................78 Figure 41: Initialization of the RA ........................................................................................79 Figure 42: Possible operations of data exchange between CA and RA ..................................80 Figure 43: Entire process between IT Software and the client ...............................................83 Figure 44: PKI architecture...................................................................................................84

Page 9: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 9/204

Figure 45: Download certificate onto token ..........................................................................87 Figure 46: Certificat installed in the browser ........................................................................87 Figure 47: Choice of PIN code by the administrator..............................................................88 Figure 48: Lifecycle of the certificate ...................................................................................90 Figure 49: Public interface....................................................................................................91 Figure 50: CA interface ........................................................................................................91 Figure 51: RA interface ........................................................................................................91 Figure 52: Node interface (ca-node, ra-node)........................................................................92 Figure 53: Different kinds of certificate requests ..................................................................93 Figure 54: Certificate's owner data that needs to be filled in this form...................................94 Figure 55: New certificate request existing in RA's database ................................................96 Figure 56: Available options for RA to manage certificate request........................................97 Figure 57: Uploading of certificate requests from RA to CA.................................................98 Figure 58: Result of the data exchange .................................................................................98 Figure 59: Reception of certificate request by the CA ...........................................................99 Figure 60: Available options of the CA for the certificate request .......................................100 Figure 61: Enrolling of validated certificates from CA to RA .............................................100 Figure 62: Downloading the validated certificates from CA................................................101 Figure 63: Certificate is in a valid status and is usable ........................................................102 Figure 64: View of valid certificates ...................................................................................103 Figure 65: Possible operations on valid certificates.............................................................104 Figure 66: Notification about the revocation reason ............................................................104 Figure 67: Generation of the certificate revocation request .................................................104 Figure 68: Available options on a certificate revocation request for RA..............................105 Figure 69: Status of certificate change in a revocation request ............................................106 Figure 70: Upload certificate revocation request to CA.......................................................106 Figure 71: Reception of certificate revocation request by the CA........................................107 Figure 72: Possible options offered to the CA to manage the revocation request .................107 Figure 73: Enroll the new CRL to the RA...........................................................................108 Figure 74: RA downloads the new CRL..............................................................................108 Figure 75: Form filled for the signing of an existing certificate (web server's certificate) ....110 Figure 76: Warning of a non-trusted authority ....................................................................117 Figure 77: Private PKI trusted by a public one....................................................................117 Figure 78: Example of LDAP directory hierarchy...............................................................120 Figure 79: User authentication thanks to OCSP validation process......................................123 Figure 80: Apache variables ...............................................................................................133 Figure 81: First "Internet Explorer" and then "Firefox" warnings about the expiry of web

server's certificate .......................................................................................................135 Figure 82: Match On Card process......................................................................................137 Figure 83: Exemple of MOC reader....................................................................................138 Figure 84: Set up of Smartcard configuration......................................................................140 Figure 85: Profile configuration..........................................................................................141 Figure 86: Administrator PIN code and operation success ..................................................141 Figure 87: Configuration of bio_test_FINGER profile ........................................................142 Figure 88: Choice of the finger and capture of the fingerprint .............................................143 Figure 89: Import of the certificate over the smartcard........................................................144 Figure 90: Import of user's certificate .................................................................................144 Figure 91: Challenge on password protecting certificate backup .........................................145 Figure 92: Certificate imported with success.......................................................................145

Page 10: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 10/204

Figure 93: Choice of the correct certificate .........................................................................146 Figure 94: Biometric authentication with fingerprint...........................................................146 Figure 95: Warning of non-trusted site................................................................................147 Figure 96: Certificate authenticated with Match On Card....................................................147 Figure 97: Certificate that requires biometric authentication inserted in the browser ...........148 Figure 98: Without smartcard introduced............................................................................149 Figure 99: Fake finger trying to authenticate.......................................................................149 Figure 100: Warning of certificate revoked.........................................................................150 Figure 101: Valid and non-valid certificates stored over the smartcard................................151 Figure 102: Server presents its own certificate and CA certificate to the user......................152 Figure 103: Warning of non-trusted certificate on Opera browser .......................................153 Figure 104: Certificate of the user.......................................................................................153 Figure 105: Web server authenticates and authorizes the use to acces the web application ..154 Figure 106: Check of certificate with OCSP protocol over port 2561..................................154 Figure 107: Revoked certificate trying to connect ...............................................................155 Figure 108: Revoked certificate ..........................................................................................155 Figure 109: Non-authorized certificate................................................................................156 Figure 110: Access Forbidden - code 403 ...........................................................................156 Figure 111: PKCS Standards ..............................................................................................164 Figure 112: Image capture device .......................................................................................165 Figure 113: Geometry of the hand in 3D.............................................................................165 Figure 114: Face elements analyzed....................................................................................166 Figure 115: Voice analysis during password's pronunciation ..............................................167 Figure 116: Analysis process and SSA decision..................................................................168 Figure 117: Eye's cut ..........................................................................................................168 Figure 118: Different kind of iris ........................................................................................169 Figure 119: Iris analysis......................................................................................................169 Figure 120: Retina ..............................................................................................................170 Figure 121: Retina capture and analysis..............................................................................170 Figure 122: Tablet with pen reader .....................................................................................171 Figure 123: Sample processing ...........................................................................................171 Figure 124: Profile of the dynamics of a users touch...........................................................172 Figure 125: Profile parameters that can be modified in the smartcard..................................200

Page 11: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 11/204

Summary management During the education of Network and Services delivered in the "Haute Ecole d'Ingénieurs et de Gestion (HEIG-VD)", it is asked to the student to realize a personal study of a technical and scientific problem. The student receives a project scope that precise a well determined task. 2

Goals

The thesis has been done within a society based in Milan. This enterprise develops and dispatches systems for its own clients, which are financial institutions. The will of this venture is to study the building of an infrastructure PKI in order to guarantee a stronger security in authenticating users. The goal of this thesis is to study the problematic of PKI and to build an infrastructure PKI in an environment dealing with an online trading system. After having studied the concepts of security, authentication and PKI, the major goal was to build an architecture that will introduce certificate management. The aim was to deliver a product that could be part of the global environment of the enterprise. This document is divided in three distinguished parts: • "Theoretic part" has for objective to explain the principle of security and particularly of

authentication. This part sets the bases of the work in presenting a synthesis of every studied lecture, in order to assimilate a satisfying knowledge about the mechanisms that will be elaborated in the practice part. This section does not affirm that one of different authentication solutions is the best. The idea is to collect and present the largest view on the different available solutions on the market. After this, the public key infrastructure (PKI) will be explained in details and the final choices about the elements that will compose this PKI will be argued.

• "Experimental part" explains with details every steps of the configuration and the

installation of the PKI in order to be useful to anyone wanting to build a PKI based on OpenCA. This part is important in order to understand the implementation choices. This section also explains the mechanisms of the PKI and the necessary procedures to the good management of the PKI. Organizational and logistical aspects have been defined in order to set a policy of the PKI, useful for the future administrators of this structure.

• "Building and realization part" describes the tests that have been done on the built PKI.

Once the PKI was operational, some functionalities have been added in order to explore other possibilities. In this sense certificate validity checking has been tested through different manners; the web server checking its local CRL3 or, the web server making an OCSP4 request to a VA5. Some management tools as bash scripts or logs’ management have

2 Guiding rules of the thesis, in the section 1.2 of "Généralités" 3 Certificate Revocation List 4 Online Certificate Status Protocol 5 Validation Authority

Page 12: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 12/204

also been added in order to enhance the product. A biometrical application has been built and tested. In this case, a client could access the web application only after having been authenticated in a strong way. Indeed, this tool requires that the user delivers a certificate and his fingerprint. If it succeeds, the user will be authorized to access. Then a test-bench has been done in order to understand the behavior of the system.

Results and state The major goal has been successfully reached in the sense that the PKI built can be used in the actual state. Indeed, the management of the certificates is good and the web application can authenticate a user or not with the certificate that the latter presents. Biometrical authentication can be used by the enterprise if necessary. Some investigations and enhancement can be done on some parameters. For example, the certificate validity check thanks to OCSP hasn't delivered satisfying results and is still not in function.

Page 13: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 13/204

Thanks For this project, I would like to sincerely thank: M. Ventura, for his strong availability and for the direction that he has transmitted to the project. M. Spagnolini, for his overview of the global problematic that has allowed to follow precise objectives. M. Maret from e-Xpert Solutions, for the technical support regarding PKI, biometrics (MOC)6 and OCSP. M. Petracchi, for his precious know-how in Linux environment.

6 Notion is detailed in the chapter 21.1 Match On Card

Page 14: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 14/204

Introduction Nowadays, the term “security” is becoming more and more important. Many years have passed since the development of the Internet which has allowed developing as much over the last few years. We can particularly notice this evolution by the vast progress in computing science. Indeed, this is a very powerful tool, which enables us at any moment, to communicate with a person or a service, in order to exchange information, more or less sensitive. Thanks to this tool, people can execute financial deals, online purchases, phone conversations, etc. The primary goal is to simplify our lives, but we must not forget that all of these operations carry huge risks especially if some private information were to be stolen. The growing success of telecommunication, in terms of volume and variety, implies the need to ensure the identity of any person who wants to use an application. The interests are mostly economical, which strongly motivate hackers to attempt to compromise vulnerable security systems. A very large diversity of authentication systems exists nowadays to help guarantee the identity of a person. Those systems are based on their reliability and their difficulty to be attacked. The goal of this thesis was to study every possibility existing over the market, in introducing strong authentication mechanisms. After this, the interest was to analyze the feasibility of building such a structure like a PKI, in terms of integration in the actual infrastructure. The project has been done in a spirit of introducing an infrastructure in IT Software’s environment. Thus, the product should answer some wishes of the enterprise in order to be considered in a feasible way. Costs or the fact that the product should be able to evolve were fundamentals aspects in order to have a vision of a solid project. These aspects have brought to use a Linux distribution. The latter allows to reduce the costs in using free software and to build a private PKI. The latter means that it will be configured from the beginning and it would take some time to reach the level of efficiency of a commercial PKI, but this is also an aspect that is interesting. Indeed, the platform can be modified and then enhanced at will, according to the needs that will perhaps not been defined at the end of this project but that can appear later. Without entering in details, which will be presented later in this document, the infrastructure that will be built will mix a certification authority (IT Software) and users owning a certificate issued by this same authority. These elements will continue to work together on the same application but with an additional parameter, which are the certificates. Indeed, after the introduction of the PKI, the company and its clients will work with a bigger transparency. A relation of trust between the components will be introduced thanks to the PKI.

Page 15: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 15/204

Plan The goal of this part is to resume the report's content. The document is divided in three parts which are "theory", "practice" and "building and realization". The whole document follows a logical evolution, based on an important theoretic survey of different technologies currently used. It was undertaken, in order to have the maximum knowledge, in this domain, to do the practice application in a more effective way. The "theory" part has been written during the pre-project of diploma, except a few new sub-chapters. Theory: • First three chapters introduce basics elements of cryptography and authentication in its

totality. It was essential to understand the base of this study in order to have a good comprehension of the technologies that will be analysed. A large choice of different technologies which perform authentication will be presented.

• Fourth chapter will explain in detail the PKI infrastructure, the technology that will be

executed in the practice part of the diploma. Different elements that are part of the PKI and the essential respective points will be detailed.

• Fifth chapter will talk about another authentication mechanism, which is biometry. This

method, which is currently undergoing a growing success, could be used as an alternative of PKI or rather, as a complement in order to reinforce a system's reliability. Fingerprint process that has been used in the project is detailed. Different processes that permit to realize a biometry authentication, that are present on the market, are presented in Annex 2 – Biometrics, other solutions.

• Chapter six and seven will first explain an actual demonstration case. Then, an architectural

thought solution for the project will be demonstrated. Eighth chapter will present the different possibilities for the implementation of the proposed solution while chapter nine describes the final choices that have been taken.

Practice: • Chapter ten described, with an important level of detail, the steps that have been done in

order to install and configure the software in a correct way. • Eleventh chapter will introduce some important aspects regarding the logistics of the

project. These are fundamental points in order to develop the solution in the best environment possible.

• Chapter twelve to fifteen depends on OpenCA software. A brief explanation of the

software’s structure is written. Then, the management of the certificates though the two most important processes, which are request and revocation of certificates, will be explained

Page 16: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 16/204

in this part. A short section showing the generation of web server certificate and its signing by the CA is also described.

• Chapter sixteen details the different existing file formats generated by the PKI and the

language on which they are based. Chapter seventeen explains the notion of interoperability in the context of the project, what are the real possibilities with the used software.

Building and realization: • Chapter eighteen explains the different solutions for the web server, to check the validity of

the presented certificate. • Nineteenth and twentieth chapters show the work made to better manage the entire

environment. This handles management of logs, bash scripting or even databases management.

• Chapter twenty-one details the building of a working structure introducing biometrics

authentication in the standard process. Indeed, in addition of the normal procedure, the user will have to be authenticated thanks to his fingerprint.

• Chapter twenty-two describes the behavior of the structure depending on the certificate that

are presented. Some analysis, based on the network sniffer Wireshark, demonstrate in details the reaction of the web server in function of the certificates.

• Chapter twenty-three shows the planning that has been followed during the project. Last two

chapters summarize the status of the project, the goals that have been reached and the possible enhancements that could be done in the future.

Page 17: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 17/204

< THEORY >

Page 18: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 18/204

1. Security notions Everyone knows the importance of computer security nowadays. Indeed, with the growth of communication via our computers, more and more areas and applications which are more or less sensitive, can be attacked by malicious software. Particularly, we think about elements like financial deals or other kinds of personal information that people just don't want to expose to anybody. To achieve a satisfying level of security, it is very important to pay attention to the following simple rules: ٠ The security of a system of information is like a chain, it is only as strong as the weakest

link of this chain. Efforts will be focused on the most sensitive elements. To achieve this, the security perimeter has to be well defined by considering the totality of the elements that are part of the system.

٠ An absolute security without any risks is simply impossible. There is always a possible risk

(human, natural, etc.). That is the reason why a compromise has to be found between the elements that have to be secured and the factors that are more difficult to manage.

٠ Security is not a product but a process. One must keep in mind that risks will evolve in time.

To try and contain those risks, it is necessary to survey, maintain and revisit the security system regularly.

٠ A security system is generally inverted proportionally to the complexity of the functionalities

that are possible. One must try, if it is possible, to create the most simple system possible. Indeed, the more there are possible functions, the greater the threat of exposure.7

7 [Cours Sécurité des Systèmes d’Information – M.Buchs]

Page 19: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 19/204

2. Cryptography Cryptography is the science of writing and reading of coded messages. It already exists since Antiquity. However nowadays, the mechanisms used can very easily be hacked. That's the reason why this science has had such a long and rapid evolution, bringing technologies more and more difficult to attack and thus, offering a greater security. Cryptography has to ensure some essentials points, which guarantee the level of security of the system: ٠ Authentication is the procedure that allows to verify the identity of a person in order to

authorize the access of this person to an application or service. The authentication allows then validating the authenticity of the person who wants to access the service.

٠ Data integrity is the state of data that suffers any alteration, modification, voluntary or

accidentally destruction. ٠ Confidentiality is defined by the International Organization for Standardization (ISO) as

the fact to make sure that information is only accessible for people who are authorized to access it.

٠ Non-repudiation is the concept of ensuring that a contract cannot later be denied by

either of the parties involved.

2.1 Symmetric key encryption

Symmetric key encryption, also called private-key cryptography, carries out a similar key and also a similar encryption algorithm in order to encrypt and decrypt a message. The problem with this kind of mechanism is that the key has to be absolutely confidential. To reach this, the key has to be transmitted to the parties in a safe way. A secure canal (VPN for example), that needs another key, can be imagined. The solution requires more and more keys and it becomes a difficulty. Another problem of the symmetric key encryption is that a key is necessary for any communication. Thus, in a situation where a lot of people want to communicate between them, a lot of keys will be needed to link every user between them. Concretely, for n users wanting to communicate with every other users of the network, a total

number of ( 1)

2

n n⋅ − will be necessary. It can be easy to notice that the sum of the needed keys

will become very huge in the case of the user network, which will be composed of an increasing number of users.

Page 20: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 20/204

Figure 1: Symmetric encryption (Source: http://www.devshed.com/c/a/Security/Basic-Concepts-of-Web-Services-Security/4/)

It can be imagined that both partners can exchange the same symmetric key in a precedent conversation that can take the form of an email, a phone call, a fax, etc. Here is some encryption algorithms that use symmetric encryption: ٠ DES ٠ 3DES ٠ AES ٠ IDEA The most significant particularity of all of these algorithms is that the size of their key is different. The more the size of the key is big, the larger the encoded message will be harder to decrypt. The advantages of those algorithms are the rapidity in which data can be exchanged. Big data volumes can be exchanged with this kind of method. Besides other problems, this technique has some disadvantages like the fact there must be a relation of confidence between the two parties because there is no authentication of the origin.

2.1.1 Diffie-Hellman The keys distribution has been a problem for long time. That is the reason why an algorithm has been found in order to make the exchange feasible and trustworthy. This algorithm is named after its creators, Diffie-Hellman. It allows the parties to exchange the keys without possessing a shared secret. Here is an example of the process of Diffie-Hellman.

Figure 2: Diffie-Hellman Algorithm

(Source: http://en.wikipedia.org/wiki/Diffie-Hellman)

Page 21: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 21/204

In spite of this solution, although it seems interesting, it can suffer from a man in the middle attack (MITM)8, and thus, does not guarantee a sufficient reliability.

2.2 Asymmetric key encryption

The asymmetric key encryption has another mechanism. The key that allows the encrypting of a document and the one, which decrypts the latter, are different. Each user owns a pair of keys (private and public). A user to decrypt a document that he has received by another person or to sign a document that will be sent to another user uses the private key. The public key allows to authenticate the signature of a document or to send an encoded message to a partner. The key management is consequently less critical as apposed to what is suggested by a symmetric key algorithm. Indeed, in a similar situation, there is absolutely no shared secret between the sender and the receiver. The private key is directly linked to a person in such a way that the authentication of the origin becomes possible.

8 This element will be presented in chapter 2.5 "Man in the middle" attack (MITM)

Page 22: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 22/204

Figure 3: Asymmetric key encryption (Source: http://en.wikipedia.org/wiki/Public-key_cryptography)

The public key exchange can be made in a number of different ways between the two partners (phone call, fax, email, etc.). This technology brings a bit more security. Indeed, the aspect of authentication is greater as the sender can be authenticated. The asymmetry also gives the fact of non-repudiation, which is very essential in terms of security. On the other hand, its slowness and its incapacity to encrypt big volumes of data is its disadvantage which is not negligible. The choice of which technique to use will depend of the needs of the system. Either the security or the efficiency in terms of volume and rapidity will be the fundamental points. This system is based on a function (hash function) easy to calculate in a way and mathematically very difficult to invert without the private key. That is the description for a one-way function. The major algorithm that uses this solution is RSA and this algorithm has a large success nowadays.

2.3 Hybrid encryption Symmetric key encryption algorithms are more reliable but asymmetric key algorithms are able to erase the problems due to the exchange on an encrypted canal. Hybrid encryption is a solution that provides a solution that combines symmetric key encryption and asymmetric key

Page 23: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 23/204

encryption. This method is interesting because it takes the advantages of both different mechanisms. This system uses, for example, a shared session key in order to begin a symmetric key encryption. A session key will be randomly generated and its size will be large enough. Then, the sender will encrypt this session key by using the receiver's public key. Finally, the receiver will decrypt the session key with its own private key. In doing this, both partners can share messages with a symmetric key and another asymmetric key.

Figure 4: Hybrid encryption

(Source: http://www.commentcamarche.net/crypto/cledesession.php3) Here are some solutions that use the hybrid encryption concept: ٠ SSL ٠ PGP ٠ IPsec using Diffie-Hellman or RSA

2.4 Hash function

A hash function receives a random length message and produces a fixed length code. Some criteria are elementary for a hash function: ٠ Coherence – A same incoming message has to produce the same outgoing code. ٠ Random – Useful in order to avoid the discovery of the message of origin. ٠ Unique – Two different messages must never produce the same outgoing code. ٠ Irreversible – It has to be impossible or extremely hard to understand a message only in

having a message's code. That is why this function is a one-way function. A hash function is unique and proves integrity and authenticity of the message. However, this method is rather risky because it can be attacked by "man in the middle attack" or most commonly called MITM9. To improve its security, it is possible to combine a hash function with an asymmetric key encryption. 9 This element will be presented in chapter 2.5 "Man in the middle" attack (MITM)

Green key: session key Yellow key: public key

Red key: private key

Session key

Page 24: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 24/204

Here are some of the most popular hash functions: ٠ MD4 ٠ MD5 ٠ SHA-1

2.5 "Man in the middle" attack (MITM)

Some of these solutions don’t bring enough security. In fact, how can we be sure that we are communicating with the right person? The MITM attack is used by a hacker that wants to listen to a communication between two users. By listening to them, he is able to capture the keys exchanged between the two parties. At that moment, the attacker can participate in the communication as if he was one of the parties, and falsify the messages. The damage of this kind of attack can be very substantial.

Figure 5: Man in the middle attack (Source: http://www.e.govt.nz/services/authentication/library/docs/authentication-bpf/chapter5.html)

A solution to avoid this problem could be to introduce a trusted third party10 in the communication in which both partners could trust. This third party, who has the task to be neutral, would distribute keys to the partners.

10 This element will be presented in chapter 2.6 Trusted third party and will also be mentioned in the chapter 4. PKI (Public Key Infrastructure) where this process is used.

Page 25: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 25/204

2.6 Trusted third party

A trusted third party is an entity which is given a private key upon meeting certain conditions concerning the system. This option is used in the case of the loss of a private key or also when the system, where the key is stored, has suffered a problem. In a political view, some governments would be very interested in having such a system for the purpose of supervision. However, imagine that some trusted parts that have large quantities of private keys could have access to commercial deals, financial deals, etc. A large mass of money could be stored in some strategic points. If someone knew these points, it could be very easy for a hacker to know where to attack in order to obtain the information. For an enterprise, the fact to use such an element would make it risky to have private keys of its own employees stolen. Thus, an enterprise should store its own private keys internally, without asking an authority to keep them.

2.6.1 Captcha Nowadays, a lot of attacks on informational systems are done by robots (the used term is bots). Captcha mechanisms, tries to avoid the possibility of attacks by these bots by challenging them. The concept is rather simple and more and more Internet sites use this method. The process of the system is to send a visual, sound or other type of request that is almost impossible to resolve for a bot, but in contrast, it is very easy for a human.

Figure 6: Example of a captcha request (Source: http://www.captcha.net/)

This system is used to fight against spams, database extraction, brute force attacks, etc. It is not an authentication system but it can be an additional barrier that people can introduce in the system of an enterprise, in order to avoid the pre-cited problems.

2.6.2 Others precautions Some others precautions should be taken in order to be sure that the system has a satisfying degree of security. A first point is to classify different resources by grouping them by their sensitivity. Employees also have to be classified by their roles and function in the enterprise.

Page 26: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 26/204

Secondly, it is necessary to physically separate some zones from each other, also by their sensitivity. The access to some zones has to be checked in order to avoid that an intruder could access any kind of information that he normally shouldn’t have the right. It can be imagined to lock an area if the zone is extremely sensitive or if the number of people that have the rights to access it is limited. Finally, it shouldn’t be forgotten to protect zones by natural disasters. A work area that is located in the basement has a greater probability to suffer of water flooding than one that is on the third floor. Fire can also be a kind of disaster to prevent.

Page 27: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 27/204

3. Authentication As previously mentioned, authentication is the procedure that allows to check the identity of a person, in order to authorize access to a user to specific resources. Thus, authentication permits to validate the authenticity of the asked person. This mechanism is introduced immediately after identification (who are you?). It is a kind of identification proof (prove it!). Authentication is used in some case like access control, non-repudiation, integrity and data confidentiality. Different kinds of techniques are possible to check the identity of a user: ٠ What the user knows (password, PIN code, etc.) ٠ What the user owns (smartcard, electronic certificate, OTP Token (OTP = One Time

Password), OTP Card, etc.) ٠ What the user is (biometric (fingerprint, retina, face, voice, etc.)) ٠ What the user knows how to do (movement, signature, etc.)

3.1 Simple authentication vs. strong authentication A simple authentication system is a system that asks the user, who wants to use the application, only one kind of authentication. For example, an application that would ask the user only a login and a password, in order that this person could interact with the service, is a simple authentication system. The problem with this solution is that it is vulnerable. Indeed, the hacker only has to focus on this unique element and if it is not well protected, the attacker can introduce himself, without any difficulties in the system even though he has no access rights. A strong authentication system is an enhanced simple authentication. Indeed, a strong authentication asks the user at least two kinds of authentication or more. For example, after having introduced the password, the user would also have to give their fingerprint to have sufficient rights to access the application. The fact to add at least one authentication element makes the hacker's task more difficult to enter into the system. Indeed, knowing only a password in relation with a login is not very useful, in this case. A study from RSA Security, done in 2005, was done in order to show the difficulty to manage passwords and also the potential risks for the enterprise's safety. On an average, it was calculated that between the asked users, more than ten passwords had to be memorized, that was an important number. Facing this quantity of passwords to remember, a frustrated user will perhaps choose more simple passwords, and in so doing putting its enterprise in a position to be attacked more easily. That is the reason why nowadays, a system based only on login and password is no longer more satisfactory, that is why it is important to introduce powerful authentication in the system.

Page 28: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 28/204

3.2 Strong authentication

As it has been shown before, strong authentication is a mixing of at least two simple authentication elements. Currently, most systems are managed with simple authentication. To be more specific, between 95% and 98% of authentication systems are based only on the login and password system for authenticating a person. As it is known, that is very easy to crack a password by using different kind of attacks, such as the following: ٠ Brute force attack: This attack can be done in trying the whole character possibilities (a,

b, c, …, aa, ab, ac, …). This is a process that is executed by the hacker and that calculates these possibilities extremely quickly. This solution will be a success if the password is not too long.

٠ Dictionary attack: This method is based on language dictionaries and also on dictionaries

that contains the most popular passwords. If target passwords are in one of those dictionaries, the hacker will need only a few seconds to find it.

٠ Hybrid attack: This kind of attack is based on the two precedent techniques. It mixes

brute force attack and dictionary attack to achieve the goal. ٠ Keylogger: This technique is possible thanks to the setting of a spyware (backdoor) that

has the particularity to save the keys that have been hit on the keyboard. Once the backdoor is installed, the hacker will have access whenever he wants to the target and would be able to steal user passwords'. That is the reason why in some applications, the keyboard is represented on the screen and the user can click with the mouth to enter its password.

٠ Sniffer: It is a software that has the faculty to listen and to take transiting packets to a

local network. In this case, sensitive data is what is exchanged with non-encrypted protocols like HTTP, Telnet or FTP for example. A good solution to fight against this weakness is to use a network protocol that is encrypted like SSL, TLS or also SSH.

٠ Phishing: The mechanism used here by the hacker is to let the target person think he is

communicating with a trusted third party but in reality, this person is actually dealing with a hacker. This method is used a lot in the banking domain where the attacker try’s to take personal information like passwords, credit card numbers or others as its target. This process is based on social engineering, which is a method that allows obtaining information by exploiting the trust and gullibility of the target.

٠ Man in the middle attack: This attack, which has been explained before, is based on the

fact that the hacker will lets the target think that he is another one, a person in whom the target has trust. When the false relation is established, the hacker can share information with its target and steal whatever he wants.

A simple authentication system then does not offer enough security for a system that holds highly confidential information (bank, insurance, etc.). That is the reason why strong authentication has taken such importance. Indeed, this technique is more efficient for the

Page 29: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 29/204

safety of the system. Here is a schema that shows some authentication solutions that could be added to a simple authentication system based on a login and a password, for example.

Figure 7: Different kind of strong authentication solutions (Source: http://fr.wikipedia.org/wiki/Authentification_forte)

Moreover, strong authentication is a concept that allows one to guarantee some extremely essential points like: ٠ Authorization or access control (who can access it?) ٠ Confidentiality (who can see it?) ٠ Integrity (who can modify it?) ٠ Traceability (who has done it?) These aspects can be shown as a model with the help of a schema that shows well the steps of strong authentication.

Page 30: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 30/204

Figure 8: Strong authentication pyramid

(Source: http://fr.wikipedia.org/wiki/Authentification_forte)

The list of different possibilities to do a strong authentication system is large. Moreover, it is also possible to mix some different technologies in order to make the work more and more difficult for a hacker.

3.2.1 One time Password (OTP) This mechanism is almost primary. The goal is to assign a password to a user. This password will be useful only for one session. To achieve a satisfying security levels, an encrypted information exchange system has to be created, in order that the password attribution is kept secret. The problem of this kind of method is that non-repudiation is not guaranteed.

3.2.2 Token A token is another authentication approach. There are different kinds of tokens like the One Time Password (OTP), the PKI type or the hybrid one. The OTP type token is based on a unique shared secret and it is the token that keeps this secret. Authentication servers own the same secret. Thanks to those mathematical operations, like common denominator, it is possible to generate passwords in only a one-way direction.

3.2.2.1 Passive token Passive token authentication is the simple fact to share a unique fixed secret. The authentications can be based on a password, a magnetic card or others. This solution is not

Trace- ability

Integrity

Confidentiality

Authorization

Strong authentication

Who has done it ?

Who can modify it ?

Who can see it ?

Who can access?

Who's who ?

Page 31: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 31/204

very efficient because of the risk of stealing the secret. It can also be vulnerable to replay attacks. This kind of attack is possible when the secret is fixed. For example, if Alice is telling Bob her secret and that Charly has heard the subject of the communication, Charly will be able to convince Bob that he is actually Alice.

Figure 9: Passive token (Source: Sécurité des systèmes d'information – Course book of M.Buchs)

3.2.2.2 Time-based token (OTP type)

Figure 10: Time token (Source: http://fr.wikipedia.org/wiki/Authentification_forte)

3.2.2.3 Counter token (OTP type)

Figure 11: Counter token

In this system, the common denominator is time. The token and also the authentication server are synchronized on this common denominator. This is a synchronizing technology because at every "x" time, a new code is generated, that is why it is called One Time Password. A PIN code can also be used as a second authentication factor.

In this second OTP solution, the concept is very similar to the time-based token. This is also a synchronizing system. The only difference is in the fact that the common denominator is realized by a counter.

Page 32: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 32/204

(Source: http://fr.wikipedia.org/wiki/Authentification_forte)

3.2.2.4 Smartcard token (PKI type)

Figure 12: Smartcard (Source: http://www.hsbc.com.br/common/seguranca

/artigo-seguranca-criptografia-autenticada.shtml)

3.2.2.5 USB token (PKI type) This kind of token has the same mechanism of cryptography that can be found in a smart card. This kind of authentication is called "connected" because it needs to be plugged in to the USB port device. The USB token allows the generating of keys and stores the private key, at the same time.

Figure 13: USB token (Source: http://fr.wikipedia.org/wiki/Authentification_forte)

3.2.3 CAP (Chip Authentication Program) The Chip Authentication Program or CAP is a process of authentication, thought by MasterCard and Visa, which uses EMV11 banking smartcards to authenticate users and transactions in online and telephone banking. This technique has initially been specified for bank use but the process can be easily extended to other authentication process, like access to a website for example.

11 Standard for interoperation of Chip cards and Points of Sales, for authenticating credit and debit card payments

A smart card can have some different utilities. This kind of mechanism is well known in banking systems (when you go and take some money) or also SIM cards that we can find in every mobile phone. This technology uses the approach that, the users wanting to authenticate, can do so by what they own. The chip is composed of a crypto processor that allows key generation and storing of the private key. In this precise case, a PKI based technology is used. The portability of such a system is not perfect because smart card drivers have to be installed on every host.

This solution is then somewhat interesting. However, there is the inconvenience of not being very portable concerning the system used. By comparing this technology to the smart card, USB interfaces are however more popular than card readers. This approach is based on "what the user owns" authentication.

Page 33: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 33/204

Figure 14: Chip Authentication Program (Source: http://www.cc.com.pl/img/vasco/800photo.jpg)

CAP technique describes a reader with a smartcard slot, a decimal keypad and a display. The owner of a reader can insert his Chip and PIN card into the reader in order to be authenticated. Thus, this is a two-factor authentication because both smartcard and valid PIN must be introduced in the reader in order to succeed. There are several kinds of authentication methods with CAP. The user introduces the smartcard in the reader and has to enter the correct PIN code to enable the smartcard. Then, three options are possible and the user can chose it in pushing a specific button for each option:

- Identify: The CAP reader interacts with the smartcard and generates a decimal one-time password, which can be used to log into a website.

- Response: This mode implements a challenge-response authentication. Indeed, in this case, the website asks the user to enter a challenge number into the CAP reader. A response will then be automatically generated and the user will have to enter it into the website.

- Sign: This is an extension of the precedent mechanism in the sense that additional information regarding a fixed detail (transferred value, currency, etc.) has to be entered in the reader.12

The use of this kind of technology allows to avoid some risks that are serious in the financial world. Indeed, the generation of a one-time password makes phishing attacks impossible. Moreover, the fact that the user has to enter a PIN code using a separate reader takes off the possibility to intercept data. This kind of process can fully be introduced in a context less linked to banking payment. Indeed, such a mechanism can be used in order to authenticate a person in order to authorize him or not to access an application.

12 http://en.wikipedia.org/wiki/Chip_Authentication_Program

Page 34: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 34/204

3.2.4 CHAP (Challenge Handshake Authentication Protocol) CHAP protocol is used to authenticate users, by using a technique based on the resolution of a model, called challenge-answer. This is a protocol that checks periodically the identity of a user by introducing a three-way dialogue called "three-way handshake". This three-way handshake is composed of: º Challenge º Response º Success or Failure The CHAP dialogue is established when the connection is started but can also be repeated whenever the authentication server wants it, with the help of a random timer for example. Both parts (administrator and user) will generate an encrypted sequence and the administrator will compare both sequences in order to check if the user is reliable. Some different steps are necessary to make this authentication method more successful: ٠ A random number of 16 bits is sent to the client from the authentication server, and also a

counter that will increment itself at ever time something is sent. ٠ The client will then hash this number, the counter and its private key. Just for information

purposes, the algorithm that is used in this case is the MD5. Once this operation has been done, the client will give the result to the authentication server.

٠ Authentication server will compare the received results with the same operation that it has

done itself, with the help of the same random number and the key associated to the client. ٠ If both results are equivalent, the client is authenticated with success. ٠ At random time intervals, authentication server will resend some new challenges. The whole

process is repeated in order to authenticate the client. One of the advantages of this method is that the risk of attack is reduced by regularly changing the counter's value. By doing this, the attacker has very little time before a new challenge arrives. Moreover, the known secret between the two partners no longer has to be exchanged on the network, which reduces greatly the risk of stealing. The major disadvantage is that this solution is very difficult to insert in an organization that is composed of a lot of hosts. The secret that is known uniquely between two elements would be difficult to manage. It can be noticed that it is the same inconvenience that can be found with the shared key system, also called symmetric key encryption.13

13 RFC 1994 - CHAP

Page 35: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 35/204

3.2.5 AAA protocols As seen before, the use of CHAP authentication is possible for a peer to peer relation, between two individual hosts. However, when the number of users increases (in a structure like an enterprise for example), another approach has to be considered. An AAA type protocol can be taken in consideration, in that case. This term is given to protocols that do three functions: Authentication, Authorization and Accounting (AAA). Protocols like RADIUS, TACACS+ (Cisco) or DIAMETER are AAA type. For example, RADIUS is a protocol that allows linking the needs of an authentication with a users database. The client will start its authentication while the authentication server will deal this request by accessing a SQL database, a LDAP directory or others. To be more precise, the client will generate an authentication request that holds all necessary information for its authentication. RADIUS authentication server will manage the request only if it has all the requested information. If it is not the case, the server will ask the client for additional information (CHAP protocol can be used in that case). This exchanging mechanism between the client and the server will last until the server is in possession of every necessary element to authenticate the client. Once the server has all information it needs, it can authorize or reject the client. Authentication That is the process that allows checking the identity of a person in order to authorize the access to this client to some resources. Authentication allows validating the authenticity of a person. Authorization In this part, some elements, which depend on a user, are added to authentication in order to avoid abuse. Often, it can be executed with some restrictions like for example time, used IP address to register or also a limited number of logins by the user. Accounting This option insures the writing of every access that has been done to the system. In RADIUS protocol, for simple reasons of safety, the transactions between client and server are authenticated thanks to a shared secret password that has never been exchanged on the network. Another interesting aspect of this type of protocol is that every sent password, between the client and the server, are encrypted to avoid any risk of stolen packets with the help of a network sniffer.

Page 36: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 36/204

3.2.6 PGP (hybrid encryption) PGP (Pretty Good Privacy) is a cryptosystem or an encryption system that uses symmetric key encryption but also asymmetric key encryption. This is thus a hybrid cryptography mechanism that, thanks to the advantages of rapidity and reliability, makes this technology almost impossible to analyze. This software was created in 1991. It was a period where there were restrictions on cryptographic product exportation. Its creator, Philip Zimmerman, understood the importance of exchanged data security and had the vision to realize a system that would allows sharing information in a more reliable and secured way. Here is the process of this interesting method that is composed of two distinguished phases: the PGP encryption and the PGP decryption. At the beginning, the sender is going to encrypt a message with a receiver's public key. Then, a calculated symmetric key will be used in order to encrypt the message already encrypted on the receiver's public key. There are two different steps of encryption in the PGP process, as the following schema demonstrates.

Figure 15: PGP encryption (Source: http://jaspal.wordpress.com/tag/tech-info/)

To decrypt the whole message, the receiver will have to be in possession of the symmetric key (that is normally only known by both partners) and its own private key (that the receiver is the only one to know it). With the symmetric key, the receiver could open the first barrier and then, to complete the phase of decryption, the receiver would have to use its private key. As the following schema demonstrates this, two operations are then essentials to read the original message.

Page 37: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 37/204

Figure 16: PGP decryption

(Source: http://jaspal.wordpress.com/tag/tech-info/) Thus, this technology allows unifying the advantages of symmetric and asymmetric key encryption. These assets are the rapidity of the symmetry and the reliability of the asymmetry. Then, it can be noted that this solution is based on hybrid encryption14.

3.2.7 Kerberos Kerberos authentication protocol allows the trust of a third party element. Indeed, to avoid some kinds of attacks, as the "man in the middle attack" for example, some authentication solutions use a trusted third party to enhance the level of security. This protocol uses DES algorithm for encryption and authentication. Kerberos has been developed in order to authenticate users' requests that want to enter the network or the application. This technology is thus based on the trusted third party concept15. This element of trust will manage the relation between two services that want to communicate. The third party is also called distribution centre or KDC and takes the authentication server role. Its task is to check the real identity of different users and services.

3.2.7.1 Protocol Kerberos mechanisms The working of this protocol is pretty different from other technologies. The Kerberos server will send tickets to users, instead of using clear text passwords. This system allows reinforcing the security by excluding intrusions by people illegally that could have stolen a password. Those tickets are limited in time and are stored in the cache of users' computer. Then, they can be used at that point and thus avoids using a traditional authentication system. º The client owns an encrypted key, only known by the client and the KDC. This private key

will take the name of CK .

º Every server also owns an encrypted private key that is called SK .

14 This kind of technique has already been explained in chapter 2.3 Hybrid encryption 15 Element that has been presented in chapter 2.6 Trusted third party

Page 38: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 38/204

º KDC knows about CK and TGSK private keys.

º Ticket server (TGS – Ticket Granting Service) owns a private key named TGSK and also

knows SK private key.

To start a communication with an application server, the client will firstly send an authentication request to the KDC (1). After checking the client's access rights, the KDC will send back the client an authentication answer that is composed of a tgt ticket (useful to

communicate with tickets server) with a session key called SessionK (2). All this information is

sent and is thus encrypted with CK client's private key. SessionK key will also be useful to

communicate with the tickets server. The second step is to ask a ticket from the TGS ticket server (3). This request holds

information, about the client, that is encrypted with the SessionK session key. The client also

has to send the tgt ticket, which the KDC has sent to the client previously, in order to be identified by the ticket server. The ticket server will then check the identity and the access rights of this client and if is reliable, the ticket server will send another ticket back that will allow the client to access the desired application on the server (4). The third phase is the communication between the client and the application server. The client has received a ticket to access the wanted server but also a session key that allows the user to be identified more formally. These two elements will be sent to the application server (5) and it will check the validity and the access rights of that client. If everything is correct, the client will be authorized to access the application server (6).

Figure 17: Kerberos mechanisms (Source: http://www.zeroshell.net/eng/kerberos/Kerberos-operation/)

1

2

3

4

5

6

Page 39: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 39/204

An interesting point of view is that different tickets given to the client have only a limited time of life (a few hours, generally), which reduces the possibility to steal tickets. Nevertheless, if a stealing were executed, the hacker would not have a lot of time to find the other necessary elements to be a non authorized authenticated person. Moreover, a client's IP address is stored in the ticket, so the server can check that, this address when the client sends a request. An additional barrier is then placed for the hacker who will have to spoof the client's IP address to let it think the server that he is actually the client. Kerberos safety is built on the security of every single element. Every component has to be absolutely secured in a satisfying way. If the TGS key server was attacked with success, a hacker could receive private keys from clients and let the servers think that he is one of them. One of the most interesting advantages of Kerberos is that it allows one to work on a non-secured network. However, they’re some other weakness’ present in the security of the system. For example, an honest or dishonest user could have the possibility to reproduce the same attack as many times as he wants, as long as the ticket is valid. The ticket could be stolen after having been used by an honest user and still be usable by the hacker. This protocol can also be attacked by the betting on the password method. This technique is based on collecting tickets that are exchanged and trying to decrypt them. Moreover, the most troubling aspect is that the origin of the whole security system is based on a software program. If someone goes into the software and succeeds in introducing a malware, it would not surely be detected, and this could have very disastrous consequences.

3.2.7.2 PKINIT PKINIT is an extension of Kerberos protocol that allows using the concept of PKI for the user's authentication. PKINIT permits the PKI infrastructure to interact with the Kerberos protocol. Because it is an extension, it does not modify the standard Kerberos process. However, it is the authentication mechanism that is a little different. It is possible to use this system with a smart card or an USB key in a Windows environment; this reduces its power of diversity. In this case, the system is called Microsoft Smart Card Logon.

3.2.8 TLS (SSL) – HTTPS Transport Layer Security (TLS), which is an evolution of Secure Socket Layer (SSL, made by Netscape) is a protocol that works on the application layer (layer seven) of the OSI model. The primary goal of TLS Protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. TLS Record Protocol has two basic properties:

- The connection is private - The connection is reliable.

Page 40: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 40/204

TLS Handshake Protocol has three basic properties: - The peer’s identity can be authenticated using asymmetric or public key, cryptography. - The negotiation of a shared secret is secure - The negotiation is reliable

The goals of TLS Protocol, in order of their priority, are as follows:

1. Cryptographic security: TLS should be used to establish a secure connection between two parties.

2. Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another's code.

3. Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.

4. Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.16

TLS permits to authenticate the partners in guaranteeing confidentiality and data integrity over the Internet. Client and server will firstly negotiate the security parameters of TLS. After this, their certificates will be exchanged, in a secured way, in order to generate a common secret. This is useful for the keys extraction of the TLS session keys. TLS is always used as a reliable transport, like TCP. Indeed, applications that use it most commonly are HTTP, SMTP, etc. Moreover, the application that uses it generally is HTTP. When this application is associated to TLS, the protocol is called HTTPS. In this case, there is a unique certificate to the server such as the client can check the identity and the validity of the homepage he is trying to access thanks to an authentication certificate. Once this step has been done, the communication is encrypted and packets that are sent during the session will be secured and non-visible on the network. This technology can usually be found in financial or banking domain, where the client has to be sure that he is dealing with his own bank and not with a hacker. This protocol is then used when confidential data is exchanged.

16 RFC 4346 - TLS

Page 41: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 41/204

4. PKI (Public Key Infrastructure) A lot of security protocols are built on a public key cryptographic system to insure confidentiality, integrity, non-repudiation and authentication of the origin of data. A PKI is a group of physical elements, human procedures and software that allow providing a reliable and efficient keys and certificates management to support these protocols. These procedures are pretty numerous but they are very important to achieve the strategic goals to build.

4.1 PKI offered services A PKI delivers some services to users such as:

º Users registering º Certificates generation º Certificates renewing º Certificates revocation º Certificates publication º Revocation lists publication º Users identification and authentication º Saving and recovering

4.2 Elements making a PKI A PKI is composed of some elements like: º Certification Authority (CA), manages certificate attribution and revocation. º Registering Authority (RA), are used like an intermediate between users and the CA. º Validation Authority (VA), which can be optional. º Certificates owners for whom certificates are emitted and can sign digital

documents. º Clients that validate digital signatures. º Places where certificates, revocation lists or CRL (Certificate Revocation List) can

be stored or be used. A PKI allows a univocal authentication of public keys. The CA emits the certificate, which is a third party in whom the user can trust. That makes PKI very credible from the users' point of view.

Page 42: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 42/204

4.3 PKI functions º Registering: This is the first part of the process that the user has to execute in order to obtain

a certificate. Firstly, he will talk directly to the CA or to the RA intermediate. However, it is the CA that will have the task to emit user's certificate.

º Initialization: This is the step that allows the user to start a communication with a PKI. It

means that the user previously received all the necessary information that will permit him to interact with the PKI. This information is for example a certificate with a pair of public/private keys, which is in relation with only one user.

º Certification: When the CA emits a certificate for a public key and sends it to the interested

user. º Keys pair recovering: When the CA has generated and published a pair of keys, a user's

private key can be stored in the CA or in another independent system. If the user wants to recover information on this pair of keys, this last step has to be recoverable without taking too many risks of compromising the system.

º Keys generation: This process allows the generation of pairs of keys by the user or by the

CA. In the second case, keys can be transmitted to a user by different ways (encrypted file, smart card token, PCMCIA card, etc.).

º Keys updating: Every pair of keys has to be periodically updated. A new pair will take the

place of the old one. This renewing can be done because the certificate has expired or because there is a risk that, for some reason, the certificate could have been compromised.

º Co-certification: A certificate can be emitted by a CA for another CA. This technique is

commonly used to permit information exchange between two entities that are not administrated by the same authority.

º Revocation: When a certificate is emitted, it has some parameters like duration validity.

This certificate can normally be used during this period of validity. However, sometimes the administrator can decide to revoke a certificate and then, to make it obsolete. This revocation can be done for various reasons like a change of name, a status change (employee that leaves the enterprise), or on the suspicion that a private key has been compromised.

4.4 Keys management

A good key management is primary because the key is the most sensitive element of the entire system and if a key would be stolen, the damages could be enormous. That is the reason why the system should follow some rigorous rules. The most risky process is the keys exchange.

Page 43: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 43/204

Indeed, it is at this moment that the hacker has the most opportunities to steal the keys. Some operations are important to cover this keys management: ٠ Keys generation: As explained before, it is the first step of a PKI infrastructure. The keys

should be generated in a way that they cannot be discovered by dishonest users. To reach this goal, some algorithms are used to ensure this operation.

٠ Keys distribution: This part consists in the moving of an encrypted key. It has to be sure that

the exchange between two partners is encrypted thanks to another key, for example. Another solution could be to use an encrypted channel like SSL or TLS.

٠ Keys storing: The process of storing keys is also a sensitive point. It is obvious that this

mechanism has to be protected in order to guarantee the integrity of the key. ٠ Keys deleting: The key is deleted when it has reached the end of its period of life. Another

possibility, when a decision to delete a key is taken, it is because an administrator thinks that the confidentiality of the key is no longer assured.

٠ Keys archives: This step is done in order to keep a copy of every key (even the ones that

have been deleted) because these keys could be used to take information that these keys were originally designed to protect.

٠ Keys recovery: Recovery is a process that permits to find a client's lost private key. If an

employee leaves the enterprise, in a radical way, that is they do not have time to organise departure, it is important to find this private key to avoid a situation where the other employees could not access the work that the person who left has done. If it is the case, the work could be totally lost and it could cause a lot of damage to the enterprise. This step can only be done by an administrator because of the fact that the person who has access to do it can obtain anyone's private key.

4.5 Certification Authority (CA)

This is the authority of trust of the system. The CA has important roles like signing, emitting, renewing or revoking certificates to users. Another important task of the CA is the emission and maintenance of CRLs (Certificate Revocation List). The generated certificate holds some important information concerning the user like their name, their private key, lifespan of the certificate and the signature of the CA with the help of the private key of the CA. The CA is the most sensitive element of the PKI infrastructure. Indeed, its private key is the thing that has to be the most protected. Because if a hacker steals the CA's private key, he could lead the other users into thinking that he is the element of trust in the system and acts on behalf of the different users, as he likes. Thus, it would be safer to physically separate the CA from the RA and never connect the CA to the Internet to exchange information. This would avoid the loss of confidentiality and integrity risks. The best way to protect the CA would be

Page 44: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 44/204

to isolate it in a locked area. Then, only an administrator could access this room to exchange manually the information between the CA and the RA. The CA is also the area that will manage every kind of update that could be executed on a certificate. In this case, the CA will have to revoke the certificate in order to update it, before generating another one. Over all, the CA has to supply periodically a list of revoked certificates (CRL). The application servers will check if the user, wanting to access the application, does not own a revoked certificate. There are two ways of using a CA. Either, using a well-known public CA like Verisign, Microsoft, etc. or an internal PKI that would be created within the enterprise. In this case, the CA will be stored in a host and it will only contain this unique element of the PKI.

4.6 Registration Authority (RA)

The role of the RA is to regulate storing, data control, communicating with the asking entity and with the CA, and checking of the respect that the certification policies are respected. It also manages the certificate requests and controls the usage verification on the user's identity that requests this certificate. The RA has ways to verify the identity of the user. This can be done by a simple exchange of information (e-mail, phone, fax, etc.), a HTML form or a simple examination of the access rights of the user in order to check if that person actually has the right to request a certificate from this authority. A RA should also manage the publication of certificates and CRLs. If the RA accepts the request, it will transmit this directly to the CA. Because the CA is not connected to the Internet, the information transfer between both entities could be done by physical elements like an USB key for example. An administrator will have the task to make an interaction between the CA and the RA by transferring information himself. There are some different formatting standards17 and the one that is used for this kind of exchange is the PKCS#10. Some advantages are noticed when the CA and the RA are separated in a physical way: ٠ In the whole system, only one central CA is necessary to generate every certificate and there

can be one or some different RA which are geographically divided in order to answer requests that will come from different branches.

٠ If these two elements are separated, it allows to have a better distribution of the tasks

between the entities and to make the work easier. ٠ According to the political choice of the enterprise, the verification of a user can take a lot of

time and can be difficult to maintain. If this function is realised by an autonomous RA, the central CA can be alleviated of this task.

17 Annex 1 – PKCS Standards

Page 45: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 45/204

4.7 Validation Authority (VA)

Validation Authority allows the controlling of the validity of certificates and signatures by consulting the CRL, for example. This entity is optional because its task can be carried out directly by the RA. The protocol that is used to check all the information is called Online Certificate Status Protocol (OCSP). Here is a figure that describes, in an easy way, the mechanism of a PKI, from the registering (red arrows) to the examination (blue arrows).

Figure 18: PKI mechanism (Source: Sécurité des systèmes d'information – Course book of M.Buchs)

Another point to be made is that the use of a directory to store certificates and CRL is optional. However, if the system requires it, the directory could be seen thanks to the LDAP protocol (Lightweight Directory Access Protocol).

4.8 Certificates The use of a certificate, emitted by a trusted third party, to authenticate a user is very important for the stability of the system and also for developing the trust a user can toward this party. The architecture that builds a PKI, and then a CA, allows avoiding the risk of a man in the middle attack.

Page 46: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 46/204

Figure 19: Use of a trusted third party (Source: Sécurité des systèmes d'information – Course book of M.Buchs)

Indeed, both users (Alice and Bob) are now sure to be in relation with a party in whom they can entirely trust. The risk of theft or key substitution by an intruder is then reduced with such a system. Everything is then built on the trust and on the proof of validity that provides the certificate. This method has the ability to link a public key value to its entity. It has a limited time of life. The signature of the certificate and its requisition can be checked in an independent way by the user. That is the reason why the certificate distribution is not critical and this step can be realised by a non trusted relation communication. It is accepted that the RA distributes them in a normal way, without taking the precaution of securing the exchanger. The certificate management process is almost common depending on the chosen algorithm and the structure: ٠ The receiver of data has to check that the identity of the sender fits with the one that is

found in the certificate. ٠ The receiver makes sure, by looking in the CRL, that the certificate has not been revoked

and that the certificate is in a valid period when the data is signed. ٠ The receiver verifies that the entity that has signed the document has the authorization to

sign it. ٠ Finally, the receiver examines that the data has not been modified, since the moment when

they have been signed, by using a certificate's public key. Some different standards of certificates exist but the most popular is the X509v3 certificate.

Page 47: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 47/204

Figure 20: X509v3 certificate (Source: Sécurité des systèmes d'information – Course book of M.Buchs)

The choice of the standard of the certificate has to be identical for the entire structure. Moreover, information that the certificates holds has to be uniform through the entire PKI. There are also standards of public key encryption18. The ones that manage the demands for the certificates are PKCS#10 and PKCS#12 which stores the private key, with the relative public certificate, in a file with a PIN code protection.

4.9 Interoperability Interoperability is the fact that some systems that are similar or not, can communicate and operate without any ambiguity. This is a fundamental point that has to be taken in consideration when deploying a PKI. Indeed, seeing that some different systems are going to convey information between them, it has to be guaranteed that it will not have any problems of interoperability.

4.10 Directory

The role of a directory in a PKI is to reach a better organization of the entire system. Indeed, the directory allows the storing information that is easily accessible for the user who has the right to access it. Here is what a directory can store in order to enhance the quality of the PKI: · Different emitted certificates, so that it is easier to recover them. · The CRL that allows the user to quickly verify the validity of a certificate. · Private keys that will be accessible uniquely by administrator.

18 [Annex 1 – PKCS Standards]

Page 48: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 48/204

Some criteria are nevertheless necessary to make the interaction between the PKI and the directory. The directory has to provide the X509v3 standard of certificate and permit the storage of the CRLs in it. It also has to furnish LDAP protocol (Lightweight Directory Access Protocol), which is a standard of data access. LDAP is a protocol that works with TCP/IP. It is very flexible and simple to use. However, its implementation becomes difficult to manage for a large system. Some interoperability problems can also be met between PKI and LDAP depending on which LDAP server is used. The last element that has to be kept in mind is the security at the level of directory's access. Indeed, it is desired that under no circumstance should non-authorized people have access or intercept confidential data. To reach this goal, all communication between the directory and any user will be executed thanks to the SSL protocol. A list of access controls could also be implemented in order to list which people have the right to access which service.

Page 49: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 49/204

5. Biometrics As it has been noticed before, identification and authentication of a person has become very important in the computing world. A large variety of different kinds of authentication solutions have been explained. However, another technology that could get more and more popular is the use of biometrics. Biometrics is the analysis of physical, biological or even behavioral characteristics of a human. Some parameters can be used for biometrics.

5.1 General points The definition of biometrics indicates that it is a science that is used to tell the difference between humans according to their physiological or behavioral biology, and the result can be directly checked. Biometrics is especially used in the area of security, in order to authenticate a person. Just as a reminder, this is a method that allows proving "what we are". The aspect of "what we are able to do" can also be related to biometrics and can be realized thanks to the way that the person has to write, the rapidity of hitting the keyboard, etc. When a user proceeds for a biometric authentication, the system will compare the received data with the one it will own in its database. Information treatment is unique to every technology used, but the answer to authentication is found in the fact to either accept or reject the user wanting to authenticate. The answer to this request is done through a threshold of validity between the element wanting to authenticate and the correspondent found in the database. The real difficulty resides at this point. Indeed, two types of errors are possible: º False Rejection Rate (FRR) => Rejection of users when they should have been

accepted. º False Acceptation Rate (FAR) => The authorization of access to a person that

normally should not have the right to access. º Equal Error Rate (EER) => Intersection between FRR and FAR19 An ideal system would not generate any of those errors. Unfortunately, a tool that will produce this result is totally utopian. Generally, it is noticed that FRR and FAR are inversely proportional. Indeed, an application that would authorize every single user would have ratings of FRR = 0 and FAR = 1. In the opposite view, if the access would be refused to everyone, the coefficients would be FRR = 1 and FAR = 0. Then, a compromise has to be found between both elements in order to reach a satisfying degree of security. This arrangement is variable according to the application that is used. A bank application will prefer to reject a

19 FRR, FAR and EER will be schematized in figure Figure 21: Compromise between FRR and FAR

Page 50: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 50/204

few more people in order to avoid at all costs the intrusion of dishonest users. It depends of the level of security that the system wants to reach.

Figure 21: Compromise between FRR and FAR (Source: http://www.biometrie-online.net/techno/fonctionnement-biometrique.php)

Biometrics is a science that is in expansion because its utilization avoids the problems related to loss, forgetting, robbery or even duplications. This technology can be associated to another mechanism of authentication like a login/password system, a smart card or others, in order to reach strong authentication characteristics.

Figure 22: Risks due to the chosen system (Source: http://www.biometrie-online.net/present.php)

5.2 Technologies

Some technologies which use a biometrical authentication are offered to us. The principle consists of seizing data from a user and storing them in a database. Once that this user wants to authenticate, a new biometrics will be executed in order to capture and compare with the ones stored in the database.

Biometrics systems suppress risks

Key

Badge

Code

Biometrics

Copy Stealing Oversight Loss

FRR FAR

EER

Page 51: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 51/204

Below, the general process of storing and the control of any user, independently of the chosen technology can be noticed. In function of the choices that have been done, the tools can be variable but this kind of development will always be respected.

Figure 23: User registration process (Source: http://www.biometrie-online.net/techno/fonctionnement-biometrique.php)

5.2.1 Fingerprint To this day, it is the most commonly used authentication method. This process is executed to authenticate a person and it has been used for a long time. This idea was invented in 1877 in India where William Herschel used it to authenticate the men that had the right to have a military pension. This was done to avoid that the same person had the pension more than once. During the years that followed, this technique was further developed in order to use it for other applications. Nowadays, some organizations own a database for fingerprints. A fingerprint is not used just like that to authenticate a person. There are some points, called minutiae, which are extracted from the fingerprint and are compared with other fingerprints (stored in the database) to determine if two fingerprints are similar. The minutiae are represented by stops in the line, bifurcation, seas, islands, etc. The possibility of different combinations is infinite.

Seizure

Seizure

Processing Signature

File

Comparison

Processing Signature

File

Morphological

Element

Transmittal of the comparison result

towards the application

Registering of a user

Page 52: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 52/204

Figure 24: Fingerprint with minutiae and different kind of attention to detail (Source: http://webmag.safran-group.com/article.php3?id_article=129&lang=fr

& http://www.biometrie-online.net/techno/empreintes/T-fin.php) To obtain digital images of fingerprints is not an easy thing because the area that has to be analysed is very small in comparison to the quantity of information that can be extracted from it. Some parameters are to be taken in consideration for the choice of the sensor. Indeed, kids and also other ethnic groups like Asian people have a thinner fingerprint and capturing them is much more difficult to do.

Figure 25: Fingerprint capture (Source: http://www.biometrie-online.net/techno/empreintes/T-fin.php)

The capture is effectuated in zones where the skin has a contact with the sensor. There exist different kinds of sensors that perform different functions. º Optical sensor º Silicon sensor º Thermal sensor º Ultrasound sensor A process is necessary to extract information that is ready to be compared:

Page 53: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 53/204

٠ Minutiae localization: This step allows to identify the roughest and the most pertinent minutiae.

٠ Texture treatment: process that shows orientation, frequency and even others parameters

in order to be compared with the other fingerprint. ٠ Storing of the fingerprint under the appropriated format: It depends from the used

application. This part is necessary for data exchange. ٠ Images filtering (Segmentation): Step that eliminates the ambiguities of the image in

making the maximum of usable information come out. ٠ Evaluation of the quality of the captured fingerprint: Quality factor that is calculated to

give a reliability indication. The minimum number of comparable minutiae is fixed at fourteen in order to reach a satisfactory degree of reliability.

٠ Make a cast of the fingerprint: Necessary steps to detect quickly the minutiae in

schematizing the fingerprint image. ٠ Extraction of minutiae: Final process that completes the fingerprint analysis. Once these steps are realised, both fingerprints are compared and the system gives an indication of the percentage of the correspondence between two marks. Biometrics by fingerprints is the most commonly used technique in the entire world. Solutions more and more affordable are coming on the market and that factor gives biometrics the opportunity to be used in more and more applications. NOTE: A larger study about other biometrical technologies is presented in Annex 2 – Biometrics, other solutions. Nevertheless it has been very interesting to learn about other mechanisms; only the fingerprint technique makes sense in the whole project. Indeed, the chapter 21. Biometrics deployment will explain the building and the using of fingerprint, coupled with a smartcard, in a strong authentication process with certificates.

5.3 Market Actually, biometrics is experiencing a growth that it has never been seen before. The number of enterprises that provide this kind of services is flourishing, that leads us to believe that it is a domain that is having a great success. However, not a lot of suppliers can offer a complete range of these kinds of products. This is a market that is in full development and that could risk to be more and more attractive to be in. Indeed, biometrics can touch a lot of different domains like computer science, economy, etc.

Page 54: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 54/204

Here is a projection of the evolution of this market during the next five years. This study has been realised by the IBG (International Biometric Group) whose goal is to expose the growth of this market.

Figure 26: Projection of biometry's market evolution (Source: http://www.biometrie-online.net/marche.php)

It can be noticed that the expected growth for the coming years is constant. To be more precise, the biometrical technology of fingerprint is the most popular with a percentage evaluation of about 43% of the market share, followed by the face recognition at about 19%. These two methods (especially fingerprint) guarantee a highest level of performance.

5.4 Legislation

Biometrical systems measure physical parameters in order to compare them to others stored in the databases. This is personal data and should not be disclosed to anyone. Then, it follows that one has to protect this kind of data in an appropriate way. Generally, a person does not like to supply personal information. That is why biometrics is not yet well accepted by the public. Legislation covering the used system makes data protection a matter of concern for each country. However, according to the application or the domain where this technology is used, legislation can be delicate if it covers users from different countries. It is a question that has to be kept in mind from the moment of the architectural conception of a system.

Page 55: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 55/204

5.5 Costs evaluation

The cost of biometrics has often been a problem, because essentially, they are pretty high. To define a concrete costs evaluation, it is necessary at first, to define user's type, the number of devices to install (if the enterprise has three branches, for example), the number of employees, etc. Here is, at equal scales, a graphic that resumes an evaluation of different parameters on the most commonly used biometrical technologies.

Figure 27: Assets and drawbacks of the different biometry technologies (Source: http://www.biometrie-online.net/techno/fonctionnement-biometrique.php)

٠ Intrusiveness: Level of perception, by the user, of an intrusion ٠ Accuracy: Efficiency of the technology ٠ Cost: Costs of the needed components to use the technology ٠ Effort: Effort that have to be executed by the user This figure allows observing the different qualities of each biometrical technology. In terms of costs for example, it can be seen that the most expensive elements are iris and retina analysis. In contrast, the cheapest are typing dynamics and voice analysis. Fingerprint authentication, which is the most used method, is situated around the average of all the described parameter. The reason why it works is perhaps because all those parameters offer satisfying results in each different parameter.

Page 56: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 56/204

6. Demonstration case The objective of authentication is to make a hacker's work impossible. To do this, the best solution is to combine authentication mechanisms in order to reach a stronger authentication. Some enterprises are satisfied with two different authentication methods while others try to add a maximum of obstacles. The degree of security depends on the commercial values that are at stake. For example, the Bloomberg enterprise is a business that is evolving in the financial world. It provides an informational service, known through out the entire world, which is distributed under licences pretty expensive (about 18000 CHF per user and per year). Its authentication concept is much elaborated. Firstly, the user receives a card in which will register the users fingerprints. This first fingerprint capture will be used as a model and will be kept stored in the memory of the card. When the user will want to use this service, it will first authenticate with the login and password. Then, the card will ask its user to authenticate their fingerprint. The fingerprint will then be then compared to the stored model in the card. If both steps are a success, the card will indicate that the user has to synchronize the card with the system. The user then has about thirty seconds to place its card on the computer screen, where a schema represents the card. This step is necessary to synchronize the card with the authentication system. Once both elements have been synchronized, the authentication system will transmit the user a password of four characters via its personal card. At this moment, the user has to enter the code via its keyboard, like if the person would enter a password. Once this phase is realised, and it is a success, the user will be authenticated by the system. This mechanism has not the pretension to be a feasible solution for this diploma thesis. Indeed, its costs are an insurmountable parameter for a lot of enterprises. Here, the idea was just to expose an authentication case for demonstration purpose that can be exploited at a pretty high level. The technological aspect of the solution is very interesting even if its capacity to be introduced in a business remains very weak if this enterprise is not a big bank.

Page 57: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 57/204

7. Architectural structure Like each computerized element or zones inside the enterprise or others, it is important to divide the components between them. Indeed, before suggesting an architectural structure, it is necessary to separate the elements and also to assign them a priority or rather, a degree of security to reach according to their sensitivity. Here is a list of the components of a PKI: · CA: It is the most important factor of the PKI infrastructure. Indeed, it is the most critical

element because if its private key would be stolen, the hacker can make the other users believe that he is the trusted third party. The ideal would be to isolate it in a locked local and only an administrator could access it.

· RA: This component is not that sensitive, because it does not manage confidential

information. It can, without any worries, be situated on a web server for example. · Others elements: Are not very sensitive, at the level of the PKI of course. Their protection

will be decided (application server will be secured according to the type of application, etc.) depending of the degree of security that the system has to reach for each single element.

Figure 28: Thought architectural solution

Page 58: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 58/204

8. PKI implementation So far the currently finished work has accomplished details like the type of architecture has been chosen according to specifics criteria decided thanks to the wishes of the enterprise. Now, two methods exist to realise a PKI. Indeed, a solution called "Thin client" or another one called "Rich client" can be imagined. Below is there an explanation of some details differentiating these two solutions.

8.1 Thin client (Web based) solution "Thin client" solution is nothing but a web based solution and which is based on HTTPS. The big advantage is to avoid to not having to deploy supplementary software for each host client. System administration in its entirety is then easier. However, what can be reproached to this idea is that the pages displayed as well as the dynamics are always a bit limited. Another unpleasant aspect is the fact that performances are restricted by the frequent round trips toward the server.

Figure 29: Thin client (web based) solution (Source: Sécurité des systèmes d'information – Course book of M.Buchs)

RA ADMINISTRATOR

PKI CLIENT

CA SERVER

RA SERVER PUBLIC SERVER

CA ADMINISTRATOR

Page 59: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 59/204

The above figure shows a "thin client" solution. It can be noticed that important elements are not located on the host client. The latter has to browse between different servers according to the application wanting to be realised. Depending on the number of simultaneous communications that can cause some server's to overload, some administrators can be compelled to oversize the servers.

8.2 Fat client solution "Fat client" solution proposes another approach to resolve the problem. Here, it will be rather a question of a client graphical application, executed on a user's operating system. Such a methodology permits to reach evolved treatment capacities and a sophisticated graphical interface can be realised. However, as its name indicates, it asks a considerable effort to reach a satisfying level and as much from the logical aspect as from the logical application which are mixed. At each application launching, a function allows to go and see on the server if a newer version exists and, if it is the case, to download it on user's host. One asset of such a solution is application decentralisation from each user's host, which permits to have more performance and successfully completed functions. Furthermore, round trips toward the server are almost suppressed, that allows less overloading of the traffic flow within the enterprise. However, its deployment and its administration are more delicate.

8.3 Rich client solution A "rich client" solution is an intermediary between both methods "thin client" and "fat client". The idea of this hybrid mechanism is to mix the advantages of each solution presented above. Indeed, the browser will always be used like an entry gate for the application and will permit to download an application and then, to launch it. Thereafter, the system becomes autonomous and takes on the characteristics of a "fat client". For the user, the application behaves like a fat client. For the administrator, the deploying tasks being automated, work becomes more agreeable.

Page 60: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 60/204

9. PKI composition The most interesting solution in this diploma thesis is the building of a PKI within the enterprise where the activity will be effectuated. Nevertheless, once the choice has been thought about as to which mechanism to apply, a lot of elements that will compose this PKI should have been defined in order to plan the best way to do the work. For example components like; the developing environment, the operating system that will be used, the software which will be in charge of the structure, the choice of the different protocols, the application management and many more important details.

9.1 Choice of the software for key management exchange Some different solutions are possible to provide the deployment of a PKI within a business. Here is a list of possible solutions, with their respective advantages and disadvantages: ٠ Baltimore, Entrust, Thawte, Verisign, Wisekey: These names are some well-known PKI

services suppliers. Those organisations ask remuneration for using their services that can be a decisive disadvantage. Moreover, the enterprise where the PKI infrastructure will be created would not have the control of the certificates in using these kinds of providers. For example, the licence of Entrust starts at a cost of about 20'000 euros and is extended according to the number of users in the infrastructure.

٠ IdealX - OpenTrust: Easier integration but the licence cost is starting at 10'000 euros and the

more the architecture becomes complex, the more the costs will increase. ٠ Keon (by RSA): This is a system which charges a price for the licence which is calculated

according to the number of users that furnishes a PKI architecture. ٠ Microsoft PKI Windows: This is a free environment, which is a big advantage.

Nevertheless, it is indispensable to buy certificates to a third party like Verisign or other ones. This last argument makes that some expenses are necessary. Moreover, an enterprise that would produces its certificates itself could not use such a solution.

٠ OpenSSL: It is also possible to deploy a PKI thanks to OpenSSL. However, only a small

infrastructure can be realised otherwise the complexity would become too important. Then, this is a solution to avoid.

٠ Selso: This business offers its services in the goal to use certificates as bench tests. User's

identity cannot in any case be verified, that makes this PKI solution not usable neither for signature nor for authentication. If this solution is used, a certification authority has to be mounted internally, based on software like OpenCA, Microsoft CA, Entrust, etc.

٠ OpenCA: This solution is totally free and allows the administrators to manage themselves

the certificates. So, the enterprise can have its own CA, RA, etc. This method is feasible in a free environment like Linux. Its integration is also possible on Windows but the arrangements that have to be done to make it works seem to be pretty complex.

Page 61: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 61/204

9.2 Comparison between Microsoft CA and Open CA These two solutions cited above are the most interesting were namely OpenCA and Microsoft CA. Indeed, these are the two software that offer the highest guarantees and that could be installed within the enterprise. Then, a comparison has to be done between them in order to take a decision on which of the software to use.

Page 62: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 62/204

Figure 30: Comparative Microsoft CA vs OpenCA (Source: http://vtmig.w2k.vt.edu/docs/vtmig_pki_interop_v1.2.pdf)

According to this comparative that has shown the advantages of each of the software, OpenCA gives the impression to be more powerful in configuration. It is important to have some tools to configure different modules in the specific interests of the enterprise. OpenCA asks certainly more involvement in installation and deployment but the result will really be closer to the final objectives. Indeed, the work that the administrator has to do is certainly meant for an expert, showing that the configuration degree can really be adapted according to enterprise's needs. In order to determine which one of those different solutions is adequate, the wishes of the business, where the project will be executed, have to be kept in mind. To this end, the aspects that seemed to have an open source solution, for irrefutable reasons of costs, and also to have the control on the management of the certificates for its clients, in emitting themselves certificates. With this kind of demand, the most logical choice was to recommend OpenCA solution. Indeed, this software allows reaching the goals cited above.

Page 63: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 63/204

< PRACTICE >

Page 64: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 64/204

10. Set up of the OpenCA PKI environment Another asset of OpenCA is that it is based on other open source projects like OpenLDAP, OpenSSL, Apache Project and Apache mod_ssl. All the projects distributed in the open source world make OpenCA a robust certification authority. Besides, all the problems of interoperability (PKI – LDAP directory for example) are solved since all these projects are built on the same basis. Having made the choice of OpenCA, the operating system in which it would be deployed has to be chosen. For reasons of simplicity, the attention has naturally been turned Linux distribution in order to avoid the heavy integration introduction concerns. In the large range of distributions, Ubuntu has been chosen for many different reasons. Indeed, it is an environment that is very close to Debian, which is a very good distribution but a bit hard to access. Ubuntu's installation seems to be much easier and its deployment faster. Different elements composing the PKI will be installed each one on different hosts. But, for reasons of simplicity and comprehension, the first tests will be effectuated on only one host. This computer will serve the purpose of the CA and the RA at the same time. Different elements composing the PKI will be installed each ones on different hosts. But, for reasons of simplicity and comprehension, the first tests will be effectuated on only one host. This computer will serve the purpose of the CA and the RA at the same time. It has also to be noticed that some years ago, a vulnerability of OpenCA has been detected. The latter can induce the acceptance of incorrect signatures. This problem comes from a validation error that is present in the function that was in charge to check the signature. Indeed, this function was only verifying serial's certificate that was present in the database and the certificate emitted and signed for a user.20 This weak link has been adjusted since OpenCA's version 0.9.1.7. Thus, this problem doesn't directly concern this project but it is important to be informed. Indeed, such vulnerability allows cross-site scripting. With this mechanism, some malicious code could be introduced.

10.1 Configuration of PKI servers

To introduce the practice part, it is important to discuss about the different elements that have been installed on the server. First of all, the operating system that has already been introduced will be more detailed. Then, because of the selection of a Linux distribution, different kind of packages must have been installed. These packages will be detailed below in order to reference each element, to indicate which component is necessary in the mounting of a public key infrastructure under a Linux distribution.

20 http://www.frsirt.com/bulletins/42

Page 65: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 65/204

10.1.1 General Ubuntu being chosen, the version of this operating system has to be selected. Thus, the selection has been done in a logical way. Indeed, at the moment where this thesis was started, the last stable Ubuntu’s distribution was:

- Ubuntu 7.04 Feisty Fawn Here is also the version of the kernel on which this project has been realized: Linux openca-desktop 2.6.20-16-generic #2 SMP Fri Aug 31 00 :55 :27 : UTC 2007 i686 GNU/Linux Some packages are proposed to be downloaded on the computer. In addition to these, some others have to be added for the good work of the PKI that will be configured. Here is a list of different packages with their respective version. Two packages are essentials for the compilation of every element. Moreover, Linux kernel depends of the functionalities of GCC:

gcc 4.1 (C compiler) g++ 4.1 (C++ compiler)

Packages installed with Synaptic Package Manager:

- sun-java 6 - apache2 2.2.3-3.2 - oppenssl 0.9.8c - mod_ssl - perl 5.8.8-7 - postgresql 8.2 (postgresql-client, postgresql-common)

Some Perl modules with their versions and a brief explanation of their utility are presented below. It has to be noticed that these packages have been installed with the help of the following command, which allows the super user to go into perl's shell:

perl –MCPAN –e shell Once that perl shell has been entered, the command: install … ("…" has to be replaced by the desired perl module) has to be introduced. Here is a list of the different packages that have been installed thanks to this command.

Page 66: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 66/204

Figure 31: Perl's modules that need to be installed (Source: http://www.openca.info/docs/guide/openca-guide.html)

10.1.2 Apache2 modules configuration Some packages that are available for the deployment of apache need to be enabled and some others have to be disabled for the good mechanism of the PKI structure that will interact with apache. Here are the necessary operations to do this: libssl-dev package => launches the SSL development libraries a2dismod userdir cgid => program that disables userdir cgid module within the apache2 configuration. a2dismod cgid => program that disables cgid module within the apache2 configuration. a2enmod cgi => program that enables cgi module within the apache2 configuration. a2enmod ssl => program that enables ssl module within the apache2 configuration. a2ensite default-443 => create symbolical links of the configurations files that will stay in /etc/apache2/sites-enabled.

Page 67: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 67/204

An important step has to be made in order to access OpenCA's web interface. Indeed, an apache certificate has to be generated locally on the machine where CA and RA will stand. This certificate has not the necessity to be signed by the CA and is just needed to access the interface. This certificate allows running the application over SSL and it is generated thanks to the following command: make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem –days 1000 The last option (-days) allows the administrator to choose the number of days during which the apache certificate is valid. This option is interesting and necessary because by default the certificate is valid for only thirty days. If the certificate is valid only for thirty days, the administrator should update it regularly. Then, the file /etc/apache2/ports.conf is edited, in order to listen on the desired ports, which are port 80 for HTTP and port 443 for TLS

Listen 80 Listen 443

The file /etc/apache2/sites-available/default has been edited in order to accept all connections from port 80.

NameVirtualHost *:80 <VirtualHost *:80>

The configuration file is copied in another version, relative to the port 443 used with SSL protocol. cp /etc/apache2/sites-available/default /etc/apache2/sites-available/default-443 The file /etc/apache2/sites-available/default-443 is edited to be in harmony with SSL options. In this case, all connections from the specific port of SSL are accepted. Moreover, SSL engine is started thanks to the SSLEngine on command. The complete configuration of Apache for PKI server is detailed in Annex 3 – Configuration of Apache for PKI server. NameVirtualHost 172.16.1.63:443

<VirtualHost 172.16.1.63:443> SSLEngine on A necessary link, for the good working of the structure, is made with the help of this command: ln -s /etc/apache2/sites-available/default-443 /etc/apache2/sites-enabled/000-default-443

Page 68: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 68/204

Indeed, apache configuration launches files that are located in sites-enabled. The apache server is then initialized with the command: /etc/init.d/apache2 restart Moreover, the IP address of the OpenCA server has to be introduced in the file /etc/apache/apache2.conf.

ServerName 172.16.1.63

10.1.3 Apache configuration for PKI server The interfaces for CA administrator and RA administrator are protected by a login/password. Even if the element of the PKI will be within the enterprise and protected by external risks, an additional protection has been thought in order to prevent a weakness from the inner of the enterprise. Security is never enough applied. Thus, the interfaces reserved to CA and RA administrator have been protected in apache configuration. Indeed, a setting allows to authorize a user accessing a particular section only if he present a precise certificate.

<Directory /var/www/ca >

SSLOptions + StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

SSLRequire (%{SSL_CLENT_S_DN_CN} eq "IT Software CA")

</Directory>

This is a typical restriction of the web pages contained in the directory /var/www/ca which

means that these are web pages reserved to CA administrator. ”SSLVerifyClient require” allows to request that the user has to present his certificate in order to be authenticated.

”SSLRequire (%{SSL_CLENT_S_DN_CN} eq "IT Software CA")” is a very interesting option that authorize only the certificates that have for name “IT Software CA”, the name of CA certificate. Because of the fact that the management is done inside the company, the access to these resource, thanks to this additional parameter, will be enough secured. However there is always the possibility to add other type of restriction in dealing with other parameters of the certificates. These parameters are detailed in Figure 80: Apache variables. By protecting the access in this way, an unauthorized user trying to access a restricted zone will receive a “HTTP – 403 Forbidden” error message code.

10.1.4 Databases creation The management of the PKI database has to be created. OpenCA database is going to manage all data and operations made by the RA and the CA. In order to separate the operations realized by the CA and the ones by the RA satisfactorily, two different databases have to be created. In the chosen configuration, also two different users have been started in a sense to establish a clear separation between CA and RA.

Page 69: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 69/204

The two database's users (openca_ca and openca_ra) are created with the following commands: Creation of user and database from the CA side: su - postgres postgres@ca:~$ createuser -A -d -P -E openca_ca Enter password for new user: Enter it again: CREATE USER Create the database using the openca_ca user

su – openca_ca openca@ca:~$ createdb -E utf8 -O openca_ca -W openca_ca Password: CREATE DATABASE openca@ca:~$ exit logout

Creation of user and database from the RA side: su - postgres postgres@ca:~$ createuser -A -d -P -E openca_ra Enter password for new user: Enter it again: CREATE USER Create the database using the openca_ra user su – openca_ra openca@ca:~$ createdb -E utf8 -O openca_ra -W openca_ra Password: CREATE DATABASE openca@ca:~$ exit logout

Page 70: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 70/204

Figure 32: Creation of two databases in pgAdmin

The software pgAdmin is a Postgresql database interface that allows seeing graphically the status of the existing database. Thus, with the help of pgAdmin, it can be seen that both databases created before, openca_ca and openca_ra, have been successfully created and are then ready for use. A last operation has to be realized for the future use of these databases. In each of those two databases, a schema named openca_X (X for ca or ra depending of which database is concerned) has to be created. This can be easily realized with pgadmin tool, by launching pgadmin in the shell. If this step isn't executed, openca won't be able to initialize the databases and openCA won't run. This problem stems from the relation between the configuration file of the CA/RA and the creation of the database. This schema is needed because SQL commands are stored in CA/RA configuration and the name of the schema has to be identical with the name used in SQL commands. If it is not the case, the database will not be initialized and no other successive operation can be executed with success. Here is an extract of the SQL commands generated at the initialization of the CA, which will be described in chapter 10.2 CA initialization, showing the necessity to create these two specific schemas (openca_ca and openca_ra): select * from openca_ca.ca_certificate; drop table openca_ca.ca_certificate; create table openca_ca.ca_certificate (ca_cert_key text PRIMARY KEY NOT NULL, format text, data text, dn text, cn text, email text, status text, public_key text, notafter int8);

Page 71: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 71/204

Figure 33: openca_ca schema creation with the relative SQL command generated

Figure 34: openca_ra schema creation with the relative SQL command generated

The installation of OpenCA's package will be executed on only one host because there is no need to do it on two or more at that stage. This host will manage two different important elements of a PKI like the CA and the RA. This can be done without any problem but in order to be accurate and clear, both elements will be installed and configured in two distinguished paths. Thus, two directories are created in order to store OpenCA's package: /usr/local/src/CA /usr/local/src/RA Download OpenCA 0.9.3-rc1 on https://www.openca.org/projects/openca/downloads.shtml in both directories. Then, the next operation is done in each directory created before in order to uncompress OpenCA package. Tar –xvf openca-0.9.3-rc1.tar.gz By choosing this kind of separation, the configuration is perfectly clear. Indeed, if the installation was realized on only one path, the configuration would have been executed twice from the same path. In this case, the second configuration launched would have overwritten the first one, which is not a professional way to do it.

Page 72: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 72/204

10.1.5 CA Configuration Here is the configuration's command that has been used in order to create all necessary directories, which have been written as parameters. root@openca-desktop:/usr/local/src/CA/openca-0.9.3-rc1# ./configure --with-node-prefix=ca-node --with-openca-user=openca --with-openca-group=openca --with-web-host=172.16.1.63 --with-httpd-user=www-data --with-httpd-group=www-data --with-cgi-fs-prefix=/usr/lib/cgi-bin --with-htdocs-fs-prefix=/var/www --with-openca-prefix=/usr/local/openca/ca --with-etc-prefix=/usr/local/openca/ca/etc --with-module-prefix=/usr/local/openca/ca/modules --enable-dbi --enable-rbac And then, make, make test, make install-offline

10.1.6 RA Configuration The same configuration is done for the RA, but with some necessary changes in order to fit with the RA. root@openca-desktop:/usr/local/src/RA/openca-0.9.3-rc1# ./configure --with-node-prefix=ra-node --with-openca-user=openca --with-openca-group=openca --with-web-host=172.16.1.63 --with-httpd-user=www-data --with-httpd-group=www-data --with-cgi-fs-prefix=/usr/lib/cgi-bin --with-htdocs-fs-prefix=/var/www --with-openca-prefix=/usr/local/openca/ra --with-etc-prefix=/usr/local/openca/ra/etc --with-module-prefix=/usr/local/openca/ra/modules --enable-dbi --enable-rbac And then, make, make test, make install-online At this stage of the configuration, all the necessary directories have been created. To have a better knowledge of the options selected, here is an overview and an explanation of each option: ./configure => Used to set up the configurations. This command will build the file Makefile. --with-node-prefix=ca-node => Distinction of the node (ca-node vs ra-node). If this is not

made, there will be only one node and there will be confusion. Moreover, data couldn't be exchanged between CA and RA. This is a step that is needed when CA and RA coexist on the same host. Thus, in a real deployment case, this distinction is not necessary.

--with-openca-user=openca => User that owns all the files and directories. --with-openca-group=openca => Group that owns all the files and directories. --with-web-host=172.16.1.63 => URL of the OpenCA host. --with-httpd-user=www-data => Web server user name. --with-httpd-group=www-data => Web server group name. --with-cgi-fs-prefix=/usr/lib/cgi-bin => Path where the cgi will be stored. --with-htdocs-fs-prefix=/var/www => Path where are stored the web files that will be

uploaded.

Page 73: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 73/204

--with-openca-prefix=/usr/local/openca/ca => Path of the whole OpenCA installation (in this case, all the files of the CA).

--with-etc-prefix=/usr/local/openca/ca/etc => Path where are stored the configuration files --with-module-prefix=/usr/local/openca/ca/modules => Path where are stored the modules. --enable-dbi => Enables the database independent interface for perl. --enable-rbac => Enables the role-based access control, which allows to have a better control

and for example restrict access only to authorized users.

make => construction of the executable software make install-offline => installs ca and node make install-online => installs ra, ldap, pub, scep and node

SCEP is for Simple Certificate Enrollment Protocol, developed by Cisco in order to automate the deployment of X509 certificates on Network Hardware (VPN IPsec for example).21 This is not a protocol that will be used in the architecture. Then, a very important thing to do is the configuration of the config.xml file in each CA and RA path (for the CA: /usr/local/openca/ca/etc/config.xml). Thus, with the selected architecture, this configuration has to be made either for the CA or for the RA. This file allows a very large possibility of configuration. Here is a list of different modules that can be configured according to the desires of the PKI editor:

- General options about the PKI element (ca_organization, country, mail_account, etc) - Web server configuration - LDAP server configuration - Database configuration - Module configuration - Configuration of relative paths - Configuration of absolute paths - Configuration of SCEP (not used) - General configuration - Dataexchange, that is useful to set up the role of the PKI element installed (here, the

CA) and how the data will be exchanged with another element like the RA. - Creation of the file where data from the PKI will be stored when transiting from CA to

RA and vice versa. For the last point, here are the elements created for the CA stored in /usr/local/openca/ca/var/tmp: Dataexchange_device_up => ca-up Dataexchange_device_down => ca-down Dataexchange_device_local => ra-local And the same file, for the RA stored in /usr/local/openca/ra/var/tmp: Dataexchange_device_up => ca-down Dataexchange_device_down => ra-down Dataexchange_device_local => ra-local

21 [http://fr.wikipedia.org/wiki/SCEP]

Page 74: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 74/204

The configuration file "config.xml" of the CA is detailed in Annex 4 – config.xml of the CA (the global configuration file of the CA). The file is pretty long and this is why the "config.xml" of the RA has not been put in the annex. This is also because both documents don’t differ too much. A few changes need to be adapted to the RA server. These files must be assigned to the right user (here for the CA). Web's user has been chosen: chown www-data:www-data /usr/local/openca/ca/var/tmp/* When CA and RA have to exchange file between themselves, all necessary data, like certificate requests for example, are stored in the ca-down respective path. Thus, when the CA must forward some data to the RA, the file ca-down of the CA has to be copied in the ca-down's RA file and vice versa. Then, some files needs to be edited in order to personalize the latter with the name of the current name of the entity that delivers this PKI (IT Software) to users. Those files are located (for the CA) in /usr/local/openca/ca/etc/openssl/extfiles. So, all the ".template" files are modified. For example: nsComment "Certification Authority Administration of @ca_organization@" The element "@ca_organization @", which normally takes the parameter set in config.xml, is changed with "IT Software". Once all these necessary configuration steps have been executed, the configuration is launched with the command ./configure_etc.sh . The bash openca_rc is renamed openca_CA_rc (openca_RA_rc for RA) in order to not introduce confusion. Then, the bash is copied in /etc/init.d where all the bashes that launch services are stored. After the PKI as been deployed and the first certificates have been attributed to the users, some cases of unsatisfying results can happen. In this situation, some changes can be made without starting the PKI from the beginning. In this circumstance, the config.xml file will be edited in the desired way. The configuration will be compiled again with ./configure_etc.sh. If an update is operated, the certificates emitted before will always be valid and usable.

10.2 CA initialization At this stage of the configuration, the PKI is ready to be initialized and next step is useful to set up the initialization of the CA element in the correct way. CA interface can be reached by writing the URL of the web host chosen in the OpenCA configurations (--with-web-host=172.16.1.63) and in adding "/ca" after => 172.16.1.63/ca

Page 75: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 75/204

Figure 35: CA initialization

The above figure shows there are three mandatory phases for the initialization of the CA element. A brief explanation of the operations and the effect that they bring will be clarified.

Page 76: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 76/204

10.2.1 Phase I: Initialize the Certification Authority

Figure 36: CA initialization - Phase I

The steps that are to be done: • Initialize Database

As mentioned, it initializes the database in creating the necessary tables that will be used in the PKI deployment. Here are the tables that are created either in the CA database or in the RA database:

Figure 37: Tables created in CA's database at the initialization

� CA certificate

� Every certificates (CA, RA, users, etc.)

� Certificate Revocation Lists

� Certificate Revocation Requests

� Requests of certificate

Page 77: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 77/204

• Generate new CA secret key • Generate new CA Certificate Request (use generated secret key)

Figure 38: Generation of CA Certificate Request

The above figure shows the beginning of the CA certificate. It can also be noticed that the certificate is encrypted with RSA and with a key size of 4096 bits.

Figure 39: DN of CA Certificate Request

Here, the figure shows the specific DN that have to be the same that the one in the OpenSSL definition. DN is for Distinguished Name and it is a terminology that is used in LDAP directories. • Self Signed CA Certificate (from already generated secret key) • Rebuild CA Chain Phase I is now completed and the other options are not token in consideration for the moment. They can make sense in the case of a root CA is implemented, which is not the case at the stage, but which can be a non-negligible option in the future.

Page 78: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 78/204

10.2.2 Phase II: Create the initial administrator

Figure 40: CA initialization - Phase II and III

Phase II is necessary to initialize the PKI with the CA certificate. These four operations are mandatory for the good initialization. • Create a new request The administrator has to fill in the form that will create the Certificate. • Issue the certificate This process generates the certificate. • Handle the certificate

This operation makes the certificate downloadable. This certificate has then to be imported in the browser and the latter needs to be re-launched before the certificate can be considered.

10.2.3 Phase III: Create the initial RA certificate This interface is the same as the Phase II. Nevertheless, Phase III is necessary to create the initial RA certificate. Again, these operations are mandatory.

10.3 RA initialization Now that the CA has been started well, the next operation is to initialize the RA element. In this case, the RA path is added to the URL, which gives: 172.16.1.63/ra

Page 79: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 79/204

Then, the tab "Server Management" is clicked in order to enter the RA-node, which allows RA administrator to manage its RA. RA Initialization – RA-node interface

Figure 41: Initialization of the RA

• Initialize Database

It is the same operation as related in the CA initialization, but necessary to create the tables in RA database.

• Import Configuration

It imports the file configuration which has been created in the CA. It is important that this step should reports a success in order that the files between the CA are synchronized with RA's, in the sense that the file structure has to be the same either in CA or in RA.

Page 80: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 80/204

10.4 Data exchange

Figure 42: Possible operations of data exchange between CA and RA

The "Data exchange" tab is useful for every sharing of information through the different levels of the PKI. The most frequent case will be data exchange between CA and RA. • Enroll data to a lower level of the hierarchy => Data from CA to RA • Receive data from a lower level of the hierarchy => Data from RA to CA • Download data from a higher level of the hierarchy => Data from CA to RA • Upload data to a higher level of the hierarchy => Data from RA to CA Now that this important exchange platform is presented, some operations have to be done in order that the RA could receive the certificates and the other configurations of the CA.

Page 81: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 81/204

Indeed, as long as those operations are not done, the RA is not initialized and this can be noticed in watching the RA database, which is empty at that stage. Last steps useful to initialize the RA:

1) Go to the CA-node interface (172.16.1.63/ca-node) Administration => Dataexchange Enroll data to a lower level of the hierarchy Configuration Copy the file ca-down of the CA in the RA configuration with the command: cp /usr/local/openca/ca/var/tmp/ca-down /usr/local/openca/ra/var/tmp

2) Go to the RA-node interface (172.16.1.63/ra-node)

Administration => Dataexchange Download data from a higher level of the hierarchy Configuration Configuration is taken from ca-down file located in RA path.

3) Go the CA-node interface (172.16.1.63/ca-node)

Administration => Dataexchange Enroll data to a lower level of the hierarchy All Copy the file ca-down of the CA in the RA configuration with the command: cp /usr/local/openca/ca/var/tmp/ca-down /usr/local/openca/ra/var/tmp

4) Go to the RA-node interface (172.16.1.63/ra-node)

Administration => Dataexchange Download data from a higher level of the hierarchy All The global elements are taken from ca-down file located in RA path.

These are successful, which means that the RA has been correctly initialized. It can be checked in watching in RA database (openca_ra) if the certificates (CA certificate and RA certificate) are present in it. At this stage, the PKI is operational and the certificates can be requested by users.

Page 82: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 82/204

11. Logistical aspects Some aspects needed to be clarified in order to build a solid structure. Indeed, it was important to know exactly the elements that will be part of the structure and to know how to make the whole system work, in basing everything on security.

11.1 Interaction with the client Different steps have to be realized with the some configurations that have been chosen. At this stage, some other decisions have been taken about the way to interact with the client. It has to be noticed that there is not only one way to make a PKI interact with a user. A solution could have been to make a public interface available to everyone on the web for every user wanting to ask a certificate for example. Indeed, this was the first idea of realization, also because OpenCA' software implements it in that way. With such a public structure, when the user asks a certificate from its host, its private key is generated directly on his host. Then, after the whole process of certificate approval and generation, the certificate will be sent by mail to the user. Thus, the user has to install the approved certificate on the same host where the relative private key is stored, otherwise it won't work. Thus, because when the certificate is downloaded on user's host, the certificate will check the compatibility with the stored private key. If they are not associated, the system will reject the certificate. In fact, it could work in another host if the user copies its relative private key on the desired host. However, the wish of IT Software was to make the process for the client as easy as possible. A user that is not accustomed to fill in a PKI form with all the technical terms will maybe have difficulty in filling it. Thus, an idea to make it easier for the client was to import the entire management of the PKI, of OpenCA software on the side of IT Software. The only thing that the user will have to do is to give its private data via email, phone or any other processes.

11.2 Who are the clients? As a reminder, the PKI infrastructure that will be built within the company makes different people or entities interact. In order to optimize the final solution, it is very important to know exactly the role of each of these elements. As it was not perfectly defined at the beginning of this project, some investigations have to be undertaken in order to identify who exactly is the client who is going to use IT Software's PKI. Here is a figure of the process of exchange between IT Software and its clients:

Page 83: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 83/204

Figure 43: Entire process between IT Software and the client

Explanation of the entire process between IT Software and the client:

1- The bank or financial institution is interested in IT Software's product and asks for a certificate for one of the bank's employees to enable them access to IT Software's web application. Indeed, only a correct login/password combination plus a valid certificate will authenticate the client and allow him to access the application.

2- Briefly, if IT Software agrees, the company generates a request and issues a certificate

for the client. Data like the certificate in PEM22 format and the private key of the client will be sent directly to the bank in a secured way.

3- Data will then be forwarded to the bank's employees who become the client of the PKI

infrastructure. 4- Lastly, the client installs his certificate and if his certificate is valid and recognized by

IT Software, he will be able to access IT Software's web application. All this process makes the client totally invisible for IT Software. In fact, the client is like an abstract client. As it has been mentioned in 11.1 Interaction with the client, the certificate's form is filled in by the company and not by the client directly, for reasons of major simplicity. The fact that the client is abstract in the eyes of IT Software and that IT Software doesn't have information about the client, is another reason why the request of certificate's form is filled in by the company. Thus this is why there is no need to publish PKI's public interface through Internet. One of the consequences is that client's certificate common name, which normally describes the name of the owner, isn't composed by the real name of the client. Indeed, a mechanism has to be imagined in order to classify the certificates in a satisfying way. In this sense a model of definition of common names has been thought of. For example, first three characters could be the acronym of the bank and then following characters will represent a numerical ID. In this way, it is easier for an administrator to manage certificates when the quantity increases. Moreover the bank administrator, even if the common name doesn't mean something, can find with a quick search the real name of the owner.

22 Format that will be more detailed in chapter 16.2.3 .PEM (Privacy-enhanced Electronic Mail)

Page 84: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 84/204

11.3 Architectural implementation

The goal of this part is to describe the architecture of the infrastructure. Normally CA, RA and VA are separated and stand each one on a different host. This chapter, so as the entire project, take this aspect in consideration in keeping in mind that for logistical reasons, CA, RA and VA has been installed over the same host. But the important thing is that every step, every configuration has been thought as if each element was installed, as it has to do, on a separate host.

Figure 44: PKI architecture

The wish of IT Software is to keep all interfaces of the PKI inaccessible from the web. Indeed, the certificate management will be realized on hosts having a private IP address. These hosts will be placed behind a DMZ, protected by two firewalls and its stands to reason that access from HTTP and port 80 will be blocked.

11.4 Firewall configuration Firewall configuration over Linux can be set thanks to many command lines. Thus, it is important to manage well the rules that will build the firewall. It is strongly recommended to adopt the policy of "blocking by default". Everything that is not explicitly authorized is forbidden.

iptables -P INPUT DROP => (Delete every entering packets) iptables -P OUTPUT DROP => (Delete every outgoing packets)

Page 85: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 85/204

iptables -P FORWARD DROP => (Delete every packets that transit) At that stage, absolutely no packets could pass through the firewall. Thus, some different specifics packets may be authorized according to the needs of each server composing the PKI. - CA server is outline and doesn't need to have a firewall configured. - RA server can either transmit data to the client by mail or sms and then a firewall has to be set or data is sent to the client through another channel like postal mail e.g. and the policy by default is sufficient. In the case where RA will send data on the Internet, two rules shall accept these kinds of packets sent through the mail service or http, connecting to a sms provider. iptables -A INPUT -s 172.16.1.63 -d 172.16.1.254 -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -s 172.16.1.63 -p tcp --dport 25 -j ACCEPT

(172.16.1.63 is the IP address of RA server while 172.16.1.254 is the IP address of the default gateway) - VA server is the one that checks the certificates in the case where OCSP is used. Thus, packets coming from the web server through OCSP defined port (2561) will be accepted.

iptables -A INPUT -s 172.16.1.238 -d 172.16.1.63 -p tcp --dport 2561 -j ACCEPT

(172.16.1.238 is the IP address of the web server that will be accessed by the users while the port 2561 is used for the OCSP protocol that will be explained in section 18.4 Request to an OCSP responder) The status of the firewall can be verified by writing the following command:

iptables -L

This gives for result for the VA:

Chain INPUT (policy DROP)

target prot opt source destination

ACCEPT tcp -- 172.16.1.238 anywhere tcp dpt:2561

Chain FORWARD (policy DROP)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Page 86: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 86/204

11.5 Delivery mode of certificate / key pair and PIN code

Another important parameter that has to be taken in consideration is the mechanism that will allow to send information to the client. Indeed, the certificate and the private key have to be sent in the most secure way possible to the bank. The latter will then forward it to the right employee. This last operation will not be implemented during this project because the procedure of this point belongs directly to the bank. There are then two elements that need to be delivered to the bank in a secure way. Before thinking which technology has to be chosen to send data, it is important to define that each of the two elements will be sent through different channels, which means a way to transmit two different pieces of information with two different methods of transmission. Indeed, this is an important point for security that means that a hacker in possession of one of these piece, cannot use the certificate. It is also important not to send each part on the same channel, because if the latter is compromised the pieces can easily be reassembled. In dividing the data and sending it through different channels makes the hacker's job more difficult. Here is a list of possible channels that can be used:

- Token => USB, Smartcard, OTP - E-mail - Postal mail - SMS - Etc.

As a reminder, two of these different methods will be used to send the divided data, which are the certificate/key pair on one hand and the PIN code in the other hand. This list doesn't mean to be exhaustive but it is characterized by concrete methods of transmission. It is clear that the more numerous the techniques of transmission are, the more the number of sending's combination increases. For example, the certificate/key pair could be stored in a token. This mechanism is often used in PKI. An USB token can be used and then transmitted to the client by postal mail or even by hand. Then, when the client accesses the web application, he has to plug-in his USB token and to enter a correct PIN code. Nevertheless, this solution is not a priority for IT Software and the application won't use this mechanism of transmission. In the biometric case where certificate and key pair are included in a smartcard ready to be used, the smartcard will be given personally or by postal mail to the client while the PIN code protecting the certificate/key pair can be sent by postal mail or by SMS. In this last case, every PIN code for the same employee's bank sent by SMS will transit to the same person who is the administrator of the bank and who provides certificate data to the employees. This point can be a bit redundant to manage for bank's administrator. If the certificate and the key pair are delivered in another device and then the client introduces it in the smartcard, certificate/key pair and PIN code will be sent through the different options above cited. At this stage, a mail is automatically sent to the user when his certificate is published by the RA. The library that is in charge of this is located in /usr/local/openca/ca/lib/functions/mail-

Page 87: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 87/204

utils.lib. An automatic procedure that will send an SMS with the PIN code could be inserted in this library. To do this, a sms server needs to be reached with a login and password and then the PIN can be sent in the SMS. But something more can be done in order to enhance the level of security. The element that is delivered should be fragmented before sending it to the client. A solution could be to export the certificate and the private key in PKCS #12 format, process explained in chapter 11.5.1 Export certificate onto a token, which "defines a file format commonly used to store private keys with accompanying public key certificates, protected by a password-based symmetric key."23 Then, the PKCS #12 file containing certificate and private key should be zipped and fragmented in different parts. The latter will then be transmitted through different channels and the receiver could reassemble the parts thanks to a password defined between IT Software's administrator and the client.

11.5.1 Export certificate onto a token This operation is useful when the certificate and the key pair need to be sent to the user, for example onto a smartcard. Whatever the case, this is always needed because the key pair is generated server side and even if the client receives his certificate, he would not have the key pair. By doing this, a backup file containing the certificate and the key pair is created and the file is protected by a PIN code. Either the CA or the RA can do this operation. After having selected the correct certificate, the process can continue. Explanations about how to reach the location where it is possible to choose a certificate are described in the part 12. OpenCA structure.

Figure 45: Download certificate onto token

Then, the administrator has to present his certificate because it is a critical operation. A successful message indicating that the certificate has been imported in the browser appears.

Figure 46: Certificat installed in the browser

23 ANNEX - PKCS

Page 88: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 88/204

Then, in “Edit”, “Preferences”, “Encryption” and “View Certificates” for Firefox (“Tools”, “Internet Options”, “Content” and “Certificates” for Internet Explorer) the certificate downloaded is in the list of certificate. Select the certificate desired and chose the tab “Backup”. The file saved will be formatted in a PKCS#12 file.

Figure 47: Choice of PIN code by the administrator

Then the backed up file can be saved on a device like a smartcard, an USB key, etc. When the user will receive this file, he will open the file and a challenge on the password entered by the administrator will be him requested. This is the PIN code that has to be transmitted to the client over a different channel. If the challenge succeeds, the certificate and the key pair will be imported in their respective places and the user can use his certificate. At the end, the certificate exported onto a token has to be deleted from the browser belonging to who has made this operation (in RA or CA's browser, go to “Edit”, “Preferences”, “Encryption”, “View certificates”, select the certificate and then “Delete”). This operation will delete the key pair stored on the administrator host, so that the certificate could not be used from this computer.

11.5.2 Necessary modification in mail account Among the numerous solutions, a choice has to be made but, at this stage, the certificate can still be sent by mail. In this regard, a change has been necessary in the basic configuration of OpenCA. As already specified in the central configuration file (/usr/local/openca/ca/etc/config.xml), the address email of the sender, which is used to warn the client that he can download his certificate, was still not correct and was set to [email protected], which is the default email address of OpenCA. Thus, in the actual simulation, the client receives an email from an address of which he can't determine the origin. The address has been changed in an existing address from IT Software. So, the email address has been changed in the template located in /usr/local/openca/ca/etc/servers/ca.conf.template in the following lines: SERVICE_MAIL_ACCOUNT "[email protected]"

Page 89: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 89/204

The change can be made in all templates (ca-node.conf.template, ra.conf.tamplate and ra-node.conf.template) but the mail is generated by the CA and so ca.conf.template is the only configuration file that needs this update. At this stage, the address is correctly changed but the subject of the mail can be modified in order to be more understandable for the client. Thus, the file /usr/local/openca/ca/lib/functions/crypto-utils.lib has been updated. my $subject = gettext ("IT Software Certificate and PIN information");

(line #1508)

my $subject = i18nGettext ("IT Software Certificate and PIN information for certificate __CERT_SERIAL__", "__CERT_SERIAL__", $cert->getSerial()); (line #1524) my $subject = gettext ("IT Software Certificate information"); (line #1606) The same update can be executed in RA's configuration but again, it is unnecessary because the mail is formatted and generated from CA's configuration.

Page 90: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 90/204

12. OpenCA structure OpenCA's software allows managing clients' certificate from creation to revocation. In the middle of these two mechanisms, many other operations are possible. Thus, it is very important to keep a trace of each executed operation. To reach this goal the software calls upon databases in order to store every element linked to the PKI (certificate, request, CRL, etc). Here is an interesting diagram describing the whole possible lifecycle of the certificate. (Diamond-shaped form is an action, while ovals represent a status).

Figure 48: Lifecycle of the certificate (Source: http://www.openca.info/docs/guide/openca-guide.html)

NOTE: CRR is for Certificate revocation request. The global management of OpenCA software will be executed within IT Software company. Four different interfaces are proposed to complete the whole management of the PKI. It is important to understand what kinds of functions are offered in each different interface. There

Page 91: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 91/204

are some functions that are not used because of the architectural choices and also because of the needs. The use of these interfaces is rather user-friendly and the functions can quickly be found.

12.1 Public interface

Figure 49: Public interface

This interface permits to create a request of certificate for the client. An interesting thing is that the certificate can be downloaded in different kinds of formats. This parameter allows the software to reach a large public of possible users, which is not negligible in terms of interoperability. This interface also allows seeing every certificate, depending on their relative status. A list of the past requests is also available.

12.2 CA interface

Figure 50: CA interface

CA interface allows CA's administrator to approve or refuse every operations initiated by the RA. The tab "Usual Operations" matches all the operations that the CA can execute. "Active CSRs" regroups the signing request while "Active CRRs" aggregates the revocation requests. The tab "Information" lists every element stored in CA's database (certificates, CRLs, etc). In "General" tab, the sub tab "Node Management" allows CA's administrator to switch over CA-node's interface.

12.3 RA interface

Figure 51: RA interface

Page 92: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 92/204

RA's interface has almost the same tabs as CA's interface. As a reminder, RA does the intermediary between the user and the CA. So the functions that this interface offers are a bit different but the goal is the same. RA-node's interface can be reached in selecting "Server Management" sub tab.

12.4 Node (CA-node and RA-node) interface

Figure 52: Node interface (ca-node, ra-node)

Node's interface (independently of CA or RA) allows switching over CA, RA or Public interface. This interface is essential for the good transmitting of data between CA and RA. This can be managed in "Administration" tab and then "Data exchange". The node interface is practically used only for these operations of exchange. Mails to the user can also be sent thanks to the "Utilities" tab. NOTE BENE: Separates logins and passwords are necessary for RA, RA-node, CA and CA-node interface. The default settings have been maintained. Thus, CA and RA will both login with root/root at that stage. Evidently, this has to be modified in the settings and it will be done by the relative administrator. Here are the steps to do:

• /usr/local/openca/ca/bin/openca-digest sha1 'mypasswd‘ • cd /usr/local/openca/openca/etc/access_control • grep -li '<digest>' *.template • For each match in templates do: • sed –i 's|<digest>Actual Passwd</digest>|<digest>New Passwd</digest>| g' \

/usr/local/openca/openca/etc/access_control/xxx.template24

24 www.tagpma.org/files/ULAGridCA-TAGPMA.ppt

Page 93: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 93/204

13. Process of certificate's request As explained before, at this stage the client has to ask for a certificate directly to IT Software by mail, phone, fax, etc. Once this informal request is received by IT Software, the client is asked for some data, in order to emit a personal and unique certificate. Thus, the administrator in charge of the request will connect to the interface called “public”, but in fact this interface won't be public at all, in the sense that it would be accessible from the web only by the administrator, within the network of IT Software, behind firewalls. Nevertheless, the interface will be called public even if it is not, in order to be coherent with OpenCA's terminologies.

13.1 Request of certificate from RA administrator

- Public interface (172.16.1.63/pub)

Figure 53: Different kinds of certificate requests

• The tab "Request Certificate" allows the administrator to request a certificate for the user. It

can be noticed that there are several options. The first one ("Request a certificate with automatic browser detection") is used when the user makes the request. In this case the private key is directly generated and stored on user's host. With the architecture that has

Page 94: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 94/204

been chosen, the administrator in charge of requesting a certificate for the user will also select this option. It will generate the key pair on his host. Indeed, it is essential to be in possession of the key pair if the certificate has to be exported over a device, a smartcard for example. And this option is the only one that generates the key pair on the host.

• The tabs "Get Requested Certificate", "Test Certificate" and "Revoke" are useful in the case

of the public interface is available for the user. Indeed, these options are not used in the selected architecture.

Figure 54: Certificate's owner data that needs to be filled in this form

Page 95: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 95/204

Here is the interface displayed where the administrator will have to introduce client's data. Different fields will be filled by the administrator in relation with the user's personal data that the administrator will have received. The role of the owner of this certificate can be selected between different options like CA Operator, RA Operator, User, etc. The administrator will choose the appropriate role. The key size can also be chosen between 512 and 4096 bits.

• E-Mail: The email address associated with the certificate • Name: The name of the user • Certificate Request Group: This is usually the department or sub group the user

belongs to • Alternative email: Another email to appear in the certificate • DNS name: The DNS name if the certificate is a web server cert • Name: The real name of the user • Email: The users email address • Department: The user's department • Telephone: The users telephone number • Level of Assurance: This is the type of physical authentication the user is to receive.

This indicates the degree of trustworthiness of certificate’s data. • Role: The certificate role within the hierarchy, this is usually "User" for most normal

users • Registration Authority: This is usually the physical location at which the user is to be

identified (e.g. Personnel) • PIN: A password used to verify the CSR • Key Size: The size of the key used in the CSR (Usually set to 1024) •

25

After the certificate has been requested on public interface, a request is stored in the database and the next who has to intervene is the RA.

13.2 Approval of the request by RA administrator

Now that the request has been made, RA has the duty to approve or not the requested certificate. In order to do this, RA's administrator has to be authenticated on RA's interface (login/password). Then here is the operation that RA's administrator has to execute to approve the certificate.

25 https://www.openca.org/~madwolf/ch05.html

Page 96: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 96/204

- RA interface (172.16.1.63/ra)

Figure 55: New certificate request existing in RA's database

"Information", "Certificate Requests" and "New" tabs have to be selected. Then, the certificates that are stored in RA's database and that have been requested, but not approved or refused yet, are displayed. Most important clients' data are shown in the "Submit Name" section. Then, to enter certificate' specifications, the serial number has to be clicked.

Page 97: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 97/204

Figure 56: Available options for RA to manage certificate request

This figure shows only the last part of the certificate. The hidden section describes the value of the certificate with every specification. The possible operations for RA are to edit the request if some data don't match a policy for example, to verify the PIN, in order to check the validity of it. Then, most important operation is the approval or refusal of the requested certificate. To approve the request, RA's administrator has to select "Approve Request without Signing". Indeed, the approval of the request can only be done without signing it because the request of the certificate has not been signed. At this stage, the certificate will be approved by the RA and the request can be uploaded to CA.

Page 98: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 98/204

- RA-node interface (172.16.1.63/ra-node)

Figure 57: Uploading of certificate requests from RA to CA

This section allows RA and CA to exchange data like certificate request, certificate revocation, CRL, etc. In this case, RA has to deliver clients' certificate request to the CA. Thus, the selected operation will be "Upload requests to a higher level of the hierarchy" (read from RA to CA).

Figure 58: Result of the data exchange

Page 99: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 99/204

When such an operation is carried out, the result of this transaction is displayed in order to inform the sender of the good delivery. As it can be seen in the red-underlined section, a file called "ca-down" is created in RA's path. This archive has to be copied in CA's path. This operation can be realized thanks to an USB key or another kind of device. Then, RA's administrator has to give CA's administrator the device in order that the latter can copy the file on CA server.

13.3 Approval and issuing of the certificate by CA administrator - CA-node interface (172.16.1.63/ca-node)

Figure 59: Reception of certificate request by the CA

The inverse data exchange's operation is made on the CA-node. So CA should select "Receive Requests from a lower level of the hierarchy" (read from RA to CA). If next window manages to carry out the operation, it means that the request stands now in CA's database. - CA interface (172.16.1.63/ca) CA can now approve or not the certificate. In order to do this and after having been authenticated, CA's administrator has to select these following tabs: Usual operations => approved certificate requests => select the certificate by clicking on the serial number.

Page 100: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 100/204

Figure 60: Available options of the CA for the certificate request

Again, only the last part of the certificate is shown above. The two tabs indicate the possible operation that CA can execute. At this stage, if CA agrees with this request, "Issue certificate" tab will be selected. Then, CA's administrator password is requested to continue the step. If the password is accepted, the certificate is officially accepted by the CA. But at this stage, the certificate is not useful because it has not been published by the RA yet. - CA-node interface (172.16.1.63/ca-node)

Figure 61: Enrolling of validated certificates from CA to RA

Page 101: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 101/204

The certificate is then transmitted from the CA to the RA. On CA-node's interface and after having chosen "Administration" and "Data exchange" tabs, CA will choose "Enroll Certificates to a lower level of the hierarchy" (read from CA to RA). The mails that will be sent to user, with information about the issued certificate, are also exported from the CA node. The same operation of copy has to be done in the inverse way. So, the certificate can for example be copied on a USB key.

13.4 Publication of the certificate by RA administrator - RA-node interface (172.16.1.63/ra-node)

Figure 62: Downloading the validated certificates from CA

RA has then to import the issued certificate on its personal database. In order to do this, RA's administrator will connect on its RA-node interface and then select "Administrator" and "Data exchange" tabs. Then the option "Download Certificates from a higher level of the hierarchy" (read from CA to RA) will be chosen.

Page 102: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 102/204

Figure 63: Certificate is in a valid status and is usable

This figure above shows that the certificate has been correctly published by the RA. By default, a mail is automatically sent to this user, sending him the certificate and the PIN. But another solution will probably be adopted in a more secured way using different channels. A panel of different solutions to send data to the client has already been described in 11.5 Delivery mode of certificate / key pair and PIN code.

Page 103: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 103/204

14. Process of certificate's revocation The validity of a certificate can be ended for different reasons. The certificate can for example expire in time (the default validity of a certificate is one year). Another possibility to invalid a certificate is to revoke it. The revocation is a mechanism that can be decided and executed by an administrator for different reasons like a status change (employee leaving the enterprise) or on a doubt of private key's compromising. This section will describe the different steps to revoke a certificate. The first operation has to be executed by RA.

14.1 Beginning of revocation process by RA administrator

- RA interface (172.16.1.63/ra)

Figure 64: View of valid certificates

The first thing to do for RA's administrator is to select the certificate that is compromised and that needs to be revoked. The certificate can be chosen in selecting "Information", "Certificates" and "Valid" tabs. At this point, the list of valid certificates is displayed and RA's administrator can choose the certificate that needs to be revoked.

Page 104: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 104/204

Figure 65: Possible operations on valid certificates

After having chosen the certificate, a panel describes different possible operations. The certificate can be downloaded directly in the browser or onto a token. An email can also be sent to the user. This operation warns the user about the revocation that is going to be executed, for example. In the situation of revocation, RA's administrator will select "Revoke" tab to launch the revocation process.

Figure 66: Notification about the revocation reason

In selecting the tab "Revoke", RA can assign a reason for the revocation of the certificate. This makes sense in order that CA will know the motive of the revocation request.

Figure 67: Generation of the certificate revocation request

Page 105: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 105/204

Then, a message is displayed with the characteristics of the certificate that RA wants to revoke. This message also says that this administrator can check if the request of revocation has been correctly accepted, in looking in the "Approved Revocation Requests List".

Figure 68: Available options on a certificate revocation request for RA

Next step for RA is to approve this revocation in an official way for the CA. RA's administrator has to go in the section "Information", "Revocation Requests" and "New". Then, the approval of the revocation request will be accomplished in selecting the "Approve Request without Signing" tab. Here again, the approval can only be done without signing it because the revocation request of the certificate has not been signed.

Page 106: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 106/204

Figure 69: Status of certificate change in a revocation request

Finally, if the tab "Approved" is selected, the certificate for which a revocation process has been started can be seen. Details of the approved revocation request certificate can be noticed in clicking on the serial number of the certificate. - RA-node interface (172.16.1.63/ra-node)

Figure 70: Upload certificate revocation request to CA

At this stage, the certificate revocation is approved by the RA but the CA is not informed about this revocation. Thus, to warn the CA, the RA will select the section "Administration", "Data exchange". Then, the operation that will be executed by the RA will be "Upload CRRs to a higher level of the hierarchy" (read upload CRRs (Certificate Revocation Requests) from RA to CA). Once this operation is done, the file generated has to be copied in CA's path.

Page 107: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 107/204

14.2 Approval of the process by CA administrator

- CA-node interface (172.16.1.63/ca-node)

Figure 71: Reception of certificate revocation request by the CA

The file generated by the RA and copied on CA's path is imported in CA's database by selecting "Receive CRRs from a lower level of the hierarchy" (Certificate Revocation Requests from RA to CA). This can be done again in the section "Administration", "Data exchange" on CA-node's interface. - CA interface (172.16.1.63/ca)

Figure 72: Possible options offered to the CA to manage the revocation request

The next step is the most important in revocation's process. CA's administrator has to select the "Usual Operations" and then the "Approved Revocation Requests" tabs. At that stage, this administrator chooses the certificate to revoke in clicking on the serial number of this one. Finally, the certificate will be revoked by the CA by selecting "Revoke certificate". Because of this operation is quite delicate, the password of CA's administrator is required. If it is successful, the certificate is considered revoked by the CA but the application that will check this certificate will still authorize this revoked certificate because of the fact that RA hasn’t been informed yet. Indeed, that point is a very critical. When the decision to revoke a certificate is taken, RA and CA have to cut short revocation process' duration to the maximum

Page 108: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 108/204

in order to avoid this kind of situation where the application will allow a certificate that has been revoked. However, the certificate is at this stage introduced in the suspended certificates and the CA has to emit a new CRL in order to introduce this new revoked certificate in the list of revoked certificates. This operation can be planned every "x" days. Adding to this, it is not a bad idea, to increase the level of security, to issue a new CRL every times that a certificate is revoked. - CA-node interface (172.16.1.63/ca-node)

Figure 73: Enroll the new CRL to the RA

The new CRL is then exported by the CA in doing the operation "Enroll CRLs to a lower level of the hierarchy". This option stands always in the section "Administration", "Data exchange". The generated file must be copied in RA's path.

14.3 Publication by RA administrator - RA-node interface (172.16.1.63/ra-node)

Figure 74: RA downloads the new CRL

Last step of the revocation's process is the import of the CRL in RA's database in order to publish it. So this is the last very important step to accomplish the revocation of the certificate. RA's administrator will go in "Administration", "Data exchange" section and select "Download CRLs from a higher level of the hierarchy". The web server is then restarted in order to consider the new changes. At this stage, the certificate is revoked and this status is also considered in this way from the application. In other words, from this moment the client that will present this revoked certificate to the application will not be authenticated anymore.

Page 109: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 109/204

15. WEB SERVER The web server also needs to have its certificate. Indeed, when the client connects to the web site, he would like to have the possibility to check web server's certificate in order to be sure of the validity of the web site. Thus, there is like a handshake of information between the client and the server, each one presenting his certificate and checking the certificate of the other entity.

15.1 Generation of web server certificate The certificate of the web server is generated directly on the web server. Indeed, it is not the same mechanism than a client certificate. This certificate is then generated in command line, thanks to openssl. The command is requested from /etc/apache2 directory:

openssl req –newkey rsa:1024 –keyout webserver.key –out webserver_req.csr This command generates a private key of 1024 bits with rsa encryption that is stored in webserver.key file. The other generated file (webserver_req.csr) is composed of the certificate and the public key. At the request of this command, some parameters need to be filled in order to define the certificate. Here are these parameters: - PEM passphrase : webITSSPA - Country : IT - State : Lombardia - Locality : Milano - Organisation : IT Software - Organisation Unit : IT Software PKI - Common Name : 172.16.1.238 - Email : [email protected] - Challenge password : itsweb - Optional company : - The challenge password is useful to protect the webserver_req.csr file, containing the certificate and the public key.

15.2 Signature by the CA

A PKI infrastructure is built in order to authenticate in a bigger depth the entities. The web application will check if the certificate is issued by the same CA and if it is in valid status. In opposite, it is also important that the client connecting to the web application is sure not to connect to a fake web server. From this perspective, the certificate of the web server has to be signed by the CA to be valid for the client.

Page 110: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 110/204

Thus, the file webserver_req.csr needs to be sent to the PKI in order to be signed by the CA. Here are the steps that are necessary to effectuate this operation: 1 - The file webserver_req.csr is transported on RA's server thanks to an USB key. 2 - RA's administrator goes on public interface (https://172.16.1.63/pub) and selects "User",

"Request a Certificate" and "Server Request". 3 - The form is filled with the same information that has been specified for the generation of

the certificate with openssl. The first element of the form indicates where to find the file webserver_req.csr. The web server's certificate is downloaded by RA in PKCS #10 format26. Then, it is important to set the role to Web server.

Figure 75: Form filled for the signing of an existing certificate (web server's certificate)

4 - RA's administrator goes then on RA's interface (https://172.16.1.63/ra). The process of

request a certificate is then followed. 5 - At the end of the request process, the CA issues the certificate and the certificate in PEM

format is generated. 6 - CA's administrator copies then the web server certificate in PEM format onto an USB key

device, for example. cp /usr/local/openca/ca/var/crypto/certs/1A.pem /media/USB key 7 - This USB key is then plugged on web server's host and the PEM certificate is copied in

/etc/apache2/ file, and renamed in webserver.pem in order to be more relevant. 8 - Finally, the apache configuration file needs to be updated. In /etc/apache2/sites-

available/default-443 these two lines are inserted. SSLCertificateFile /etc/apache2/webserver/webserver.pem

26 Annex 1 – PKCS Standards

Page 111: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 111/204

SSLCertificateKeyFile /etc/apache2/webserver/webserver.key When the apache is started thanks to the command /etc/init.d/apache2 start, web server's certificate's PEM passphrase is requested in order to protect the private key of web server's certificate. root@sam-laptop:/etc/apache2/sites-available# /etc/init.d/apache2 start * Starting web server (apache2)... [Tue Dec 04 14:53:24 2007] [warn] NameVirtualHost 172.16.1.238:443 has no VirtualHosts Apache/2.2.3 mod_ssl/2.2.3 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons.

In order to read them you have to provide the pass phrases. Server benvm:443 (RSA) Enter pass phrase:

OK: Pass Phrase Dialog successful. [ OK ]

At this stage, the web application is based on valid certificate issued by the same CA that issues certificates for the clients.

Page 112: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 112/204

16. File formats During the whole process of attribution and revocation of certificates, different kinds of file format are generated by OpenCA authorities. It was important to note this because some operations that are executed in background use one kind of format while another function uses another type of format. Some functionalities needed to be added to the base of OpenCA in order to manage the certificates in a better way. Because of these extensions brought basics OpenCA's functions into play, it was important to know which kind of format the related OpenCA's function needed. Here is a brief explanation about the formats and in which occasion they are used.

16.1 ASN.1 (Abstract Syntax Notation One)

ASN.1 is a standard and flexible notation that describes data structures. This standard, which can also be found in X.509 standard, is used for represent, encode, transmit or decode data. It provides a set of formal rules for describing the structure of objects that are independent of machine-specific encoding techniques and is a precise, formal notation that removes ambiguities.27 Data architecture of ASN.1 can be found in the RFC 2459 named "Internet X.509 Public Key Infrastructure - Certificate and CRL Profile". A source file will have .asn extension and will use an object class representation in order to characterize certificates. The notation offers a large choice of predefined types such as:

- INTEGER - BOOLEAN - IA5String, UniversalString, etc. - BIT STRING - Etc.

and allows defining composed type such as:

- SEQUENCE => Data type that individuated a list of zero or more elements that are ASN.1 typed.

- SEQUENCE OF => Same as SEQUENCE but introduces the concept of dynamical "array".

- CHOICE => Used to model a variable, which type is selected from time to time inner a collection of alternatives types.

- Etc.28 Here is an example of ASN.1 architecture describing in this case, the basic certificate fields: Certificate ::= SEQUENCE {

27 http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One 28 http://www.diit.unict.it/users/flicandro/Materiale/ASN1.pdf

Page 113: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 113/204

tbsCertificate TBSCertificate,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING }

TBSCertificate ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version shall be v2 or v3

subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version shall be v2 or v3

extensions [3] EXPLICIT Extensions OPTIONAL

-- If present, version shall be v3

}

Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {

notBefore Time,

notAfter Time }

Time ::= CHOICE {

utcTime UTCTime,

generalTime GeneralizedTime }

UniqueIdentifier ::= BIT STRING

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING }

ASN.1 describes the syntax, the architecture of data but does not restrict how files will be encoded. Thus, ASN.1 is used with many different encoding mechanisms. Indeed, two formats used in OpenCA to encode files are based on ASN.1; .DER and .CER.

16.2 Files generated by the PKI

Here is a brief view of the different formats that generates OpenCA, in order to be interoperable with a maximum of applications.

Page 114: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 114/204

16.2 1 .DER (Distinguished Encoding Rules) This is an encoding method used for signature calculation; the certificate is encoded using the ASN.1 distinguished encoding rules (DER)29. This format plays the role of intermediary between the architectural description (ASN.1) and the file that will be able to be executed by an application. Elements ANS.1 encoded with DER are triplets of tar/length/value represented by a sequence of bytes. Openssl permits to see a certificate encoded in DER thanks to the command:

openssl x509 –inform DER –in certificate.der –noout -text This format is among others used to generate CA certificate and CRL.

16.2.2 .CER (Encoded Certificate) CER and DER are almost equivalent because they are both based on BER (Basic Encoding Rules). But there is a difference in the set of restrictions that they place on the encoder. DER uses definitive length form when CER uses indefinite length form. Because of this, CER requires less metadata for large encoded values. Openssl also owns a command that allows using certificates that are encoded with CER. The unique standard use of this format in OpenCA is for CA certificate.

16.2.3 .PEM (Privacy-enhanced Electronic Mail) PEM format defines a printable encoding scheme that uses Base 64 encoding to transform an arbitrary sequence of octets to a format that can be expressed in short lines of 7-bit characters, as required by transfer protocols.30 PEM specifications can be found in RFC 1421. This kind of format has been thought for mail applications because DER format, for example, is not optimal for these ones. A certificate in PEM format is enclosed by two markers; BEGIN CERTIFICATE and END CERTIFICATE. Here is a part of a certificate encoded in PEM: -----BEGIN CERTIFICATE-----

MIIGhjCCBG6gAwIBAgIBIDANBgkqhkiG9w0BAQUFADB2MQswCQYDVQQGEwJJVDEU

MBIGA1UEChMLSVQgU29mdHdhcmUxGDAWBgNVBAsTD0lUIFNvZnR3YXJlIFBLSTEP

MA0GA1UEAxMGSVRTU1BBMSYwJAYJKoZIhvcNAQkBFhdzLmdoZWxsZXJAaXRzb2Z0

d2FyZS5pdDAeFw0wNzEyMDcxOTQyMTFaFw0wODEyMDYxOTQyMTFaMIGGMQswCQYD

QtWPU/BZS3641wd8fIXx9BUE1obqq3/Rw3nXsEXgCu3lCNPDf5NeCTZsvOTq5FxY

D720fM07UOL0p0vLBu5oWklYYy877Ol5V9f7yz6Ia6oDllGrP3E6jBr21Sl51XFd

+U46XaJueD5dZTFN4BjitmbFXHyZ0UetcrhT2wmLi/VgAeTwRrlbhsf1

-----END CERTIFICATE-----

29 RFC 2459 – Internet X.509 Public Key Infrastructure – Certificate and CRL Profile 30 http://en.wikipedia.org/wiki/Base64

Page 115: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 115/204

16.2.4 Others formats Besides, there are others formats that are used in OpenCA like CRT format is used to specify data types that are incorporated in a signed certificate. This kind of format is used for CA certificate. CRL format is specific to CRLs. But this latter is also generated with other extensions.

16.3 Mostly used PKCS formats to exchange data

Many different formats are used in OpenCA to guarantee a good result in the exchange of data between entities.

16.3.1 PKCS # 7 This is used to encrypt or sign information under a PKI. PKCS #7 can for example be used in answer of a signing request in PKCS # 10 format.31

16.3.2 PKCS # 10 This format is the one that is used when a signing request is delivered to a certification authority. This format has been used to sign the web server certificate that was not directly generated by the certification authority. This process allows then to establish a relation of trust between the CA and a certificate that is not issued by this CA.32

16.3.3 PKCS # 11 This kind of format is used for the storage of certificates onto tokens. For example, in the case of Match On Card where the certificate is stored onto a smartcard, the necessary format will be PKCS #11.

16.3.4 PKCS # 12 This format allows reassembling in a unique file a key-pair (private/public), the relative certificate and the signatory certificate of the whole chain of certification until root certificate. This format is very useful to install a user's certificate in a web client.

31 RFC 2315 Cryptographic Message Syntax 32 RFC 2986 Certification Request Syntax Specification

Page 116: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 116/204

17. Interoperability inter-PKI Here comes a very important point, which is the interoperability of the PKI. The reasons that motivated this reflection were to know if it was possible that many different PKI issued by different software could coexist. For example, if a CA issued by OpenCA could work with a RA issued by Microsoft CA, another issued by OpenCA and a last one issued by another organization. At this day, this possibility is not realized in this thesis but it's important to be extendable in a project. Indeed, such a situation can take effect when the company works on different continents for example. The fact to have more than one RA takes all this importance in this case. And then, everything cannot be controlled. Perhaps that for some reasons, a Microsoft RA is better while in another place the OpenCA is selected. So, in a worry of portability and extendibility, it was important to understand if it was possible to mix different PKI systems. The certificates emitted by OpenCA are based on ASN.1. Thus, these certificates allow interoperability between different PKI that also bases the structure of their certificate on ASN.1. Here are the necessary steps in order to make it work:

1- RA certificates are issued with the respective software (OpenCA, Microsoft CA, etc.) 2- The certificate is stored over a device like an USB key, with the format .csr. 3- The USB key is then transmitted to the administrator in order that he cans download it.

On public interface ("User", "Request a certificate", "Server Request") 4- Then, a form needs to be filled where the certificate is uploaded and the correct role of

the certificate is specified (here RA role). 5- Then the normal process of certificate attribution follows. 6- The certificate is downloaded on a device and sent to RA's administrator, who will at

this moment be able to use its certificate as a RA. The whole question stands in the trust that the root CA gives to other RAs. If the RA is trusted and then the CA signs RA's certificate, the RA becomes totally functional in the architecture. And at the end, the whole chain will be trusted by the CA, independently of the PKI's software used. That is also a reason why there are different format types to save and store a certificate. Indeed, it makes easier the interoperability between different systems. Moreover, this argument opens a new interesting point. Indeed, there are a lot of assets in building a private PKI. Unfortunately, there are also some disadvantages. One of them is the fact that the private PKI won't be recognized as trusted by browsers. In opposite, public PKI are automatically inserted in the trusted organizations in the browsers. This is a very good argument because when a user connects to an URL that requires the check of the authority certificate, and the latter is already trusted, nothing is asked to the user. Indeed, the control is done in the background without that the user can notice it.

Page 117: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 117/204

In opposite, when a private PKI is used to authenticate web pages and users, a window will always appear to the user in order to warn him that the site is not trusted. This even if the user has decided to trust the site and has stored the CA certificate in his browser's preferences.

Figure 76: Warning of a non-trusted authority

This is clear that it becomes a bit irritating for a user to always have to click on "OK" to this window in order to access a web application. A solution could be to do an arrangement with a public authority (Entrust, Verisign, etc.), which are trusted by every browsers, in order to have a private PKI that would be trusted by a public one. This could be realized in requesting a CA certificate from a public PKI. This certificate will play the role of root CA that will trust every certificate below it. The architecture would look like this:

Figure 77: Private PKI trusted by a public one

Public authority that trusts

the whole below structure

Private authority that manages the certificates

Page 118: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 118/204

By building such a structure, the whole certificate's management is effectuated inner IT Software, without the public authority's intervention. Thus, the clients will be managed by IT Software only and it has to be like that. A solution could be to buy a certificate from a public authority that would play the role of Root CA. This Root CA certificate would sign IT Software's CA certificate. By doing like this, every certificate that would have been issued by IT Software's CA would have the public root CA as root CA and would then be trusted by the public authority. Thus, a study has been done in order to understand if it was feasible. Two big companies have been contacted by email. One of them answers back without being extremely clear but after some exchanges of information, it appears that something was possible to do. But the problem resides in the business argument. Indeed, the public authority could surely not sell a certificate that would play the role of root CA. If that was the case, this process will be more popular. A price should be defined depending on how many certificates the private PKI would issue and manage. This point could be very interesting to be deepened by IT Software, in order to deliver certificates that would be automatically trusted by every browser.

Page 119: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 119/204

<Building and Realization>

Page 120: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 120/204

18. Application check of validity of the certificate with the CRL How the application will check validity of the certificate is very important. Various solutions can be implemented. Indeed, three solutions have been taken into consideration in the project:

- Request to a LDAP directory - Request to a CRL - Request to an OCSP responder

18.1 Integration mode with the actual infrastructure To verify this, a basic html page has been created in order to see if the user was authenticated or not thanks to his certificate. The actual authentication method, for the user, is based from a standard login/password. The module that manages this login and password is totally independent. Thus, the verification of the certificate can be done independently. If it works, actual server would need some adjustment but the login/password module wouldn't change. Thus, the web application could use a login/password module and a certificate to validate the access to a user.

18.2 Request to a LDAP directory

LDAP is also a format that is based on ASN.1. There are 3 versions of LDAP and two of them are still used. A LDAP directory has a structure that can be compared to a tree. Indeed, the root CA stands at the top of the hierarchy and at the bottom, the clients can be found.

Figure 78: Example of LDAP directory hierarchy (source: http://www.dia.unisa.it/~ads/corso-security/www/CORSO-0203/LDAP/IMAGE/ALB2.gif)

Page 121: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 121/204

The Distinguished Name (DN) is the entry of an element and the CA of this project would have this as DN:

CN=ITSSPA,OU=ITSoftwarePKI,O=ITSoftware,C=IT The major weak point of this technique is how two different LDAP directories can interact. For example, if a LDAP is built in order to store the X.509 certificates, the latter may also need to interact with other information that could be stored in a LDAP directory generated by a Microsoft IIS33, for example. This point could be overcome because of some restrictions in LDAP configuration that manages to obtain a good level of interoperability between, for example as mentioned before, an IIS LDAP and a X.509 LDAP. But, this depends on many points and the interoperability is not guaranteed. A big problem is the redundancy, which could be inevitable, of having to repeat operations in both directories. Thus, the work would be doubled every time that a new element is created, updated or deleted. For this reason, the solution cannot be chosen to check validity of the certificates. In the future, it could be interesting to make some tests of interoperability between LDAP directories already existing in IT Software and OpenCA's LDAP directory. If the results were satisfying, this kind of process could be considered. But in the project, a less heavy method is advocated in order to have a better chance in reaching the goal of an efficient working environment, which doesn't necessarily mean to be less reliable.

18.3 Request to a CRL

Another good form to check the validity of a certificate for a web server is to question a CRL with the serial number of the certificate as parameter. In this case, the web server has the CA certificate and can check whether the client's certificate that is presented is issued by the same CA. Then if client's certificate is not in the CRL list, it means that the certificate is not revoked and the web server will then authorize the access to the user. This operation always brings satisfying results in test bench but in the future, when the solution will be deployed, this method can be enhanced in terms of resource's optimization. Indeed, with such a mechanism, the CRL is stored directly on the web servers that have to check certificate's validity. Ideally, a new CRL is issued every time that a certificate is revoked. Every time that a new CRL is issued, this CRL has to be exported to every web server that needs to check the validity of certificates. This operation can be a bit redundant to do regularly. An idea could be to insert a flag on RA's server that shows a change of state when a new CRL is emitted. The web server could have a script that runs in the background and ask continuously if RA's flag has the value that means that a new CRL is available. If this is the case, the web server would automatically download the new CRL. The web server must also be restarted in order to consider the new CRL. This can be done thanks to the command

33 Microsoft Internet Information Services is a set of Internet-based services for servers using Microsoft Windows

Page 122: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 122/204

/etc/init.d/apache2 restart. The pass-phrase protecting the certificate of the web server is then requested. But another problem of downloading the CRL directly on interested web server is a matter of traffic on the internal network. The CRL is supposed to become bigger and bigger and it is easy to understand that a constant downloading of a big file can reduce the bandwidth and affect the performance of internal network. Tests showing the behavior of the system using this technique are presented in section 22. Behavior of the system with certificates. The Apache configuration file for CRL validity checking process can be found in Annex 5 – Apache configuration for web server (check validity with CRL).

18.4 Request to an OCSP responder

In lieu of or as a supplement to checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of a certificate.34 A good way to avoid these exchanges of CRL is to set up a process that is based on OCSP protocol. A new element of the PKI is then introduced; the Validation Authority (VA). OpenCA project has an external module that is called ocspd ("d" for daemon). This daemon will run permanently on VA's server and this node is called the OCSP responder. On the other side, the OCSP client will be played by the web server that has to check the validity of a client certificate asking for access on web server. In this way, the CRL stands only on VA's server without the need to upload it to web servers. The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responder provides a response.35

34 RFC 2560 - OCSP 35 RFC 2560 - OCSP

Page 123: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 123/204

Figure 79: User authentication thanks to OCSP validation process

The above figure shows each entity that takes part in this project. The objective here is to explain the validation process between Web Application Server and VA realized when a user tries to access the Web Application Server in presenting a certificate. So the points regarding OCSP process are located from point four to point seven. 1 - Certificate generation for the user. 2 - The files needed in order to succeed in OCSP request, like the certificate of the CA

(cacert), are uploaded to Validation Authority Server. This VA takes the role of OCSP responder and the OCSPdaemon is stored on this server.

3 - Issuing and transmission of the valid certificate to the user. 4 - This point includes various steps: - User tries to access web application. - Web Application Server sends to the user its certificate so the user can check the

validity of Web Application Server's certificate. - If the user accepts to trust this certificate, user sends his certificate to Web

Application Server. 5 - Web Application Server, which is the OCSP client, sends an OCSP request to OCSP

responder, with user's certificate in parameter. 6 - OCSP responder sends an answer to OCSP client. 7 - Depending on the answer received by OCSP client, Web Application Server authorizes or

not the access to the user. Regarding the point five, an OCSP responder will return a signed response indicating whether the checked certificate is "good", "revoked" or "unknown". The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate is not revoked, but does not necessarily mean

Page 124: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 124/204

that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. The "revoked" state indicates that the certificate has been revoked (either permanently or temporarily (on hold)). The "unknown" state indicates that the responder doesn't know about the certificate being requested. There are some others advantages in using this mechanism compared to CRLs:

- Reduction of traffic with better bandwidth management. - Up-to-date information regarding revocation status. With OCSP, there is not the

critical delay between the time of revocation of certificate and reception of this notification by the CRL on the web server.

- No need on behalf of the client to personally check the CRL, a sometimes complex operation.

- The CRL can be considered as a black list, a list of bad clients. It can become a public exposure issue for the clients that have this tool in hand. But in the case of this project, the clients have abstract names and this argument is then not considered.

Some products from commercial organizations like Tumbleweed for example, exit and can resolve the OCSP mechanism. The only problem is the price of the product that can start from USD 2000 and growing up according to the enterprise that provide the product. It is clear that these kinds of product cannot be considered in the project, at least in this moment, because it is a project based on open source software.

18.4.1 Building of OCSP architecture At this point, the OCSP daemon needed to be installed on VA's server. First, the daemon is downloaded from OpenCA and the version installed is the 1.5.1. Then, like every source file, it is stored in /usr/local/src. This daemon doesn't require specific configuration and it can be installed through the following operation: cd /usr/local/src/openca-ocspd-1.5.1-rc1 ./configure make make install At this stage, the files considered are stored in /usr/local/etc/ocspd/. OCSP daemon is installed but it needs to be better configured in ocspd.conf file. - First, the location of the CA certificate needs to be adjusted in consequence (ca_certificate = $dir/ca/cacert.pem), where $dir takes the value of /usr/local/etc/ocspd/. - Then, the same thing needs to be done for the crl (crl_url = file:////usr/local/etc/ocspd/crl/cacrl.pem).

Page 125: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 125/204

- The IP address of the OCSP responder needs to be bound thanks to the line (bind = 172.16.1.63). Same operation for the port where OCSP exchange will transit (port = 2561). These changes need to be done many times in ocspd.conf file. This configuration file is documented in Annex 6 – Configuration ocsp daemon. Then, it is necessary to add the correct user in order to use OCSPd application. groupadd daemon useradd –d /dev/null –s /bin/false –g daemon ocspd The OCSP responder needs some files in order to understand the request of the OCSP client. Thus, the cacert.pem and the cacrl.* are downloaded from the RA. Moreover, every time that a new crl is issued, the new version will be downloaded by the VA. In this regard, a bash script called NEWcrl has been written and its description is detailed in chapter 20.2.2 NEWcrl. Then, an important update is needed in the every certificate. Thus, some changes are needed in the following directory: /usr/local/openca/ca/etc/openssl/extfiles. Every file with the extension ".template" needed to be modified, and the following line has to be added: authorityInfoAccess = OCSP;URI:http://172.16.1.63:2561 OCSP server's certificate also needs some configuration in its openssl.cnf file: [OCSP]

nsComment = "OCSP Responder"

subjectKeyIdentifier = hash

authorityKeyIdentifier = keyid,issuer:always

basicConstraints = critical,CA:FALSE

extendedKeyUsage = OCSPSigning

crlDistributionPoints = URI:http://172.16.1.63/crl

Thanks to this, every new certificate will present the IP of the OCSP responder to query, to the web application server. It has also to be noticed that the certificates issued after this modification, display the information of authorityInfoAccess, the URI of the OCSP responder. This specification is still not in function yet but, it could become important in a probable future evolution of OCSP daemon. Thus, it has been introduced in order to have the certificates ready if this enhancement will happen. At this stage, OCSP daemon is ready, but it only needs to be started thanks to the command:

/etc/init.d/ocspd start –v (the –v option displays. This has been useful to debug the initial problems)

Page 126: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 126/204

The good initialization of OCSP daemon can be verified in watching the log files relative to the daemons, located in /var/log/. The command to observe the launching of OCSP daemon is tail daemon.log . These logs have been very helpful to debug the problems that were present at the beginning. Indeed, there were some configuration problems of the daemon at the beginning. If the daemon starts well, two messages are displayed: [date] [user] [ocspd pid]: OpenCA OCSPD v1.5.1 – starting [date] [user] [ocspd pid]: CRL loaded successfully [ITSSPA_ca]

18.4.2 Static OCSP request An OCSP request can be executed by doing a simple openssl command, in inserting some important features that the OCSP responder needs in order to understand the request. Here is for example a request made manually to verify the validity of a specific certificate that is stored in local (0B.pem here). openssl ocsp –issuer /usr/local/etc/ocspd/ca/cacert.pem –CAfile /usr/local/etc/ocspd/ca/cacert.pem –cert /usr/local/etc/ocspd/certs/0B.pem –url http://172.16.1.63:2561 –text The options issuer and CAfile indicate the path of CA's certificate. This is useful to determine which entity has signed the certificate. The cert option delivers the certificate to check. In an automated process, this option would be a variable that would take the value of the certificate presented to the web server, the certificate of the user that wants to access the web application. The url option indicates the IP address of the OCSP responder, which is listening on port 2561 for OCSP requests. Finally the option text is not mandatory; it is only useful to show with more details the transaction between OCSP client and responder. Here is the result of this request in the shortest verbosity (the option “text” (more verbose) displays the entire certificate and the answer is thus pretty long): OCSP answer for a valid certificate:

Response verify OK

/usr/local/etc/ocspd/certs/02.pem: good

This Update: Dec 3 15:12:33 2007 GMT Next Update: Dec 10 15:43:39 2007 GMT

OCSP answer for a revoked certificate:

Response verify OK /usr/local/etc/ocspd/certs/09.pem: revoked

This Update: Dec 3 15:12:33 2007 GMT Next Update: Dec 10 15:43:26 2007 GMT

Revocation Time: Oct 16 11:52:10 2007 GMT

The answer of the OCSP responder is very clear on the validity of the certificate (displayed in bold). Moreover, in the case of the revoked certificate, a precious information indicates at what time the certificate has been revoked by the CA.

Page 127: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 127/204

18.4.3 Dynamic OCSP request Obviously, the purpose of using OCSP protocol is to execute OCSP request automatically, in real-time, with user certificate in parameter so the OCSP responder can check the validity of user's certificate presented. OCSP protocol seems to exist since 1999 as it is referred in RFC 2560. The last version of the daemon of OpenCA dates from more than a year as it is described on www.openca.org site. Thus, these tools are not brand-new and a solution to make OCSP process work automatically has been searched, but in vain. Indeed, surprising though it may seem, nothing that could match with the purpose of my project has been developed at this day. A module has been found and it is called NSS_mod. Apparently, this module owns a function called NSSocsp that can be enabled. After having installed the module and begun to configure it, some doubts arose. First, NSS_mod retrieves SSL_mod functionalities, but both cannot co-exist under the same port. Then, this module seems to be too bound to Apache server. If the web server wasn't Apache anymore, it could be problematic. Thus, this direction was abandoned. In consequence, a personal module must be created. This module was written in Perl and was launched by Apache when a certificate was presented to web application server. Because of this language and of the fact that communication between the Apache server and an external module wasn't mastered, a step-by-step methodology has been chosen to achieve this functionality:

- Perl module, called OCSP.pm and referenced in , was started up and if anything needed testing, it was done by launching itself thanks to the command: perl OCSP.pm. It is obvious that it is a testing technique and that actually, the Apache server will be in charge of launching it. It was necessary to check if the syntax and the result of the script were correct.

- Once that an OCSP request was executable by the script, the chosen method was to do an OCSP request with a fixed certificate in parameter. This certificate was stored locally, in the same file of the Perl script. Then, the answer of OCSP responder is stored in a file on Apache server's host. Once it was working, the method was to check the certificate presented dynamically by the user. This can be obtained thanks to the environment variables of Apache and mod_ssl.

- The OCSP response is rather descriptive and the content of the generated file is consequently important. Thus, this file needs to be parsed in order to isolate the searched answer. OCSP.pm module executes this step correctly. Then, there were some problems in communicating this answer to Apache server.

18.4.4 Problems encountered OCSP.pm needs to be called in the apache configuration, in the section “Directory” where the check of the certificate is requested as detailed in Annex 7 – Perl module managing OCSP request to the VA. Two lines are necessary to launch OCSP.pm perl module: SetHandler perl-script

Page 128: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 128/204

Perl... Apache2::OCSP The second line launches the module and defines what type of handler it is. Without finding a working solution, different kinds of handlers have been tried whose two kind of handler that allows to approach the more the solution: PerlHandler :

The option SSLOptions +StdEnvVars +ExportCertData has been used and the last parameter allows to export the environment variables that contains information about the certificate of the client. Indeed, this parameter is essential in order to do an OCSP request.

The variable is retrieved in perl module thanks to the command $ENV{SSL_CLIENT_CERT}; that allows to capture client certificate in PEM format, which is the format used in OCSP requests. In this case, when a client tries to access the web application, the OCSP request is well done and brings back the status of the certificate. The problem is that with this technique, the value is not returned in Apache configuration in order that Apache can authorize or not the access of the client, dependently of the status of client’s certificate. PerlAccessHandler : With this kind of handler, which seems to be more appropriate, the environment variables are

not exported. Thus, the method used in PerlHandler to retrieve the variable SSL_CLIENT_CERT is not possible. So the idea was to create an environment variable in Apache but the result was the same. Thus, this solution doesn’t even do the OCSP request because perl module doesn’t have any certificate to check (client certificate that is delivered in parameter).

18.4.5 Kind of OCSP errors When an error occurs, ocsp responder answers with an error message. The existing error types are:

• malformedRequest

• internalError

• tryLater

• sigRequired

• unauthorized In the future, if the OCSP direction will be maintained, the application will have to manage these errors.

18.4.6 Security considerations

“For this service to be effective, certificate using systems must connect

to the certificate status service provider. In the event such a connection

cannot be obtained, certificate-using systems could implement CRL

processing logic as a fall-back position.

Page 129: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 129/204

A denial of service vulnerability is evident with respect to a flood of

queries. The production of a cryptographic signature significantly affects

response generation cycle time, thereby exacerbating the situation.

Unsigned error responses open up the protocol to another denial of service

attack, where the attacker sends false error responses.

The use of precomputed responses allows replay attacks in which an old

(good) response is replayed prior to its expiration date but after the

certificate has been revoked. Deployments of OCSP should carefully evaluate

the benefit of precomputed responses against the probability of a replay

attack and the costs associated with its successful execution.

Requests do not contain the responder they are directed to. This allows an

attacker to replay a request to any number of OCSP responders.

The reliance of HTTP caching in some deployment scenarios may result in

unexpected results if intermediate servers are incorrectly configured or

are known to possess cache management faults. Implementors are advised to

take the reliability of HTTP cache mechanisms into account when deploying

OCSP over HTTP.”36

After these considerations and thinking about the possible vulnerabilities, it would be necessary to define, within the enterprise, if OCSP process matches with the internal policies or if a more static technique (CRL), requesting more continuous flows, guarantuees less exposure of attacks.

18.4.7 Alternative with SCVP37 A solution could be the use of SCVP instead of OCSP. Indeed SCVP is an alternative of OCSP but the concept is pretty the same. The problem is that this technique is still in beta phase and doesn’t offer enough reliability yet.

36 Extract of RFC 2560 - OCSP 37 Server-based Certificate Validation Protocol

Page 130: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 130/204

19. Database management Certificates generated by the PKI are very sensible data that need to be protected. Thus, it was important to establish a process of backup and restore of the databases. The procedure of backup would be generated every day in being inserted in the etc/cron.daily directory, where the scripts are launched every day, and will save the two databases (openca_ca and openca_ra). In the opposite, the restore is a procedure that has to be explicitly requested. There is one process of restore for each database, which calls the relative database backed up. These bashes are located in /home/openca. BACKUP_dbs: #Backup the openca_ca database

/usr/bin/pg_dump -i -h localhost -p 5432 -U openca -F c -b -v -f

"/home/openca/Desktop/openca_ca.backup" openca_ca

#Backup the openca_ra database

/usr/bin/pg_dump -i -h localhost -p 5432 -U openca -F c -b -v -f

"/home/openca/Desktop/openca_ra.backup" openca_ra This bash allows to save both databases in two distinguished files that have been bolded. Between the numerous options, the "c" option allows to override an existing file. The pg_dump function requires an extension ".backup" for the saved file. It can be launched by executing the following command: /home/openca/BACKUP_dbs RESTORE_CA_db: #Restore CA_db database

/usr/bin/pg_restore -i -h localhost -p 5432 -U openca –c -d

"test_recover_CA" -c -v "/home/openca/Desktop/openca_ca.backup" RESTORE_RA_db: #Restore RA_db database

/usr/bin/pg_restore -i -h localhost -p 5432 -U openca -c -d

"test_recover_RA" -c -v "/home/openca/Desktop/openca_ra.backup"

This operation deletes the existing database before recreating the new one that will be composed by the backed up elements. The test of recovery has been tested in creating two new databases called “test_recover_CA” and “test_recover_RA” in order to not to risk the lost of entire data. But everything works well and it could without any problems be modified in selecting the databases that the PKI uses. In this case, in the restore bashes, “test_recover_CA” will be replaced by ”openca_ca” and ”test_recover_RA” by ”openca_ra”. To launch them: /home/openca/RESTORE_CA_db or /home/openca/RESTORE_RA_db

Page 131: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 131/204

20. Management of logs Logs are very important in computing science and a software or an application should always record events in order to provide a trail essential to diagnose and resolve problems. In this regard, logs have often been used during this project in order to successfully realize the setting up of the architecture. Apache offers two interesting log files which are located in /var/log/apache2; access.log that records the logs relative to the successful connections, error.log which, as its name can indicate, records the failed attempts. The latter was very helpful for debugging any problematic situation. But sometimes, logs weren't generous enough and some important information wasn't sufficiently detailed. In this case, there are two possibilities; generate additional logs or configure in a better way the used application. For example in Apache, some changes have been necessary in order to reach a satisfying level of description in the logs. By default, the level of log is set to "warn" and a change has been necessary in the configuration of Apache has been executed, more precisely in the file default-443. The LogLevel needs to be set to "debug". This specification permits among others to write the serial number of the revoked certificate presented, which is very useful for diagnosing some problems. Here are the updates: ErrorLog /var/log/apache2/error.log (indicates the path of error.log)

#Possible values include: debug, info, notice, warn, error, crit, alert, emerg. (Here, the level of logs in terms of quantity reaches its maximum in "debug" and it decreases going to the right up to "emerg".)

LogLevel debug (The chosen level is then set to "debug", which is the maximum level of

quantity of logs. This parameter is for error.log file). A revoked certificate (here certificate serial number “28” or “1C” in hexadecimal) trying to access the application is detected thanks to the following log generated in error.log: [Fri Dec 07 21:13:10 2007] [info] Certificate with serial 28 (0x1C) revoked

per CRL from issuer /C=IT/O=IT Software/OU=IT Software

PKI/CN=ITSSPA/[email protected]

20.1 Add logs The information displayed in access.log wasn't satisfying enough. A log was generated when a user was authenticated thanks to his certificate but it wasn't very explicit. Indeed, there was no information about the serial number of the certificate, for example. Information that is important because with it, the administrator can trace who has accessed. Thus, something has been done to create an additional log that will write this kind of data.

Page 132: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 132/204

In Apache configurations, it is possible to specify some new logs thanks to the CustomLog command. Thus, a new log has been set in order to display the serial number of the authenticated certificate. CustomLog /var/log/apache2/access.log "%h %t Client with certificate's

serial number %{SSL_CLIENT_M_SERIAL}x has been authenticated %u %x \"%r\"

%b"

This command, following the same format as the other ones already existing, generates a log that write the host, the time and the text indicating which certificate has been authenticated, using the SSL_CLIENT_M_SERIAL environment variable that delivers the serial ID of the certificate. Thanks to this tool, now, when a user will be authenticated (here the user with certificate serial number “0B”), the following log will be generated in access.log file:

172.16.1.238 [07/Dec/2007:21:10:20 +0100] Client with certificate's serial

number 0B has been authenticated - - "GET /TEST_CERTIF/logo-its.jpg

HTTP/1.1" 1224

There are a lot of possibilities of adding log using client's certificate information. Indeed, mod_ssl, which has been installed, offers different variables that can do this. Thus, other logs could be added in the future if special information is needed, in using the following environment variables offered by Apache and mod_ssl:

Variable Name: Value Type:

Description:

HTTPS flag HTTPS is being used.

SSL_PROTOCOL string The SSL protocol version (SSLv2, SSLv3, TLSv1)

SSL_SESSION_ID string The hex-encoded SSL session id

SSL_CIPHER string The cipher specification name

SSL_CIPHER_EXPORT string true if cipher is an export cipher

SSL_CIPHER_USEKEYSIZE number Number of cipher bits (actually used)

SSL_CIPHER_ALGKEYSIZE number Number of cipher bits (possible)

SSL_VERSION_INTERFACE string The mod_ssl program version

SSL_VERSION_LIBRARY string The OpenSSL program version

SSL_CLIENT_M_VERSION string The version of the client certificate

SSL_CLIENT_M_SERIAL string The serial of the client certificate

SSL_CLIENT_S_DN string Subject DN in client's certificate

SSL_CLIENT_S_DN_x509 string Component of client's Subject DN

SSL_CLIENT_I_DN string Issuer DN of client's certificate

SSL_CLIENT_I_DN_x509 string Component of client's Issuer DN

SSL_CLIENT_V_START string Validity of client's certificate (start time)

SSL_CLIENT_V_END string Validity of client's certificate (end time)

SSL_CLIENT_A_SIG string Algorithm used for the signature of client's

Page 133: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 133/204

certificate

SSL_CLIENT_A_KEY string Algorithm used for the public key of client's certificate

SSL_CLIENT_CERT string PEM-encoded client certificate

SSL_CLIENT_CERT_CHAINn string PEM-encoded certificates in client certificate chain

SSL_CLIENT_VERIFY string NONE, SUCCESS, GENEROUS or FAILED:reason

SSL_SERVER_M_VERSION string The version of the server certificate

SSL_SERVER_M_SERIAL string The serial of the server certificate

SSL_SERVER_S_DN string Subject DN in server's certificate

SSL_SERVER_S_DN_x509 string Component of server's Subject DN

SSL_SERVER_I_DN string Issuer DN of server's certificate

SSL_SERVER_I_DN_x509 string Component of server's Issuer DN

SSL_SERVER_V_START string Validity of server's certificate (start time)

SSL_SERVER_V_END string Validity of server's certificate (end time)

SSL_SERVER_A_SIG string Algorithm used for the signature of server's certificate

SSL_SERVER_A_KEY string Algorithm used for the public key of server's certificate

SSL_SERVER_CERT string PEM-encoded server certificate

Figure 80: Apache variables

(Source: http://httpd.apache.org/docs/2.0/mod/mod_ssl.html)

20.2 Bash scripting

Bash scripts are Unix shells written in order to be executed. Their scope is to be launched and the command lines that are written in it will be executed. This is low-level scripting but it is possible to automate some operations. Some scripts have been written in order to enhance the level of management of the PKI.

20.2.1 ALERT An interesting point of management has been thought which can open to others ideas. Indeed, it would have been bad not to use this information source. For example a script shell has been written in order to alert the appropriated administrator when a user tries to connect the web server with a revoked certificate. First, the idea was to send the mail thanks to telnet but after a couple of tries, some problems of configuration have happens. Indeed, the server doesn't allow to relay the mail from inner.

Page 134: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 134/204

By the way, another solution has been searched and has been found. Indeed a command called "mailx" exists and permits to send an email thanks to sendmail, which is a MTA38 available on Linux. Sendmail is also the used function in OpenCA to send mails. Its functionality, as its name indicates is to transfer electronic message from one host to another one. Sendmail is criticized for its slowness, but it is one of the most popular. Moreover, the rapidity of sending an email, in this case, is not fundamental. Furthermore, the mail is sent in inner. Thus, the object will pass through only one MTA and then, the time is reduced. In conclusion, sendmail is widely sufficient for the needs of this project. Some changes are necessary in order to configure the hostname and the domain name in the correct way. Indeed, if it is not done, sendmail will not accept to forward the mail due to an error like "Unknown User". The file that needs to be modified is /etc/hosts. These three lines needed to be added at the beginning of the file:

127.0.0.1 localhost 127.0.0.1 openca-desktop.openca-desktop.it openca-desktop 172.16.1.63 openca-desktop.openca-desktop.it openca-desktop

Some different temporary files are necessary for this script. The script ALERT, which allows alerting the administrator when a revoked certificate tries a connection on the web server is available in Annex 8 – ALERT bash script. The necessary command to launch the bash is: /var/log/apache2/ALERT This script is then an executable and the rights of every files used in this script needs to be set in a way that they are writable for every user. This is necessary because the mechanism is launched by the web server. The permissions of a file can be changed with the following command: chmod 777 ALERT chmod 666 every_file_used_by_ALERT An explanation is necessary here in order to comment the command above. The number is divided in three. The first stands for the owner of the file. The second represents the group's members and the last number is for the others. Afterwards, each number represents three kind of information displayed in binary. For example, the first 6 represents, for the owner of the file, permissions of read and write, because 6 in binary is equal to 110. First position ('1') => read => ok Second position ('1') => write => ok Third position ('0') => execute => not ok (this is not an executable file) Thus, chmod 666 means read/write permission for every users and chmod 777 means read/write/execute permissions to every user.

38 Mail Transfer Agent

Page 135: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 135/204

20.2.2 NEWcrl This script has been written for OCSP management. Indeed when a new CRL is emitted and then published by the RA, the OCSP responder also needs to have this last version of CRL. Thus, NEWcrl script has been written in order to detect when a new crl is issued and when it is the case, to copy all the cacrl.* files in an accessible directory for OCSP responder, on VA's server. Indeed, if this operation is not effectuated, the OCSP could not access the directory where the CRLs are stored by default, for right’s reasons. The NEWcrl bash script is detailed in Annex 9 – NEWcrl bash script. The file is located in the directory /usr/local/openca/ca/var/crypto/crls and the command to execute it is then /usr/local/openca/ca/var/crypto/crls/NEWcrl

20.2.3 CRLexpire An interesting problem has been simulated during this project. CRL's delays of expiration were purposely set to a weak number of days. This was done in order to see the behavior when such a situation occurs. This operation has also be done on the certificate of apache, on CA' side. So, the test was to watch the behavior of the system in the case of the last CRL is expired and the apache server's certificate is also expired. Here is a view that is seen by a client when the web server's certificate has expired. This is a situation that is to avoid because this kind of messages are not very inviting for a client.

Figure 81: First "Internet Explorer" and then "Firefox" warnings about the expiry of web server's certificate

Thus, with such a situation, OpenCA's interface was no more accessible for CA's administrator. The first operation was to regenerate a new apache server's certificate fixed with a period validity of 1000 days with the make-ssl-cert command. But this step was unsuccessful. So the restrictions on users in default-443 have been deactivated for a moment. During this time were CA's interface was less protected, a new CRL has been issued, after

Page 136: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 136/204

that the protection has been restored. This means that for a few minutes, CA interface was accessible for everybody from the inner of the enterprise, even if the interface was still protected by CA's login and password. Even if risk is not very marked, because the only risks would come from the inner, every risk should be reduced at the minimum. This is then a situation that is absolutely to avoid in terms of security. To resolve this problem, an idea was to do a script that will generate automatically a CRL every 'x' days. The problem here in doing this is an evident problem of security. Indeed, the script that will do this will need to access the CA, and then to enter CA's login and password. Thus, CA's login and password would be written as constant in the script. If the script is then intercepted by someone, or if some malicious code is inserted in it, the whole architecture would be no more reliable. Thus, the fundamental point of security that is needed in a PKI environment wouldn't exist anymore. This solution is then to avoid, and unfortunately for the administrator, this step should be executed manually. A solution to solve this problem is to increase a little bit the duration of validity of the CRL. Then, an email could be sent to CA's administrator every month, to remember him that it would be better to issue a new CRL. This in the case where no CRL is issued during an entire month (no certificate revoked). This can be easily done in doing a little script that will send an email to recall this task to the administrator. This script could be placed in /etc/cron.monthly where the scripts are executed once every month. This script is called CRLexpire and its content stands in the only command: mailx –s "Recall : Please issue a new CRL" [email protected] < /var/log/recallCRL.txt The totality of the script can be analyzed in Annex 10 – CRLexpire bash script and the script can be launched by writing /var/log/CRLexpire in the shell.

Page 137: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 137/204

21. Biometrics deployment The introduction of a strong authentication mechanism that mixes PKI certificates and biometrics was interesting. Before working on this aspect, the subject has been discussed with the enterprise in order to understand the place that would take this kind of strong authentication. IT Software finds this technology very interesting in terms of security. But the problem is that there is not the wish to make the client pay for this additional element if this one doesn't find it necessary. Thus, this strong authentication won't take place in the principal package proposed to the client. But, if the latter desires to introduce it in order to increase the level of security, it would be possible.

21.1 Match On Card

Definition of matching: The process of comparing input biometric information with a template. The greater the degree of conformance, the better the match.39 The technology Match on Card or MOC allows managing every biometrical operation on a smartcard. This technology helps to reach a high level of security but it permits also to keep the private data protected. There is no possibility that some biometrical information can be outputted from the card. Indeed, only the cryptographic processor of the smartcard can manage these kinds of data. Thus, the private key is stored in a secured way onto the smartcard.

Figure 82: Match On Card process (Source: http://fr.wikipedia.org/wiki/Match_on_Card)

39 Technical glossary from http://precisebiometrics.com/?id=414

Page 138: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 138/204

The process is divided in two different parts: the reader and the smartcard. The reader will attend to acquire data and extract it. The smartcard will compare the matching between the fingerprint in database and the one that asks to authenticate.40 A system like MOC can be added to the process of authentication in the situation where a PKI infrastructure is built. In this special case, X509 certificates and biometric element are the keys of authentication. In such a case, it can be said that the system is based on a very strong authentication mechanism: a smartcard and a finger as PIN code.41 Example of MOC reader:

Figure 83: Exemple of MOC reader

(Source: http://fr.wikipedia.org/wiki/Match_on_Card)

The efficiency of this product seems to be a very attractive solution in order to guarantee a very strong authentication. As it could have been written before, security is very important and strong authentication must absolutely be taken in consideration when used with application that deals with sensible data. Generally, another point that is very important for enterprises is the cost for each new product. For example, a quick research has been realized on the product presented above. The choice of the fingerprint reader is pretty large but if a venture wants to equip its system with this MOC reader, a contribution starting from about one hundred and fifty euros per fingerprint reader has to be paid. For this chapter, some technical support regarding MOC has been provided generously by e-Xpert Solutions.

21.2 Fingerprint reader

The fingerprint reader has been used for more than six years and the device can be considered a little obsolete even though it is obvious that some progress has been done over this reader. The used reader is still on the market even if it is described as end of life on precise biometrics web site, but the product has evolved on different parameters which are precision of capture, rapidity of processing, etc. Moreover, the choice of the fingerprint reader largely depends on the performance expected. But, the used reader is still competitive and suits such a project.

40 http://www.e-xpertsolutions.com/images/pdf/moc/3_BiometricMOC.pdf 41 http://fr.wikipedia.org/wiki/Match_on_Card

Page 139: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 139/204

Here are some specifications of the used fingerprint. It is true that these parameters represent the new generation of readers but it allows to get an overview of the performance that can be obtained by this kind of fingerprint reader: Name: Precise 100 MC (Combined fingerprint and smart card reader for computer security)

• Optimized Precise Match-on-Card performance

• High speed smart card operations capacity • Real-time fingerprint image capturing

• Plug'n'Play installation • Low power consumption - less than 0.5 mA when not active

• Dual-color LED indicator for user interaction

General

• Size: 92 x 61 x 19 mm • USB connection

• CE certified - ISO9000/1 and ISO14001 production certified • Drivers: Windows® 98 / Windows® Me / Windows® 2000 / Windows® XP

Biometric Reader

• Silicon fingerprint sensor • Capturing of up to 6 fingerprint images/second

• Image encryption

Smart Card Reader • Up to 250 kbit/s communication speed

SYSTEM REQUIREMENTS

• Windows® 2000 or Windows® XP

The only negative point that emerges from these specifications is that this kind of product is not compatible with a Linux or Mac OS. This option is only available with enhanced device as the 200 MC or the 250 MC. Moreover, the smartcard that is used isn't Linux compatible. Thus, because of the RA is on a Linux OS, if IT Software decides to send the certificate with the key pair to the client already on the smartcard, an administrator would have to backup the certificate on a token as explained in chapter 11.5.1 Export certificate onto a token. In this case, the certificate will be copied on the smartcard, on a host that runs over Windows.

21.3 Smartcard The smartcard will own a certificate with the key pair. The smartcard is introduced in the fingerprint reader so only one device with two factors of authentication is used. The choice of the smartcard was important because there are several kinds of smartcard that don't offer the same functionalities. After having discussed this problematic with experts in this area, an Athena Smartcard has been chosen. Athena is an enterprise that develops innovative solutions in the smartcard world, which can allow

Page 140: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 140/204

logical or physical access. Between the large choice of smartcards that they deliver, Athena offers an identification device that permits to store PKI certificates. This smartcard is based on a special Athena smartcard OS and uses a middleware42 written in Native43 or Java. With this kind of smartcard readers there are two possibilities of authentication: either a PIN code or the use of fingerprint. In this part, the main focus is on the biometric aspect. 44

21.3.1 Installation The driver of the smartcard needs to be installed. The software used is the ASECard Manager Tool Version 4.0. Driver Precise Biometrics 100 Drivers 2.6.045 has also been downloaded because without it, the reader couldn't be recognized by the operating system. Then the ASECard Personalization Tool has been started in order to start the enrolment of biometric data (ASECard Crypto Toolkit ->ASECard Personalization Tool).

Figure 84: Set up of Smartcard configuration

The icon "Biometric GINA" needs to be selected so that the smartcard can work with biometric authentication.

21.3.2 Profiles After the configuration and the installation of this tool, some modifications are needed in the ASECard Personalization Tool.

42 Software located between the application working on different OS 43 Low-level code written in such a way to work over a specific processor. 44 http://www.athena-scs.com 45 Available on http://www.precisebiometrics.com/?id=1041

Page 141: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 141/204

Figure 85: Profile configuration

PIN profile The default profile is selected thanks to the tab "Manage Profiles". Then, the default profile is duplicated in a new profile that has been called bio_test_PIN.ppf. Then bio_test_PIN profile is selected and needs to be personalized ("Personalize" tab) in introducing the specific fingerprint on the smartcard. The Administrator PIN code is then requested in order to achieve this step.

Figure 86: Administrator PIN code and operation success

After verification of the administrator PIN code and a treatment on the smartcard, a message is displayed if the operations are successful. The smartcard is then ready to be used with the PIN code as process of authentication. Many different parameters can be modified in the personalization section of ASECard Manager Tools. Parameters like PIN codes, number of tries before blocking the card, administrator password, verification type, etc. can be changed. By default, user's PIN is set to "11111111" while administrator's PIN is set by default to "00000000".46 These parameters could be modified whenever necessary thanks to administrator's password. Note: Some of the parameters above can only be changed through re-personalization of the card which results in the loss of the credentials saved on the card. Changing the User PIN,

46 ASECard Crypto for Windows User Guide

Page 142: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 142/204

User Fingerprint, Admin PIN, or Card Label will not result in loss of credentials. See more details in the following chapter. 47 The list of possible updatable parameters can be seen in Annex 11 – List of possible changes of smartcard's profile parameters. Biometric profile Another profile, called bio_test_FINGER, is then created in order to store biometric data. This fingerprint will replace the PIN code. At this point, the profile needs to be changed because by default, the selected process of authentication is the PIN code. Thus the profile needs to be changed to "Biometric" which can be obtained through "Manage Profile", "User PIN" and "Verification Policy => Biometric".

Figure 87: Configuration of bio_test_FINGER profile

21.3.3 Fingerprint registering After the selection of this updated profile, an important operation has to be carried out. Indeed, the fingerprint of reference needs to be captured in the smartcard. Thus, when the user will try to use the certificate stored in the smartcard and he will be requested a fingerprint challenge, the fingerprint that the user will introduce in this moment will be compared to the fingerprint of reference stored in the smartcard. The user himself can choose the finger he wants to store. Then, the fingerprint is then requested three times in order to capture a reliable model.

47 ASECard Crypto for Windows User Guide

Page 143: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 143/204

Figure 88: Choice of the finger and capture of the fingerprint

A success message appears and indicates that the smartcard has been personalized. At this stage, two profiles have been created with different kinds of authentication mechanisms; PIN code (less important), fingerprint (more important).

21.3.4 Import of Certificate & Keys The certificate of the user needs to be installed in the smartcard. Here, there are many solutions that depend on the PKI policy. The certificate and the private key could for example be stored in a smartcard, protected by a password and sent to the client. The latter could then introduce his fingerprint as described above and use the certificate. A second solution is introduced if the first doesn't result secure enough. As explained in section 11.5 Delivery mode of certificate / key pair and PIN code, other delivery processes could be imagined in order to increase the level of security, by sending different parts of certificate/key pair through different transmission channels. If this is the case, the certificate with its key pair would be copied in the smartcard by the client. This process is used to store the certificate in the smartcard. ASECard Manager software is needed for this step (ASECard Crypto Toolkit -> ASECard Manager).

Page 144: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 144/204

Figure 89: Import of the certificate over the smartcard

The tab "Certificates & Keys" is selected and if the smartcard is already protected by a fingerprint, an authorization request follows. A new certificate called "Fingerprint Cert" has been generated.

Figure 90: Import of user's certificate

Then, the icon "Import Certificate" is chosen in order to install the desired certificate in this smartcard. The certificate needs to be imported in the "CAPI" section because if not, it won't work for certificate format reason. After having chosen the correct certificate, in the PKCS #12 format, the password protecting the certificate backup is requested.

Page 145: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 145/204

Figure 91: Challenge on password protecting certificate backup

At this point, the fingerprint is requested again. Finally, if these steps are successful, a message indicates that the certificate has been correctly imported. The imported certificate appears in the window.

Figure 92: Certificate imported with success

21.4 Test-bench At this point, the process of authentication with biometrics can be tested by the client host. It is important that the browser understands the difference between a certificate that need biometric authentication and a certificate that doesn't. Thus, the test has been executed with a certificate that requires biometric authentication.

Page 146: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 146/204

21.4.1 Test 1 – Access to the web site with a certificate and a Match On Card process The user launches his browser and hits the URL where the web application of IT Software is located. The user has then to choose the correct certificate in order to test the Match On Card authentication.

Figure 93: Choice of the correct certificate

A challenge is then sent to the user by the web server. Indeed, the user must be authenticated through the fingerprint. The time needed to capture the fingerprint is pretty short so even if the device is not brand-new, it offers good time response.

Figure 94: Biometric authentication with fingerprint

Page 147: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 147/204

There is a normal warning system indicating that the site, the client is trying to connect to, is trustworthy.

Figure 95: Warning of non-trusted site

The html page that has been created only for testing is then reached, which indicates that the user has been authenticated correctly.

Figure 96: Certificate authenticated with Match On Card

Here are the relative logs of successful access, generated on the web server side, in access.log, located in /var/log/apache2/: 172.16.1.254 [03/Dec/2007:15:13:45 +0100] Client with certificate's serial number 1E has been authenticated - - "GET /TEST_CERTIF HTTP/1.0" 405 172.16.1.254 - - [03/Dec/2007:15:13:45 +0100] "GET /TEST_CERTIF/ HTTP/1.0" 200 201 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705)" 172.16.1.254 [03/Dec/2007:15:13:45 +0100] Client with certificate's serial number 1E has been authenticated - - "GET /TEST_CERTIF/ HTTP/1.0" 201 172.16.1.254 - - [03/Dec/2007:15:13:45 +0100] "GET /TEST_CERTIF/logo-its.jpg HTTP/1.0" 304 - "https://172.16.1.238/TEST_CERTIF/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705)" 172.16.1.254 [03/Dec/2007:15:13:45 +0100] Client with certificate's serial number 1E has been authenticated - - "GET /TEST_CERTIF/logo-its.jpg HTTP/1.0" -

Page 148: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 148/204

172.16.1.254 - - [03/Dec/2007:15:13:45 +0100] "GET /TEST_CERTIF/its-tech.gif HTTP/1.0" 304 - "https://172.16.1.238/TEST_CERTIF/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705)" 172.16.1.254 [03/Dec/2007:15:13:45 +0100] Client with certificate's serial number 1E has been authenticated - - "GET /TEST_CERTIF/its-tech.gif HTTP/1.0" - 48

The reaction of the web server is interesting. Indeed, four logs are generated when an authenticated certificate accesses the web site (the grey logs represent the authentication while the white logs indicate operations relative to the loading of the web page). The HTTP code 405 that is found in the first log means "the Allow header indicates that the method used by the client is not supported for this URI".49 This log is due to the fact that the user can't access the website without presenting a certificate. Then, the user chooses his certificate and a second log is generated. This log has a 201 HTTP code, which means that a resource has been created on the web server which contains an entity describing the status of the request and referring to the new resource, which is the host of the client.50 This second log occurs when the client selects his certificate. Then, the process of authentication is executed web server side. It is interesting to notice that the certificate that requires biometric authentication is also stored and saved in the browser.

Figure 97: Certificate that requires biometric authentication inserted in the browser

Thus, after a successful access on the web site, it is important to test this certificate without the smartcard or with another fingerprint, as a hacker could try to do. These tests are important in order to understand the behaviour of the authentication process, in checking for example the Apache logs generated on web server's host, in the error.log file.

21.4.2 Test 2 – without the smartcard inserted or the fingerprint reader plugged-in The first test is to remove the smartcard of the Match On Card reader. When the user selects the certificate that requires fingerprint authentication and in the case the smartcard isn't inserted, an invitation to insert it is required.

48 Logs issued from Apache access.log 49 http://www.codeshttp.com 50 RFC 1945 – Hypertext Transfer Protocol – HTTP/1.0

Page 149: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 149/204

Figure 98: Without smartcard introduced

Thus, as could be expected, the application waits for a smartcard. When the smartcard is finally introduced, the application immediately recognizes the smartcard and the process of authentication can continue normally. The situation where the fingerprint reader is not plugged-in brings to the same result.

21.4.3 Test 3 – Fake finger The second test is to try a connection using another finger at the authentication request. A warning indicating that the used finger is not correct is sent to the user.

Figure 99: Fake finger trying to authenticate

The number of tries is set by default to ten but if the security policy is strengthened, this parameter could be reduced at a lower number of tries. This operation is indicated in Annex 11 – List of possible changes of smartcard's profile parameters. In both cases, the same logs are generated by Apache in the error.log file: [Mon Dec 03 15:46:04 2007] [info] [client 172.16.1.254] (104)Connection reset by peer: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] [Mon Dec 03 15:46:04 2007] [info] [client 172.16.1.254] Connection closed to child 64 with abortive shutdown (server same:443)

Page 150: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 150/204

The logs here are not very descriptive which means that Apache doesn't really understand what has happened. Apache thinks that "Stop button" has been pressed in the browser.

21.4.4 Test 4 – Revoked certificate Now that the certificate requiring biometric authentication is correctly authorized by the web server, another situation needs to be tested. Indeed, it's important to see the behaviour of the web application in case of revocation of this certificate. Thus, the process of revocation is launched for this certificate. After having revoked this certificate and having updated the new CRL, the test of connection on the web site with the revoked certificate is completed. But before doing this, it is necessary to restart the Apache server. Indeed, if it isn't restarted, the Apache server bases his check on the old CRL that he has in the cache memory. Thus, if a new CRL, that indicates that certificate with serial number 30 is revoked, emitted and the Apache server has not been restarted, the certificate number 30 can continue to connect to the application despite the fact the certificate has been revoked. So this is another critical operation that must be done. After having executed all these steps, the certificate is tested. First, the application asks the user to choose its certificate. The revoked certificate is then voluntarily selected in order to see how the system behaves. Surprisingly, the fingerprint is nevertheless requested, which indicates that the web server checks the validity of the certificate only after having authenticated the user. Indeed, the web server could check the validity of the certificate before the challenge because the certificate has already been presented to the web server in this precise moment.

Figure 100: Warning of certificate revoked

As the above figure shows, an error message appears and an email is immediately sent to the administrator, thanks to the script "ALERT", in order to warn him that a revoked certificate has tried to connect to the web site. A new certificate that requests biometric authentication is created and stored in the smartcard. Thus, the smartcard has two different certificates in its memory; one valid and the other revoked.

Page 151: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 151/204

Figure 101: Valid and non-valid certificates stored over the smartcard

Page 152: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 152/204

22. Behavior of the system with certificates Some network captures have been done in order to understand the behavior of the architecture in different kinds of situations. The software that has been used is Wireshark (Ethereal). The situations that have been tested are: • A standard certificate that is valid and authenticated • A certificate stored over a smartcard. The user would have to pass a challenge of

Match On Card • A certificate that is checked by the web server using OCSP protocol. • A revoked certificate trying to connect • A non-authorized certificate

22.1 Authenticated standard certificate

Figure 102: Server presents its own certificate and CA certificate to the user

This figure shows the web server presenting its own certificate to the client that request an access. This is part of the handshake between the web server and the user. First red line shows the information of web server's certificate. The second red line describes the certificate that have issued web server's certificate, in other words the certificate of the CA.

Page 153: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 153/204

Figure 103: Warning of non-trusted certificate on Opera browser

The user can check the CA certificate before accepting to continue, if he agrees and trust the certificate, he will accept it and the process will follow.

Figure 104: Certificate of the user

Then, user's certificate (here certificate id number 25, as shows the above red line) is presented to the web server. This operation occurs when the user, after having chosen to trust the web site, select his own certificate in order to be authenticated. This figure is interesting because it shows that in the data of the user certificate, marked in green, the level of information is pretty high. The CA certificate also appears at the end of this figure. Thus, the web server can compare if his certificate's issuer is the same as the user's certificate.

Page 154: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 154/204

After this, the web server has to check the validity of user's certificate:

Figure 105: Web server authenticates and authorizes the use to acces the web application

When the certificate is validated by the web server, the latter sends a "Server Hello" package to the client and the user can from this moment be considered as authenticated. Finally, data from the page that has been requested is sent through "Application Data" packets.

22.2 Authenticated certificate with Match On Card

This test has been done in order to see if a flag or any information indicates that the certificate has been authenticated thanks to a two-factor process, by using the fingerprint reader. After having explored the capture, no information about this was displayed, as it appears normal after reflection. Indeed, the challenge is requested client side, without transiting over the network. Thus, the capture is pretty identical to the first case.

22.3 Certificate with OCSP checking

The check of certificates validity with OCSP is not operational yet. But, this test is effectuated in order to see if the OCSP request is done correctly to the VA. First steps showing the handshake and the presentation of the certificate aren't explained again. Indeed, they are the same as in the first test. Here the focus is placed on the job of OCSP validation.

22.3.1 Web server side

Figure 106: Check of certificate with OCSP protocol over port 2561

Page 155: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 155/204

Here are the exchanges between the OCSP client or web server (ip: 172.16.1.238) and the OCSP responder or VA (ip: 172.16.1.63). After synchronization and acknowledge, that allows to set a communication, OCSP request is well effectuated. This can be noticed in the ports that are used. Indeed, OCSP exchanges have been configured in order to use port 2561. As the above figure shows, port 2561 is used. Thus, OCSP communication between web server and VA works well. Unfortunately, a problem stands in the interpretation of the information by Apache and so, the OCSP mechanism cannot be used at that stage.

22.4 Revoked certificate trying to connect

Figure 107: Revoked certificate trying to connect

After the standards handshake exchanges, the above figure shows explicitly that the certificate has been rejected because it has been revoked. Thus, it demonstrates that the system introduced to check the certificates with a local CRL is efficient.

Figure 108: Revoked certificate

Page 156: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 156/204

User's certificate has been rejected and a warning email has been sent to a PKI administrator, thanks to the bash "ALERT".

22.5 Non-authorized certificate (PKI server files protected)

Figure 109: Non-authorized certificate

In this test, a client certificate was used to access the interface of the RA server. The latter is protected in apache configuration and only the RA certificate can access this page. Thus, when the user tries to connect, he has a "Forbidden" response.

Figure 110: Access Forbidden - code 403

The ip address that sends him this response is the 172.16.1.63. It can be noticed that the three packets sent from this ip address have all a bad checksum. This can be understood as a rejection of the presented certificate.

Page 157: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 157/204

23. Task’s planning

Page 158: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 158/204

24. Status of the project This part summarizes the status of the project in order to have an overview of the work that has been done during the project. Each point defined at the beginning of the project scope has been done with extreme attention. Some additional elements have even been studied. First of all, some procedures’ definitions have been detailed in order to help the integration of the infrastructure in the actual structure of the enterprise. These explanations are useful to the management of the certificates by the future different administrators of the PKI. At that stage, the PKI is totally functional and can be used to issue, manage, revoke, etc., certificates. These certificates, with their relative key pair, are stored in a database. It is clear that this kind of information is very precious and the databases are then saved every day. A process of restore of the databases is also operational in case of data’s lost. The check of the validity of the certificate, done by the web server side in order to authorize only the valid certificate, is working well. At this stage, the web server has only the possibility to check the certificate through the CRL that the web server owns and the results are satisfying. Some explorations have been done in order to find a solution more dynamic. Indeed, with the CRL method, there is a critical moment between when the certificate is revoked and when the web server is warned about this update in receiving the new CRL. Therefore, this can be overcome in being strict in the procedure (when a certificate is revoked, issue and deliver the new CRL to the web server, restart the web server) but it is clear that a dynamical way would be more pleasant for administrators. In order to make the process of validity checking more dynamic the OCSP protocol, included in Apache configuration, has been tested. When a user tries to connect the web server, Apache checks his certificate in launching a Perl module that will manage the OCSP request and answer. The OCSP request is well executed in the project and the OCSP responder returns a satisfying answer. The problem is that Apache is not able to interpret the answer and to authorize or not the user. Efforts have been done in order to overcome this problem but no solutions have been found at this day. Another module called mod_nss, could be used but the fact is that this module is too bounded to Apache server and consequently not very portable in the case where another web server would be used. Some efforts have been done on the improvement of the infrastructure management for the administrators. Indeed, some bash or applications have been written in order to automate some process. For example, the administrator will be warned by mail when a revoked certificate will try to connect the web server, or to remind him to issue a new CRL. A process copying the new generated CRL in a directory accessible for others application has also been thought. For example, OCSP needs to check the CRL in a dynamic way and the directory where the CRL are located by default is not accessible for right’s reasons. These are little details that make easy the management of the infrastructure. After having introduced biometrics aspects in the theory, a biometric device has been inserted and tested in the project. The user has the possibility to store his certificate onto a smartcard and to be authenticated thanks to his certificate and his fingerprint. Even if it is an aspect that cannot be considered by every user for cost’s reasons, this was very challenging to introduce

Page 159: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 159/204

such a technology. Some conclusive tests about biometrics have been done and it is a technology that can be suggested to any client wanting to increase the level of security in introducing an additional factor of authentication.

Page 160: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 160/204

25. Enhancements During this project, a solid structure managing certificates has been built. The mind has always considered security as principal goal. Indeed, such a structure handles with very sensitive data, also because the clients use the structure in a financial scope. However, improvements have always to be imagined and it is what makes a project going further. First of all, a SMS service can be deployed in order to transmit the PIN code to the client, instead of using the mail method which is set by default. The library that generates the automatic mail stands in /usr/local/openca/ca/lib/functions/mail-utils.lib. It can be imagined to replace this library by a library that will be able to send the PIN code with a SMS. The application would be launched when a certificate would be published by the RA, after having been issued by the CA. The program should connect to a SMS server thanks to a login/password authentication. The phone number of the client would be transmitted as parameter. The latter would have been introduced in the form filled for the client. This process would allow to send the certificate/key pair through a channel while the PIN code protecting them would be by SMS. Moreover, the process would be a bit more automated. The check of the certificate could be enhanced thanks to a mechanism that is still not defined. Indeed, some efforts have been made about OCSP protocol, without reaching satisfying results. Perhaps OCSP was not the good direction to follow in order to check the validity of the certificates in a dynamic way and other solutions might be considered. Some tests of interoperability between existing LDAP directories within IT Software and the LDAP provided by OpenCA should be done. Indeed, it could be interesting to know if both directories could use the information generated by the other one. If it will be the case, the check of the certificates could be done in consulting the LDAP directory. The management of the entire infrastructure can be automated and improved in order to make easier the work of the administrator. The goal being to make the administrator intervene the less possible, in warning him when a critical operation has occurred. This can be done thanks to bash scripting. The administrators shall manipulate the structure during a while before to understand the needs that the enterprise have and to introduce some improvements. These improvements should enhance the work of the administrators but it must absolutely not being done in compromising the security of the structure, which is the essential point. Bashes including administrators’ login and passwords statically are obviously to avoid. The logs provide a precious source of information. Depending on the needs and the wishes of IT Software, some logs could be added in order to increase the level of information. Then, these logs can be used in order to output some interesting statistics on the behaviour of the certificates used to access the web application. Some graphics can be extracted of these statistics. The aspect of biometry has shown very interesting results and attraction to a device allowing the authentication by fingerprint. The drawback is that the solution presented was a bit expensive for every client. A more affordable solution might be considered in order to be interesting for the clients.

Page 161: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 161/204

The development of a thin client can be considered even if such a project would involve a lot of time. Indeed, the functionalities of a PKI are various and numerous. But the advantage of doing a thin client would be to realize functions and libraries that are specific to the needs of the company, according to the wishes of the clients. Such a solution would reduce considerably the traffic to the server. Indeed, the application would be decentralised from each user’s host, increasing the global performance.

Page 162: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 162/204

Conclusion

This thesis has allowed to go deeper in the processes of cryptography and authentication, from the bases to the building of an entire PKI infrastructure. The concept of authenticating a user in a reliable way is becoming more and more essential, moreover if the used application is sensitive. It’s very important for the enterprise to control the using of its application and in the other hand, it’s also important for the user to be sure that he’s using a valid application. For this reason, the introduction of a structure managing X.509 certificates has been built and developed. The project has been very attractive because it has required to analyze the problematic with detachment in order to reach the fixed target. Many different elements have been considered during this thesis but a unique global vision has been followed in order to maintain a good direction. Indeed, security was the most fundamental aspect during the entire project. This was due to the fact that very sensible data has been manipulated and is still located in servers’ environment. The enterprise, dealing with financial institutions, has to guarantee the maximum of security to their users. In this, the thesis has been valorised by the fact that the project has been done within an enterprise. Thus, the problematic of security could be discussed and analyzed in function of the existing structure of the enterprise. In this regard, a real enterprise’s vision has been adopted in order to understand the wishes of IT Software all the while keeping a particular attention to security. Indeed, it was important to understand some possible risks and to consider them in trying to reduce them to the maximum. Thus, after having analyzed the best mechanisms to introduce in IT Software, the major goal was to build a solid functional structure. It was very important to know that the technology was operational. Then, the goal was to enhance the infrastructure in order to deliver a more complete product to the future administrators. The aim was to deliver a product that could be part of the global environment of the enterprise. The built infrastructure offers satisfying results even if the product can be improved. The realization of this PKI has requested efforts of installation and configuration. It is clear that such a structure require maintenance in order to use it with real clients. Thus, IT Software has to decide if a PKI can take place in its environment. But to look towards the increasing of session’s hacking and knowing that IT Software’s clients use sensible data, something needs to be done in order to increase the level of the security. In this regard, certificates issued by a private PKI require efforts for IT Software, but the global security of the application will certainly be improved. The PKI world is very vast and a lot of solution could have been imagined. It is obvious that the private PKI that has been built during the project has not the same quality that a public PKI could offer. This is due to the inexperience of the built PKI. Indeed, the actual PKI need some time in order to be tested deeper and to understand what can be improved. On the other hand, the advantage that brings a private PKI based on Linux is the fact that modules, patches, applications can always been added to the global project. Indeed, the configuration can be highly controlled and changed according to the future needs of the enterprise.

Page 163: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 163/204

PKI’s term, in general, doesn’t necessarily mean security. Indeed some questions can sometimes not be answered. How can we trust an authority that is connected on Internet? How are managed our keys? The RA or CA server is locked in a room and protected by password but who can be sure that an unauthorized person could not access the server anyway? These kinds of questions have not the goal to call everything in question but have just to stay in mind of every administrator. The security of a system of information is like a chain, it is only as strong as the weakest link of this chain. Everything can not be controlled. But the simple fact to take off RA server from Internet and then to avoid accesses from the outside to the server reduce considerably the risks of attack. The management of the structure will be perhaps more constraining but at least, a major control of the risks coming from the outside is evident. Thus, it is an additional argument that allows to ensure a better management of the risks. This kind of attitude should be very well received by any type of clients, as a demonstration that a big effort is done about security.

Page 164: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 164/204

Annexes

Annex 1 – PKCS Standards

Figure 111: PKCS Standards (Source: http://en.wikipedia.org/wiki/PKCS)

Page 165: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 165/204

Annex 2 – Biometrics, other solutions

2.1 Hand The hand analysis is uniquely based on the geometry of the hand. It is a very simple and cheap technology. The system takes a picture of the hand and examines eighty characteristics (like length and width of fingers, articulations shape, etc.). This technology offers a satisfying degree of exactitude even though in some particular cases for example, a situation where two people of the same family would use the same system. The template that is extracted from this analysis is very small (~ ten bytes).

Figure 112: Image capture device

(Source: http://www.biometrie-online.net/techno/main/T-mai.php)

Figure 113: Geometry of the hand in 3D (Source: http://www.biometrie-online.net/techno/main/T-mai.php)

This kind of biometrics is very simple to build and very often well accepted by users based on the fact that this is not an unpleasant method. Its efficiency, in terms of reliability of the authentication, has proven itself.

Page 166: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 166/204

2.2 Face

Figure 114: Face elements analyzed (Source: Survey on biometrics from M. Baumgartner – 2002)

However, this is a technology that is not secured enough. Indeed, some variable parameters can obviously disturb and mislead the analysis of a camera. Those parameters are for example the hairiness, make-up, the presence or absence of glasses, ageing, a different face emotion, big circles under the eyes due to a bad night, etc. Moreover, the result can vary according to the brightness of the environment. All these factures does not offer enough reliability with this technology. This method is used most often when it does not disturb the user. Moreover, the result will never be assured knowing the poor reliability offered by this system. However, the building and implementation of the device is pretty cheap. It all depends on the degree of security that it needs to be reached.

2.3 Voice Voice identification is considered as being the most natural because it does not need a physical contact between the user and the equipment that captures the information. This technique is often used in situations where other mechanisms are too difficult to install (bank operation at distance, accounts accesses, etc.). Most of the systems that use a display window with a random text that the user will have to read in order to avoid that the authentication are made by a recording which a hacker could have in its possession. The analysed parameters are the frequency, intensity and tonality of the voice. All these elements come directly in the form of vocal cords of an individual, which provide enough differences between people. It only has to pay attention to the elements like ambient noise, the use of a microphone or even a user's emotion, parameters that can modify a voice. In spite of all these aspects that need to be verified, voice biometrics remains a very interesting means because it can directly be built into the telephone network.

This technique is more and more often used in the domain of the recognition of people in the middle of a crowd (sport stadiums, airports, commercial centre, etc.). Some traces and particularities of a face can be extracted thanks to a TV camera. The equipment should ideally, be able to identify particularities of a human being even if some differences are introduced like a moustache or glasses between the analyzed person and the referenced model. The elements that are the most important are the eyes, the mouth and also the face outline.

Page 167: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 167/204

Figure 115: Voice analysis during password's pronunciation (Source: http://www.biometrie-online.net/techno/voix/T-voi.php)

The process that analyses the voice is called Speaker Automatic Authentication (SAA) or Speaker verification. Such a mechanism will evaluate voice performances. However, some parameters that can modify the result have to be kept in mind: ٠ Speaking quality: Calm or noisy environment ٠ Speaking quantity: Speaking duration of test sessions.

٠ Variability of intra-speaker: The voice depends on the physical and emotional state of the person. The voice can also change when the person gets used to the system.

٠ Speakers database population: The more important the population is, the longer

the comparison process will take time. ٠ Speakers intention: The distinction between cooperative speakers and others, those

that do not want to cooperate, will have a change with their voice. Here is the process of analysis of the voice realised by a SAA system. The user's voice will be compared to the vocal signature kept in the memory. The steps characterising the voice analysis are: ٠ The settings: Choice of parameters (spectral analysis parameters, parameters that

exploits dynamic speaking signals, etc.) ٠ Classification: Comparison between signal vectors of the tested speaker with the

signal vectors of reference that are stored in the database. ٠ Decision: Directly depends of classification phase. The user will be accepted,

recognized or rejected according to a decision threshold (it has to be noticed that a similarity of 100% is not feasible).

Page 168: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 168/204

Figure 116: Analysis process and SSA decision (Source: http://www.biometrie-online.net/techno/voix/T-voi.php)

The big problem of this kind of technique is the variability due to the speaker and the recording conditions. Nevertheless, it is a technology that is more and more often used and where the progress is constant. It is often used in systems where the voice is already used in parameters like call centre or telephony.

2.4 Eye In this part, two authentication methods are feasible: iris or retina authentication. This technique is much more reliable because the elements that forms an eye are very particular and personal, and thus easier to identify.

Figure 117: Eye's cut

(Source: http://www.amdcanada.com/images/content/4_2_fig1.jpg)

2.4.1 Iris authentication Iris authentication uses so many parameters that it makes it more of an authentication technology than an identification technology. To tell the truth, the probability to find two

sufficiently identical irises to cause confusion is one chance in 7210 , according to Mr.

Page 169: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 169/204

Daugman, which is the creator of the iris recognition algorithm. His method is going to be explained below. Another asset of this technology is the form of the iris since it does not vary a lot during the lifespan of a person. In contrast, iris' color can change a little bit. The iris is so complex that a global study of it is sufficient to authenticate two different individuals.

Figure 118: Different kind of iris (Source: http://www.biometrie-online.net/techno/iris/T-iri.php)

The capture of the image of an iris is pretty delicate on certain aspects. Indeed, it is a question of a sensitive organ whose size can vary according to the ambient brightness or the state of tiredness. Thus, the sensor has to succeed in seizing the image quickly without any use of superficial light that would reflect onto the iris and which then could distort the analysis. The method currently used for the characterisation of the iris is the one patented by Daugman. It consists of digitalizing the image of the eye by bringing out the centre of the pupil and the zone where the iris is situated.

Figure 119: Iris analysis (Source: http://www.biometrie-online.net/techno/iris/T-iri.php)

Iris biometrics is a technology that ensures a high level of security because of this is a unique element, in terms of the almost impossible chance to merge two different irises. Thus, reliability is big with that kind of element.

2.4.2 Retina authentication The element that permits to distinguish two different retinas is the veins that cover it. The disposition of those veins is stable and unique from a person to another one.

Page 170: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 170/204

Figure 120: Retina (Source: http://www.biometrie-online.net/techno/retine/T-ret.php)

This technology, older than the iris one, is pretty uncomfortable for the person that has to be submitted to it. Indeed, the bottom of the eye has to be illuminated with a beam of light, through the pupil and the vitreous body. Moreover, to proceed with capturing the image, it is necessary to put the eye at only a few millimetres of the device, which is pretty uncomfortable for the user.

Figure 121: Retina capture and analysis (Source: http://www.biometrie-online.net/techno/retine/T-ret.php)

The captured image is cut up in a ring and then sculpted in order to perceive the veins and also their orientation. The algorithms used to reach this kind of result are pretty complex. This method brings a fairly high level of recognition. It is well adapted for an application that requires high security, where the level of safety has to be at maximum.

2.5 Signature The most popular means to authenticate a written document is the signature. This method is used in many cases and situations. The idea of this mechanism is to capture the handwritten signature in a digital way, in order to analyse and be in a position to authenticate the signatory. In most of the situations, the capturing is done via a writing pad with a pen reader.

Page 171: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 171/204

Figure 122: Tablet with pen reader (Source: http://www.biometrie-online.net/techno/signature/T-sign.php)

Some variables are analysed to determine the correspondence with a signature referenced in the database. These parameters are the speed of writing, accelerations, the applied pressure, etc.

Figure 123: Sample processing (Source: http://www.biometrie-online.net/techno/signature/T-sign.php)

However, this technique has some disadvantages. Indeed, a signature is never perfectly identical to another one written before by the same person. Some events like emotions or tiredness can introduce a variant on the signature. This technology has a large advantage to have a great juridical recognition for authentication. But, because of the variations of a handwritten signature for the same person, it is difficult to reach a high exactitude in the identification of a person.

2.6 The dynamics of typing on a keyboard Every individual has a particular manner to hit a computer's keyboard. This can also be a way of biometric authentication because a method already exists and consists of asking the user to enter their password about ten times. According to these attempts, the system will do a mean of these hits and will create a stroke profile for the user. When the user would like to authenticate himself, the stroke dynamics will have to fit with the stored model in the database. This profile is created thanks to two parameters:

Time

Vertical move Horizontal move

Pen pressure

Page 172: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 172/204

- The time that is taken to hit and keep the key. - The time between two different keys pressed.

Figure 124: Profile of the dynamics of a users touch (Source: http://www.biometrie-online.net/techno/clavier/T-clav.php)

Indeed, it is not obvious to reproduce exactly the same typing dynamic of another person. And even if the dishonest individual has succeeded in hacking the user's password, he will have to get over this difficult step of imitation. The advantage of such a system resides in the fact that only a software program is necessary to run this system. The costs are very little and its use can easily be extended to a high number of users. Moreover, the necessity to regularly change the password becomes less important. However, for people who travel a lot, this system could be problematic because of the different formats of keyboards that change according to the country where the capture is effectuated.

Key hold

down time

TIME BETWEEN TWO KEYS PRESSED

HITS

User hitting profile

Page 173: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 173/204

Annex 3 – Configuration of Apache for PKI server

NameVirtualHost 172.16.1.63:443

<VirtualHost 172.16.1.63:443>

ServerAdmin [email protected]

DocumentRoot /var/www

SSLEngine on

SSLCertificateFile /etc/apache2/ssl/apache.pem

SSLCACertificateFile /usr/local/etc/ocspd/ca/cacert.crt

SSLVerifyDepth 1

SSLOptions +StdEnvVars +ExportCertData

SSLCARevocationFile /usr/local/openca/ca/var/crypto/crls/cacrl.pem

SSLVerifyClient require

#Protect CA files form intrusions

<Directory /var/www/ca/ >

SSLOptions +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

#The client certificate must be CA's ("IT Software CA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software CA")

</Directory>

#Protect cgi-bin for ca files. When the ca is selected, the url is changed

in /cgi-bin/ca/ca...

<Location /cgi-bin/ca/ca >

SSLOptions +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

#The client certificate must be CA's ("IT Software CA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software CA")

</Location>

#Protect CA-node files from intrusion

<Directory /var/www/ca-node >

SSLOptions +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

#The client certificate must be CA's ("IT Software CA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software CA")

</Directory>

#Protect cgi-bin for ca-node files. When the ca is selected, the url is

changed in /cgi-bin/ca-node/node...

<Location /cgi-bin/ca-node/node >

SSLOptions +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

#The client certificate must be CA's ("IT Software CA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software CA")

</Location>

#Protect RA files from intrusion

<Directory /var/www/ra >

SSLOptions +StdEnvVars

SSLVerifyClient require

Page 174: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 174/204

SSLVerifyDepth 5

#The client certificate must be RA's ("IT Software RA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software RA")

</Directory>

#Protect cgi-bin for ca files. When the ca is selected, the url is changed

in /cgi-bin/ra/RAServer...

<Location /cgi-bin/ra/RAServer >

SSLOptions +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

#The client certificate must be RA's ("IT Software RA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software RA")

</Location>

#Protect RA-node files from intrusion

<Directory /var/www/ra-node >

SSLOptions +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

#The client certificate must be RA's ("IT Software RA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software RA")

</Directory>

#Protect cgi-bin for ca files. When the ca is selected, the url is changed

in /cgi-bin/ra-node/node...

<Location /cgi-bin/ra-node/node >

SSLOptions +StdEnvVars

SSLVerifyClient require

SSLVerifyDepth 5

#The client certificate must be RA's ("IT Software RA")

SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software RA")

</Location>

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

<Directory /var/www >

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

allow from all

# This directive allows us to have apache2's default start page

# in /apache2-default/, but still have / go to the right place

#RedirectMatch ^/$ /apache2-default/

</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory "/usr/lib/cgi-bin">

AllowOverride None

Options ExecCGI -MultiViews +SymLinksIfOwnerMatch

Order allow,deny

Allow from all

</Directory>

ErrorLog /var/log/apache2/error.log

Page 175: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 175/204

# Possible values include: debug, info, notice, warn, error, crit,

# alert, emerg.

LogLevel debug

CustomLog /var/log/apache2/access.log combined

#Additional log to have the serial number of client's certificate

#presented

CustomLog /var/log/apache2/access.log "%t %h Client with

certificate's serial number %{SSL_CLIENT_M_SERIAL}x has been

authenticated \"%r\" %b"

ServerSignature On

Alias /doc/ "/usr/share/doc/"

<Directory "/usr/share/doc/">

Options Indexes MultiViews FollowSymLinks

AllowOverride None

Order deny,allow

Deny from all

Allow from 127.0.0.0/255.0.0.0 ::1/128

</Directory>

Alias /awstatsicons/ "/usr/local/src/awstats/awstats-

6.7/wwwroot/icon

<Directory "/usr/local/src/awstats/awstats-6.7/wwwroot/icon">

Options Indexes MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

</VirtualHost>

Page 176: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 176/204

Annex 4 – config.xml of the CA (the global configuration file of the CA) <?xml version="1.0" encoding="UTF-8"?>

<openca>

<software_config>

<!--

########################################################

USAGE WARNING

########################################################

If yo change this file then you must change all files in

etc which has the suffix .template. Please do this with

the script openca-configure.

Example:

template: servers/ca.conf.template

openca-configure config.xml servers/ca.conf.template

servers/ca.conf

If you don't do this then you have an inconsistent

OpenCA installation. So this warning is serious.

You can update all templates with a simple bash script.

configure_etc.sh is such a script and demonstrates the

usage of openca-configure.

2003-Mar-12, Michael Bell <[email protected]>

-->

<prefix>@</prefix>

<suffix>@</suffix>

<!-- =============== -->

<!-- general options -->

<!-- =============== -->

<option>

<name>default_language</name>

<value>C</value>

</option>

<option>

<name>default_charset</name>

<value>UTF-8</value>

</option>

<option>

<!--

cert_chars says if you want utf8 or latin1

strings to be allowed in the fields of reqs

and certs. Can have values "UTF8" or "LATIN1".

If left empty or absent altogether, defaults to

LATIN1 strings.

-->

<name>cert_chars</name>

<value>LATIN1</value>

</option>

<option>

<!--

Once cert_chars is UTF8 you may use

strings in national languages here.

-->

<name>ca_organization</name>

<value>IT Software</value>

</option>

Page 177: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 177/204

<option>

<!--

Once cert_chars is UTF8 you may use

strings in national languages here.

-->

<name>ca_locality</name>

<value>Milano</value>

</option>

<option>

<!--

please enter the ISO country code here

DE, IT, PL, UK, US ...

this country code is ALWAYS two characters long

-->

<name>ca_country</name>

<value>IT</value>

</option>

<option>

<name>sendmail</name>

<value>/usr/lib/sendmail -t </value>

</option>

<option>

<name>send_mail_automatic</name>

<value>yes</value>

</option>

<option>

<name>service_mail_account</name>

<value>[email protected]</value>

</option>

<option>

<name>policy_link</name>

<value>https://172.16.1.63/pub/policy.html</value>

</option>

<!-- ======================== -->

<!-- web server configuration -->

<!-- ======================== -->

<option>

<name>httpd_protocol</name>

<value>https</value>

</option>

<option>

<name>httpd_host</name>

<value>172.16.1.63</value>

</option>

<option>

<!-- please include the colon if you specify a port -->

<!-- please remember this is dependend from httpd_protocol -->

<name>httpd_port</name>

<value>:443</value>

</option>

<option>

<name>menu_logo_left</name>

<value>

<!-- Here you can put references to the logo, you can use

any html reference you want but please keep in mind that:

no <> are allowed, use instead &lt; and &gt; rispectively.

example:

&lt;img src="https://xyz.org/mylogo.jpg" alt="XYZ Logo"/&gt;

-->

</value>

</option>

<option>

<name>menu_logo_right</name>

&lt;a href="__HTDOCS_PREFIX__/thanks.html"&gt;

Page 178: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 178/204

&lt;img src="__HTDOCS_PREFIX__/images/openca-logo.png"

alt="OpenCA Logo"/&gt;

&lt;/a&gt;

<value></value>

</option>

<option>

<!--

You can add more CDPs here. Please enter one CDP per line.

This is the content of an OpenSSL configuration section.

Example:

URI.1=http://cdp1.xyz.de/pub/crl/cacrl.crl

URI.2=ldap://cdp2.xyz.de/cn=CA,ou=Trustcenter,o=XYZ,c=DE

URI.3=http://cdp2.xyz.de/pub/crl/cacrl.crl

URI.4=ldap://cdp1.xyz.de/cn=CA,ou=Trustcenter,o=XYZ,c=DE

-->

<name>CRLDistributionPoints</name>

<value>

URI.1=http://172.16.1.63/pub/crl/cacrl.crl

</value>

</option>

<option>

<name>NS_CRLDistributionPoint</name>

<value>http://172.16.1.63/pub/crl/cacrl.crl</value>

</option>

<!-- ========================= -->

<!-- ldap server configuration -->

<!-- ========================= -->

<option>

<name>ldap_host</name>

<value>172.16.1.63</value>

</option>

<option>

<name>ldap_port</name>

<value>389</value>

</option>

<option>

<name>ldaproot</name>

<value></value>

</option>

<option>

<name>ldaprootpwd</name>

<value></value>

</option>

<option>

<name>useLDAP</name>

<value>no</value>

</option>

<option>

<name>update_ldap_automatic</name>

<value>no</value>

</option>

<!-- ====================== -->

<!-- database configuration -->

<!-- ====================== -->

<option>

<name>dbmodule</name>

<!-- you can use DB or DBI -->

<value>DBI</value>

</option>

<option>

<name>db_type</name>

<value>Pg</value>

</option>

<option>

Page 179: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 179/204

<name>db_name</name>

<value>openca_ca</value>

</option>

<option>

<name>db_host</name>

<value>localhost</value>

</option>

<option>

<name>db_port</name>

<value>5432</value>

</option>

<option>

<name>db_user</name>

<value>openca_ca</value>

</option>

<option>

<name>db_passwd</name>

<value>openca_ca</value>

</option>

<option>

<name>db_namespace</name>

<!--

a namespace is prefix in front of every table

Example: table user1

==>

select * from user1.certificate;

This is not required for MySQL, PostgreSQL and IBM DB2.

Nevertheless all supported database can use such namespaces

and it is the default behaviour of Oracle. Oracle uses as

namespace usually the name of the database.

-->

<value>openca_ca</value>

</option>

<!-- ==================== -->

<!-- module configuration -->

<!-- ==================== -->

<option>

<name>module_shift</name>

<!-- 8 bits are enough for IDs from 0 to 255 -->

<!-- please remember that 0 is the ID of the CA -->

<value>8</value>

</option>

<option>

<name>ra_module_id</name>

<value>1</value>

</option>

<option>

<name>ldap_module_id</name>

<value>2</value>

</option>

<option>

<name>node_module_id</name>

<value>3</value>

</option>

<option>

<name>pub_module_id</name>

<value>32</value>

</option>

<option>

<name>scep_module_id</name>

<value>33</value>

</option>

<option>

<name>batch_module_id</name>

<value>128</value>

Page 180: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 180/204

</option>

<!-- =============================== -->

<!-- configuration of relative paths -->

<!-- =============================== -->

<option>

<name>batch_htdocs_url_prefix</name>

<value>/batch</value>

</option>

<option>

<name>batch_cgi_url_prefix</name>

<value>/cgi-bin/batch</value>

</option>

<option>

<name>ca_htdocs_url_prefix</name>

<value>/ca</value>

</option>

<option>

<name>ca_cgi_url_prefix</name>

<value>/cgi-bin/ca</value>

</option>

<option>

<name>node_htdocs_url_prefix</name>

<value>/ca-node</value>

</option>

<option>

<name>node_cgi_url_prefix</name>

<value>/cgi-bin/ca-node</value>

</option>

<option>

<name>ra_htdocs_url_prefix</name>

<value>/ra</value>

</option>

<option>

<name>ra_cgi_url_prefix</name>

<value>/cgi-bin/ra</value>

</option>

<option>

<name>ldap_htdocs_url_prefix</name>

<value>/ldap</value>

</option>

<option>

<name>ldap_cgi_url_prefix</name>

<value>/cgi-bin/ldap</value>

</option>

<option>

<name>pub_htdocs_url_prefix</name>

<value>/pub</value>

</option>

<option>

<name>pub_cgi_url_prefix</name>

<value>/cgi-bin/pub</value>

</option>

<option>

<name>scep_cgi_url_prefix</name>

<value>/cgi-bin/scep</value>

</option>

<!-- =============================== -->

<!-- configuration of absolute paths -->

<!-- =============================== -->

<option>

<name>batch_htdocs_fs_prefix</name>

<value>/var/www/batch</value>

Page 181: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 181/204

</option>

<option>

<name>batch_cgi_fs_prefix</name>

<value>/usr/lib/cgi-bin/batch</value>

</option>

<option>

<name>ca_htdocs_fs_prefix</name>

<value>/var/www/ca</value>

</option>

<option>

<name>ca_cgi_fs_prefix</name>

<value>/usr/lib/cgi-bin/ca</value>

</option>

<option>

<name>node_htdocs_fs_prefix</name>

<value>/var/www/ca-node</value>

</option>

<option>

<name>node_cgi_fs_prefix</name>

<value>/usr/lib/cgi-bin/ca-node</value>

</option>

<option>

<name>ra_htdocs_fs_prefix</name>

<value>/var/www/ra</value>

</option>

<option>

<name>ra_cgi_fs_prefix</name>

<value>/usr/lib/cgi-bin/ra</value>

</option>

<option>

<name>ldap_htdocs_fs_prefix</name>

<value>/var/www/ldap</value>

</option>

<option>

<name>ldap_cgi_fs_prefix</name>

<value>/usr/lib/cgi-bin/ldap</value>

</option>

<option>

<name>pub_htdocs_fs_prefix</name>

<value>/var/www/pub</value>

</option>

<option>

<name>pub_cgi_fs_prefix</name>

<value>/usr/lib/cgi-bin/pub</value>

</option>

<option>

<name>scep_cgi_fs_prefix</name>

<value>/usr/lib/cgi-bin/scep</value>

</option>

<!-- ===================== -->

<!-- configuration of SCEP -->

<!-- ===================== -->

<option>

<name>SCEP_RA_CERT</name>

<value></value>

</option>

<option>

<name>SCEP_RA_KEY</name>

<value></value>

</option>

<option>

<name>SCEP_RA_PASSWD</name>

<value></value>

</option>

Page 182: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 182/204

<!-- ===================== -->

<!-- general configuration -->

<!-- ===================== -->

<option>

<name>USE_LOAS</name>

<value>yes</value>

</option>

<option>

<name>prefix</name>

<value>/usr/local</value>

</option>

<option>

<name>bindir</name>

<value>/usr/local/bin</value>

</option>

<option>

<name>etc_prefix</name>

<value>/usr/local/openca/ca/etc</value>

</option>

<option>

<name>lib_prefix</name>

<value>/usr/local/openca/ca/lib</value>

</option>

<option>

<name>var_prefix</name>

<value>/usr/local/openca/ca/var</value>

</option>

<option>

<name>batch_prefix</name>

<value>batch</value>

</option>

<option>

<name>ca_prefix</name>

<value>ca</value>

</option>

<option>

<name>ldap_prefix</name>

<value>ldap</value>

</option>

<option>

<name>node_prefix</name>

<value>ca-node</value>

</option>

<option>

<name>pub_prefix</name>

<value>pub</value>

</option>

<option>

<name>ra_prefix</name>

<value>ra</value>

</option>

<option>

<name>scep_prefix</name>

<value>scep</value>

</option>

<!-- ========================== -->

<!-- dataexchange configuration -->

<!-- ========================== -->

<!-- there are several templates available today -->

<!-- 0. no dataexchange configure - the default -->

<!-- this makes only sense for an all in one box -->

Page 183: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 183/204

<!-- it is strongly recommended to use this only for testing -->

<!-- 1. the node acts as CA only -->

<!-- the node exports to one or several RAs only -->

<!-- the node can export to LDAP too -->

<!-- 2. the node acts as RA only -->

<!-- the node exchange data with a CA and public/scep -->

<!-- the node can act as LDAP too -->

<!-- the node can export to LDAP too -->

<!-- 3. the node acts as public/scep only -->

<!-- the node exchange data with a RA -->

<!-- 4. the node acts as LDAP only -->

<!-- the node receives data from CA or RA -->

<!-- 5. the node acts as public/scep and RA -->

<!-- the node echanges data with a CA only -->

<!-- no support for dataexchange with additional LDAP -->

<!-- 6. the node acts as RA and CA -->

<!-- the node exchange data with public/scep -->

<!-- the node can export to LDAP too -->

<!-- -->

<!-- LDAP is only relevant if it is the only protocol on the node -->

<!-- 0. no dataexchange configure - the default -->

<!-- <option>

<name>enroll_ca_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_crl_states</name>

<value></value>

</option>

<option>

<name>enroll_crr_states</name>

<value></value>

</option>

<option>

<name>enroll_csr_states</name>

<value></value>

</option>

<option>

<name>enroll_mail_states</name>

<value></value>

</option>

<option>

<name>receive_crr_states</name>

<value></value>

</option>

<option>

<name>receive_csr_states</name>

<value></value>

</option>

<option>

<name>download_ca_certificate_states</name>

<value></value>

</option>

<option>

<name>download_certificate_states</name>

<value></value>

</option>

<option>

<name>download_crl_states</name>

<value></value>

Page 184: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 184/204

</option>

<option>

<name>download_crr_states</name>

<value></value>

</option>

<option>

<name>download_csr_states</name>

<value></value>

</option>

<option>

<name>download_mail_states</name>

<value></value>

</option>

<option>

<name>upload_crr_states</name>

<value></value>

</option>

<option>

<name>upload_csr_states</name>

<value></value>

</option>

-->

<!-- 1. the node acts as CA only -->

<option>

<name>enroll_ca_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_crl_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_crr_states</name>

<value>ARCHIVED DELETED APPROVED</value>

</option>

<option>

<name>enroll_csr_states</name>

<value>ARCHIVED DELETED</value>

</option>

<option>

<name>enroll_mail_states</name>

<value>CRINS DEFAULT</value>

</option>

<option>

<name>receive_crr_states</name>

<value>APPROVED</value>

</option>

<option>

<name>receive_csr_states</name>

<value>APPROVED</value>

</option>

<option>

<name>download_ca_certificate_states</name>

<value></value>

</option>

<option>

<name>download_certificate_states</name>

<value></value>

Page 185: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 185/204

</option>

<option>

<name>download_crl_states</name>

<value></value>

</option>

<option>

<name>download_crr_states</name>

<value></value>

</option>

<option>

<name>download_csr_states</name>

<value></value>

</option>

<option>

<name>download_mail_states</name>

<value></value>

</option>

<option>

<name>upload_crr_states</name>

<value></value>

</option>

<option>

<name>upload_csr_states</name>

<value></value>

</option>

<!-- 2. the node acts as RA only -->

<!--

<option>

<name>enroll_ca_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_crl_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_crr_states</name>

<value>ARCHIVED DELETED APPROVED SIGNED PENDING NEW</value>

</option>

<option>

<name>enroll_csr_states</name>

<value>ARCHIVED DELETED</value>

</option>

<option>

<name>enroll_mail_states</name>

<value></value>

</option>

<option>

<name>receive_crr_states</name>

<value>PENDING NEW</value>

</option>

<option>

<name>receive_csr_states</name>

<value>PENDING RENEW NEW</value>

</option>

<option>

<name>download_ca_certificate_states</name>

<value>VALID</value>

</option>

<option>

Page 186: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 186/204

<name>download_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crl_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crr_states</name>

<value>ARCHIVED DELETED APPROVED</value>

</option>

<option>

<name>download_csr_states</name>

<value>ARCHIVED DELETED</value>

</option>

<option>

<name>download_mail_states</name>

<value>CRINS DEFAULT</value>

</option>

<option>

<name>upload_crr_states</name>

<value>APPROVED</value>

</option>

<option>

<name>upload_csr_states</name>

<value>APPROVED</value>

</option>

-->

<!-- 3. the node acts as public/scep only -->

<!--

<option>

<name>enroll_ca_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_crl_states</name>

<value></value>

</option>

<option>

<name>enroll_crr_states</name>

<value></value>

</option>

<option>

<name>enroll_csr_states</name>

<value></value>

</option>

<option>

<name>enroll_mail_states</name>

<value></value>

</option>

<option>

<name>receive_crr_states</name>

<value></value>

</option>

<option>

<name>receive_csr_states</name>

<value></value>

</option>

<option>

<name>download_ca_certificate_states</name>

<value>VALID</value>

Page 187: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 187/204

</option>

<option>

<name>download_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crl_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crr_states</name>

<value>ARCHIVED DELETED APPROVED SIGNED PENDING RENEW NEW</value>

</option>

<option>

<name>download_csr_states</name>

<value>ARCHIVED DELETED</value>

</option>

<option>

<name>download_mail_states</name>

<value>CRINS DEFAULT</value>

</option>

<option>

<name>upload_crr_states</name>

<value>NEW</value>

</option>

<option>

<name>upload_csr_states</name>

<value>RENEW NEW</value>

</option>

-->

<!-- 4. the node acts as LDAP only -->

<!--

<option>

<name>enroll_ca_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_crl_states</name>

<value></value>

</option>

<option>

<name>enroll_crr_states</name>

<value></value>

</option>

<option>

<name>enroll_csr_states</name>

<value></value>

</option>

<option>

<name>enroll_mail_states</name>

<value></value>

</option>

<option>

<name>receive_crr_states</name>

<value></value>

</option>

<option>

<name>receive_csr_states</name>

<value></value>

</option>

<option>

Page 188: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 188/204

<name>download_ca_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>download_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crl_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crr_states</name>

<value>ARCHIVED DELETED APPROVED SIGNED PENDING RENEW NEW</value>

</option>

<option>

<name>download_csr_states</name>

<value>ARCHIVED DELETED</value>

</option>

<option>

<name>download_mail_states</name>

<value></value>

</option>

<option>

<name>upload_crr_states</name>

<value></value>

</option>

<option>

<name>upload_csr_states</name>

<value></value>

</option>

-->

<!-- 5. the node acts as public/scep and RA -->

<!--

<option>

<name>enroll_ca_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_certificate_states</name>

<value></value>

</option>

<option>

<name>enroll_crl_states</name>

<value></value>

</option>

<option>

<name>enroll_crr_states</name>

<value></value>

</option>

<option>

<name>enroll_csr_states</name>

<value></value>

</option>

<option>

<name>enroll_mail_states</name>

<value></value>

</option>

<option>

<name>receive_crr_states</name>

<value></value>

</option>

<option>

<name>receive_csr_states</name>

<value></value>

Page 189: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 189/204

</option>

<option>

<name>download_ca_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>download_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crl_states</name>

<value>VALID</value>

</option>

<option>

<name>download_crr_states</name>

<value>ARCHIVED DELETED APPROVED</value>

</option>

<option>

<name>download_csr_states</name>

<value>ARCHIVED DELETED</value>

</option>

<option>

<name>download_mail_states</name>

<value>CRINS DEFAULT</value>

</option>

<option>

<name>upload_crr_states</name>

<value>APPROVED</value>

</option>

<option>

<name>upload_csr_states</name>

<value>APPROVED</value>

</option>

-->

<!-- 6. the node acts as RA and CA -->

<!--

<option>

<name>enroll_ca_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_certificate_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_crl_states</name>

<value>VALID</value>

</option>

<option>

<name>enroll_crr_states</name>

<value>ARCHIVED DELETED APPROVED SIGNED PENDING NEW</value>

</option>

<option>

<name>enroll_csr_states</name>

<value>ARCHIVED DELETED</value>

</option>

<option>

<name>enroll_mail_states</name>

<value></value>

</option>

<option>

<name>receive_crr_states</name>

<value>PENDING NEW</value>

</option>

<option>

Page 190: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 190/204

<name>receive_csr_states</name>

<value>PENDING RENEW NEW</value>

</option>

<option>

<name>download_ca_certificate_states</name>

<value></value>

</option>

<option>

<name>download_certificate_states</name>

<value></value>

</option>

<option>

<name>download_crl_states</name>

<value></value>

</option>

<option>

<name>download_crr_states</name>

<value></value>

</option>

<option>

<name>download_csr_states</name>

<value></value>

</option>

<option>

<name>download_mail_states</name>

<value></value>

</option>

<option>

<name>upload_crr_states</name>

<value></value>

</option>

<option>

<name>upload_csr_states</name>

<value></value>

</option>

-->

<!-- these are the devices for the default dataexchange -->

<option>

<name>dataexchange_device_up</name>

<value>/usr/local/openca/ca/var/tmp/ca-up</value>

</option>

<option>

<name>dataexchange_device_down</name>

<value>/usr/local/openca/ca/var/tmp/ca-down</value>

</option>

<option>

<name>dataexchange_device_local</name>

<value>/usr/local/openca/ca/var/tmp/ra-local</value>

</option>

</software_config>

</openca>

Page 191: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 191/204

Annex 5 – Apache configuration for web server (check validity with CRL) NameVirtualHost 172.16.1.238:443

<VirtualHost 172.16.1.238:443>

ServerAdmin webmaster@localhost

SSLEngine on

SSLCertificateFile /etc/apache2/webserver/webserver.pem

SSLOptions +StdEnvVars +ExportCertData

SSLCertificateKeyFile /etc/apache2/webserver/webserver.key

SSLCACertificateFile /etc/apache2/webserver/ca/cacert.crt

SSLVerifyDepth 1

SSLCARevocationFile /etc/apache2/webserver/crls/cacrl.pem

SSLVerifyClient require

DocumentRoot /var/www/

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

allow from all

# This directive allows us to have apache2's default start page

# in /apache2-default/, but still have / go to the right place

#RedirectMatch ^/$ /apache2-default/

</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory "/usr/lib/cgi-bin">

AllowOverride None

Options ExecCGI -MultiViews +SymLinksIfOwnerMatch

Order allow,deny

Allow from all

</Directory>

ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,

# alert, emerg.

LogLevel debug

CustomLog /var/log/apache2/access.log combined

#Additional log in order to know the serial number of the certificate that

#has been successfully accepted by the web server

CustomLog /var/log/apache2/access.log "%h %t Client with certificate's serial

number %{SSL_CLIENT_M_SERIAL}x has been authenticated %u %x \"%r\" %b"

ServerSignature On

Alias /doc/ "/usr/share/doc/"

<Directory "/usr/share/doc/">

Options Indexes MultiViews FollowSymLinks

AllowOverride None

Order deny,allow

Deny from all

Allow from 127.0.0.0/255.0.0.0 ::1/128

</Directory>

</VirtualHost>

Page 192: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 192/204

Annex 6 – Configuration ocsp daemon

# OCSPd example configuration file.

# (c) 2001 by Massimiliano Pala - OpenCA Project.

# All rights reserved

[ ocspd ]

default_ocspd = OCSPD_default # The default ocspd section

####################################################################

[ OCSPD_default ]

dir = /usr/local/etc/ocspd # Where everything is kept

db = $dir/index.txt # database index file.

md = sha1

ca_certificate = $dir/ca/cacert.pem # The CA certificate

ocspd_certificate = $dir/certs/ocspd_cert.pem # The OCSP server cert

ocspd_key = $dir/private/ocspd_key.pem # The OCSP server key

pidfile = $dir/ocspd.pid # Main process pid

# User and Group the server will run as. It is a good idea

# not having servers running as root: in case of errors in

# the code providing an 'illegal' access method for an attacker

# it is better not to give him additional advantages.

user = ocspd

group = daemon

# Bind to a specific address. This option is useful if you need

# to listen only on one IP among the availables ones.

bind = 172.16.1.238

# Port where the server will listen for incoming requests.

port = 2560

# Max size of accepted requests. Data connection will be closed

# in case this size will be reached.

max_req_size = 8192

# Number of threads that shall be created at startup time, the

# more threads, the better for handling very high traffic. We

# expect to have better performances on multi-threaded machines

# and processors.

threads_num = 150

# Max timeout for request receiving. If a request is not received

# within the specified number of seconds then the socket is closed

# in order to free unused threads. If not set, the default value

# is 5 seconds

max_timeout_secs = 5

# Chroot the application into the specified directory, whatch

# out because if you chroot the application, all the paths

# should be relative to the new root for CRL reloading or

# (better solution) you have to download the CRLs from HTTP or

# LDAP. If you chroot and you do not provide support for

# privileges dropping, privileges will not be dropped and an

# error will be written in the logfile, but the server will

# continue to run assuming the chroot() is sufficiently isolated

# to prevent abuse of the machine.

# chdir = /usr/local

# Auto Reload interval of CRL (if set to 0 or not present, to

# reload the CRL you'll need to send a SIGHUP (kill -1 <pid>)

Page 193: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 193/204

# to the parent process (seconds)

crl_auto_reload = 3600

# Check CRL validity period. If this parameter is set to #n

# then the CRL is checked every #n secs and if the CRL's validity

# period is expired then all the responses will be set to

# 'unknown'.

# If 'crl_check_validity' is set to '0' or it is absent, all

# responses will be based on the loaded CRL, no matter if it

# is expired or not.

crl_check_validity = 600

# Reload CRL if the one loaded is expired. Set this parameter

# only if you are sure that the new CRL will be issued and put

# in the crl_url.

crl_reload_expired = yes

# Specifies the response section to load the server options

# from

response = ocsp_response

# It specifies the section to be used where options about where

# CRL and certificates are kept.

#

# Example section using LDAP for data retrival

# dbms = dbms_ldap

#

# Example section using FILES for data retrival

dbms = dbms_file

# Enables the ENGINE interface for the server. If set to off then

# no support for ENGINE is loaded. If set to anything but 'off' the

# value must correspond to a section in this configuration file.

# Currently only LunaCA3, LunaSA are directly supported. If you need

# support for other HSM write to the authors.

#

# IMPORTANT NOTE: in case of usage with engine support enabled, put

# the private key ID - look at the HSM documentation - into the

# 'ocspd_key' field above in this file

engine = HSM

####################################################################

[ ocsp_response ]

dir = /usr/local/etc/ocspd

# It is possible to include additional certificates in given

# responses. Put all the certificates you want to include in

# the file pointed by 'ocsp_add_responses_certs', concatenated

# one after the other.

#

# Comment this option if you don't want to add certificates

# to responses.

ocsp_add_response_certs = $dir/certs/chain_certs.pem

# Set this option if you want to include the KeyID. If you are

# unsure about this setting, use 'yes'.

ocsp_add_response_keyid = yes

# next_update_days and next_update_mins allows to specify in

# each response when new revocation data will be available.

# If the two options are both set to '0' the 'nextUpdate' field

# in the OCSP response will be left NULL indicating new data

# can be made available anytime (this is true if you are issuing

# new CRLs every time a revocation takes place)

#

# NOTE: Firefox/Mozilla do not parse correctly the OCSP answer in

Page 194: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 194/204

# case the nextUpdate field is missing. It is therefore suggested

# to use the next_update_mins set (e.g. 5 minutes) to have mozilla's

# software correclty work with OCSP enabled.

next_update_days = 0

next_update_mins = 5

####################################################################

[ dbms_ldap ]

0.ca = @ldap_ca_1

[ ldap_ca_1 ]

# You can have the CRL on a simple file

# crl_url = file:///usr/local/etc/ocspd/crl.pem

# You can have the CRL retrieved from an HTTP server

# crl_url = http://[user[:pwd]@]server[:port]/path_to_crl

# You can store the CRL into an LDAP server, simply

# store it in certificateRevocationList;binary attribute

#

# There are different way, all legal, to specify the CRL

# URL address:

# crl_url = ldap://[user[:pwd]@]ldap.server.org[:389]

# crl_url = ldap://ldap.server.org:389

crl_url = ldap://localhost

# The CRL entry DN is the DN to look for when retrieving the

# date from the LDAP server. Put here the complete DN (usually

# the DN of the CA's certificate).

#

# This option is needed only if the CRL is stored on LDAP

#crl_entry_dn = "cn=Certification Auth, o=Organization, c=IT"

# To retrieve the CRL from LDAP the attribute where it is stored is to

# be specified. Usually this should be set to:

#

# certificateRevocationList;binary

#

# anyway existing LDAP installations or new standards can mandate

# for different attributes for storing CRLs into. Use this parameter

# to specify the attribute used to retrieve the CRL from.

#

# This option is needed only if the CRL is stored on LDAP

crl_entry_attribute = "certificateRevocationList;binary"

# We need the CA certificate for every CA we support. Upon loading

# the CRL and the CA certificate a simple check is made to ensure

# the CRL/CA certificate matching. Also the CA certificate is used

# to retrieve the CID used to identify the certificate being

# requested by the client (CID of the Issuer + serial Number).

#

# DN where the cACertificate;binary value can be downloaded

# This option is needed only if the CA Certificate is stored on LDAP

#ca_entry_dn = "o=Organisation, c=IT"

####################################################################

[ dbms_file ]

# We can have as many CAs supported as we want, each CRL will be

# loaded and stored upon server starting

0.ca = @ITSSPA_ca

#1.ca = @second_ca

Page 195: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 195/204

####################################################################

[ ITSSPA_ca ]

# You can have the CRL on a simple file in PEM format

crl_url = file:////usr/local/etc/ocspd/crl/cacrl.pem

# We need the CA certificate for every supported CRL

ca_url = file:////usr/local/etc/ocspd/ca/cacert.pem

####################################################################

[ second_ca ]

# You can have the CRL on a simple file in PEM format

#crl_url = file:////usr/local/etc/ocspd/crls/crl_02.pem

# We need the CA certificate for every supported CRL

#ca_url = file:////usr/local/etc/ocspd/certs/2nd_cacert.pem

####################################################################

[ HSM ]

# Setup parameters for basic lunaCA3/LunaSA crypto hardware.

# Specifies the ENGINE id to be used - check OpenSSL and your HSM

# vendor to get more info about this parameter.

engine_id = LunaCA3

# Some HSM need initialisation before access to the crypto accelerated

# functions is granted. It is possible, by using the 'engine_pre' options

# to issue needed commands directly to the HSM.

#

# The format is as follows:

# 0.engine_pre = cmd:values

# 1.engine_pre = cmd2:values

# ...

# It is possible to have as many commands as needed.

# The following command is for LunaCA3/LunaSA. It forces the vendor's

# library to use '/etc/my_conf_file' as configuration file (check the

# HSM documentation about this file contents.

#0.engine_pre = CONF_PATH:/etc/my_conf_file

# The following is for LunaCA3/LunaSA where the command is 'login' and

# the value is "1:10:11:myPassword" which indicates to use Slot 1,

# high application id 10, low app id 11 and password "myPassword"

0.engine_pre = login:1:10:11:myPassword

# Some HSMs need to perform commands after the ENGINE initialisation

# which are taken from the 'engine_post' option. Usage and format

# is exactly the same as 'engine_pre', the difference is that commands

# are sent to the HSM after the ENGINE_init() function. Refer to your

# HSM documentation for more informations

# 0.engine_post = logout:1:10:11

Page 196: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 196/204

Annex 7 – Perl module managing OCSP request to the VA

AddHandler cgi-script .pm

AddHandler cgi-handler .pm

PerlModule /etc/apache2/mods-enabled/SSLLookup.pm

NameVirtualHost 172.16.1.238:443

<VirtualHost 172.16.1.238:443>

ServerAdmin webmaster@localhost

SSLEngine on

SSLCertificateFile /etc/apache2/webserver/webserver.pem

SSLOptions +StdEnvVars +ExportCertData

SSLCertificateKeyFile /etc/apache2/webserver/webserver.key

SSLCAcertificateFile /usr/local/etc/ocspd/ca/cacert.crt

SSLVerifyClient require

<Directory /var/www/TEST_CERTIF>

SSLRequireSSL

Options +Indexes

SSLOptions +StdEnvVars +ExportCertData

SSLVerifyDepth 5

SetHandler perl-script

PerlHandler Apache2::OCSP

</Directory>

DocumentRoot /var/www/

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

<Directory /var/www/>

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

allow from all

</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory "/usr/lib/cgi-bin">

AllowOverride None

Options ExecCGI -MultiViews +SymLinksIfOwnerMatch

Order allow,deny

Allow from all

</Directory>

ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,

# alert, emerg.

LogLevel warn

CustomLog /var/log/apache2/access.log combined

ServerSignature On

Alias /doc/ "/usr/share/doc/"

<Directory "/usr/share/doc/">

Options Indexes MultiViews FollowSymLinks

AllowOverride None

Order deny,allow

Deny from all

Allow from 127.0.0.0/255.0.0.0 ::1/128

</Directory>

</VirtualHost>

Page 197: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 197/204

Annex 8 – ALERT bash script

#Infinite loop

while : do

#Change directory in order to point in the correct one

cd /var/log/apache2/

#test if error.log is newer than ALERTsend_temp, if there are some new error logs. if [ error.log -nt ALERTsend_temp ]; then

#parse error.log until the string "Certificate with serial […] revoked", put this log in ALERTtemp file

err_cert_revoked=$(tail -1 error.log | grep "Certificate with serial" error.log | grep "revoked" >

ALERTtemp)

#Check if ALERTtemp and ALERTsend_temp are different (time and date) diff ALERTtemp ALERTsend_temp &> /dev/null

#test if ALERTtemp has a newer entry of "certificate revoked" in comparison to ALERTsend_temp file

if [ $? -eq 1 ]; then cp ALERTtemp ALERTsend_temp

#Isolate the last line

log=$(tail -1 ALERTsend_temp | grep "Certificate with serial" error.log | grep "revoked" > ALERTsend) last_log=$(tail -1 ALERTsend > ALERTsend_final)

#Send the mail to the admin to alert him of the problem

mailx -s "Revoked certificate trying to connect ITSSPA application" [email protected] <

ALERTsend_final

fi

fi done

Page 198: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 198/204

Annex 9 – NEWcrl bash script

#infinite loop

while :

do

#directory

cd /usr/local/openca/ca/var/crypto/crls

#Check if cacrl.txt is newer than cacrl.txt.old

diff cacrl.txt cacrl.txt.old &> /dev/null

#if cacrl.txt is newer, copy all crl format in ocsp directory

if [ $? -eq 1 ]; then

cp cacrl.* /usr/local/etc/ocspd/crl/

cp cacrl.txt cacrl.txt.old

fi

done

Page 199: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 199/204

Annex 10 – CRLexpire bash script

#Infinite loop

while :

do

#Change directory

cd /var/log/

#Test if daemon.log is newer than CRL_expired_temp

if [ daemon.log -nt CRL_expired_temp ]; then

CRL_has_expired=$(tail -2 daemon.log | grep "WARNING::CRL" daemon.log |

grep "[ITSSPA_ca]" daemon.log | grep "IS EXPIRED" daemon.log > CRL_expired)

#Check if CRL_expired andd CRL_expired_temp are different (time and

date)

diff CRL_expired CRL_expired_temp &> /dev/null

#Test if CRL_expired has a newer entry of "CRL IS EXPIRED" in

comparison to CRL_expired_temp

if [ $? -eq 1 ]; then

cp CRL_expired CRL_expired_temp

#Isolate the next to last line, where the log inidicates that the CRL

has expired

expiration_log=$(head -2 CRL_expired_temp | tail -1 CRL_expired_temp >

CRL_expire_send)

#Send the information to the administrator

mailx -s "CRL has expired !! You should issue a new CRL"

[email protected] < CRL_expire_send

fi

fi

done

Page 200: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 200/204

Annex 11 – List of possible changes of smartcard's profile parameters

Figure 125: Profile parameters that can be modified in the smartcard

(Source: Documentation of the Athena smartcard driver)

Page 201: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 201/204

Bibliography

Books

Sécurité des réseaux – Merike Kaeo – Cisco Systems – ISBN 2-7440-0850-8 Guide Pratique de sécurité informatique – Favre/Goupille – Dunod – ISBN 2-1004-8705-1

Documents

Sécurité des systèmes d'information – Course book of M.Buchs Introduction to PKI Technology – e-Xpert Solutions SA Thesis of M.Gachet – Déploiement de solutions VPN: PKI étude de cas – 2001 Etude sur la biométrie de M. Baumgartner – 2002 Thesis of M.Cotte – Public Key Infrastructure - 2000

RFC’s

RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP) RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol -

OCSP RFC 1945 – Hypertext Transfer Protocol – HTTP/1.0 RFC 2459 named "Internet X.509 Public Key Infrastructure - Certificate and CRL Profile" RFC 2315 Cryptographic Message Syntax RFC 2986 Certification Request Syntax Specification

Internet Security http://www.fullsecurity.ch/ http://www.websecurity.ir http://www.rsa.com http://www.securiteinfo.com/ General Information http://rfc-editor.org http://www.td.unige.ch http://wiki.linux-sevenler.org http://www.dicodunet.com http://www.journaldunet.com/

Page 202: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 202/204

http://www.commentcamarche.net http://www.wikipedia.org http://www.01net.com/ PKI https://www.openca.org/ http://www.openca.info/docs/guide/openca-guide.html http://www.dartmouth.edu/~pkilab/ http://www.frsirt.com/bulletins/42 http://www.tagpma.org/files/ULAGridCA-TAGPMA.ppt http://vtmig.w2k.vt.edu/docs/vtmig_pki_interop_v1.2.pdf Apache-Perl http://httpd.apache.org/docs/2.0/mod/mod_ssl.html http://perl.apache.org/docs/1.0/guide/config.html Biometrics http://www.e-xpertsolutions.com/images/pdf/moc/3_BiometricMOC.pdf http://www.athena-scs.com http://precisebiometrics.com http://www.lexum.umontreal.ca/cours/internet2000/desd/Biometrie.html Forums http://www.nabble.com/OpenCA-f3689.html http://www.developpez.net/forums http://forum.ubuntu-fr.org/ Divers http://www.diit.unict.it/users/flicandro/Materiale/ASN1.pdf http://www.codeshttp.com http://www.dia.unisa.it/~ads/corso-security/www/CORSO-0203/LDAP/IMAGE/ALB2.gif

http://www.votreopticien.com http://www.biometrie-online.net http://www.zeroshell.net

Page 203: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 203/204

List of acronyms .NET DotNet 3DES Triple Data Encryption Standard AAA Authentication Authorization Accounting AAL Authentification Automatique du Locuteur AES Advanced Encryption Standard CA Certificate Authority CAP Chip Authentication Program CAPTCHA Completely Automated Public Turing to tell Computers and

Humans Apart CHAP Challenge Handshake Authentication Protocol CHF Franc Suisse CRL Certificate Revocation List CRR Certificate Revocation Request CSR Certificate Signing Request DES Data Encryption Standard DN Distinguished Name EER Equal Error Rate FAR False Acceptation Rate FRR False Rejection Rate FTP File Transfer Protocol HTML Hypertext Mark up Language HTTP Hypertext Transfer Protocol HTTPS Secured Hypertext Transfer Protocol IBG International Biometric Group IDEA International Data Encryption Algorithm IE Internet Explorer IIS Internet Information Services (Microsoft) IP Internet Protocol IPsec Internet Protocol Security ISO International Organisation for Standardization Kc Key Client KDC Key Distribution Centre Ks Key Server KTGS Key Ticket Granting Service LDAP Lightweight Directory Access Protocol MD4 Message Digest 4 MD5 Message Digest 5 MITM Man In The Middle attack MOC Match On Card MTA Mail Transfer Agent OCSP Online Certificate Status Protocol OS Operating System OSI Open Systems Interconnection OTP One Time Password PCMCIA Personal Computer Memory Card International Association

Page 204: PKI_Thesis - Gheller Samuel

Samuel Gheller

Building of an infrastructure PKI used in an environment of a trading online system 204/204

PGP Pretty Good Privacy PIN Personal Identification Number PKCS Public Key Cryptographic Standards PKI Public Key Infrastructure PKINIT Public Key Cryptography for Initial Authentication in Kerberos RA Registration Authority RADIUS Remote Authentication Dial In User Service RSA Rivest Shamir Adleman SCEP Simple Certificate Enrollment Protocol SCVP Server-based Certificate Validation Protocol SHA-1 Secure Hash Algorithm –1 SIM Subscriber Identity Module SQL Structured Query Language SMTP Simple Mail Transfer Protocol SSH Secure Shell SSL Secure Sockets Layer TACACS+ Terminal Access Controller TCP Transmission Control Protocol Telnet TELetype NETwork TGS Ticket Granting Service TGT Ticket Granting Ticket TLS Transport Layer Security URI Uniform Resource Information URL Uniform Resource Locator USB Universal Serial Bus VA Validation Authority VB Visual Basic VPN Virtual Private Network