PKI - Thesis - Gheller Samuel

Samuel Gheller
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
Building of an infrastructure PKI used in an environment of a trading online system 1/204

Samuel Gheller
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

Samuel Gheller
- 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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
< THEORY >

Samuel Gheller
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]

Samuel Gheller
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 n ⋅ (n − 1) will be necessary. It can be easy to notice that the sum of the needed keys
2
will become very huge in the case of the user network, which will be composed of an
increasing number of users.

Samuel Gheller
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)

Samuel Gheller
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)

Samuel Gheller
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

Samuel Gheller
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.
Green key: session key
Yellow key: public key

Session
key Red key: private 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)

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
Who has done it ?

Trace-
ability
Integrity Who can modify it ?
Confidentiality Who can see it ?
Authorization Who can access?
Strong authentication Who's who ?
Figure 8: Strong authentication pyramid

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

Samuel Gheller
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)
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.
Figure 10: Time token

3.2.2.3 Counter token (OTP type)
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.
Figure 11: Counter token

Samuel Gheller
3.2.2.4 Smartcard token (PKI type)
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. 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.
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.
Figure 13: USB token
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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 K C .
º Every server also owns an encrypted private key that is called K S .
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

Samuel Gheller
º KDC knows about KC and KTGS private keys.

º Ticket server (TGS – Ticket Granting Service) owns a private key named KTGS and also
knows K S 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 K Session (2). All this information is
sent and is thus encrypted with K C client's private key. K Session 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 K Session 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).
3
4
Figure 17: Kerberos mechanisms

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

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

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.

Samuel Gheller
Figure 19: Use of a trusted third party

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.

Samuel Gheller
Figure 20: X509v3 certificate

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]

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.
FRR FAR
EER
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.
Biometrics systems suppress risks

Copy Stealing Oversight Loss
Key
Badge
Code
Biometrics
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.

Samuel Gheller
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.
Registering of a user
Signature
Seizure Processing File
Morphological
Transmittal of the
comparison result Comparison
towards the application
Element
Signature
Seizure Processing
File
Figure 23: User registration process

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.

Samuel Gheller
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:

Samuel Gheller
٠ 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.

Samuel Gheller
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.

Samuel Gheller
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

٠ 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.

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.
CA ADMINISTRATOR
CA
SERVER
RA SERVER PUBLIC SERVER

RA PKI
ADMINISTRATOR CLIENT
Figure 29: Thin client (web based) solution


Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
< PRACTICE >

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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);

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
--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]

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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:
CA certificate
Every certificates (CA, RA, users, etc.)
Certificate Revocation Lists
Certificate Revocation Requests
Requests of certificate
Figure 37: Tables created in CA's database at the initialization

Samuel Gheller
• 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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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)

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)

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)

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.

Samuel Gheller
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:

Samuel Gheller
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)

Samuel Gheller
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)

Samuel Gheller
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)

Chain OUTPUT (policy ACCEPT)


Samuel Gheller
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-

Samuel Gheller
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

Samuel Gheller
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
support@pki.openca.org, 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 "s.gheller@itsoftware.it"

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
- 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.

Samuel Gheller
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.

Samuel Gheller
- 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

Samuel Gheller
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.

Samuel Gheller
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.
Figure 61: Enrolling of validated certificates from CA to RA

Samuel Gheller
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
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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.
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.

Samuel Gheller
14.2 Approval of the process by CA administrator
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

Samuel Gheller
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.
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
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.

Samuel Gheller
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 : samuel.gheller@heig-vd.ch
- 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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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:
Public authority that trusts

the whole below structure
Private authority that

manages the certificates
Figure 77: Private PKI trusted by a public one

Samuel Gheller
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.

Samuel Gheller
<Building and Realization>

Samuel Gheller
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)

Samuel Gheller
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

Samuel Gheller
/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

Samuel Gheller
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

Samuel Gheller
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).

Samuel Gheller
- 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)

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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
36
OCSP over HTTP.”
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

Samuel Gheller
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

Samuel Gheller
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/emailAddress=s.gheller@itsoftware.it
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.

Samuel Gheller
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:
Value
Variable Name: Description:
Type:
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

Samuel Gheller
certificate
Algorithm used for the public key of client's
SSL_CLIENT_A_KEY string
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)
Algorithm used for the signature of server's
SSL_SERVER_A_SIG string
certificate
Algorithm used for the public key of server's
SSL_SERVER_A_KEY string
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.

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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" samuel.gheller@heig-vd.ch <

/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.

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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).

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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)"
/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)"
/TEST_CERTIF/logo-its.jpg HTTP/1.0" -

Samuel Gheller
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)"
/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

Samuel Gheller
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)

Samuel Gheller
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.

Samuel Gheller
Figure 101: Valid and non-valid certificates stored over the smartcard

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
23. Task’s planning

Samuel Gheller
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

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
Annexes
Figure 111: PKCS Standards

(Source: http://en.wikipedia.org/wiki/PKCS)

Samuel Gheller
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.

Samuel Gheller
2.2 Face
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.
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.

Samuel Gheller
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).

Samuel Gheller
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 in1072 , according to Mr.

Samuel Gheller
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.

Samuel Gheller
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.

Samuel Gheller
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.
Pen pressure
Time
Vertical move Horizontal move

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:

Samuel Gheller
- The time that is taken to hit and keep the key.

- The time between two different keys pressed.
Key hold
down time User hitting
profile
TIME BETWEEN TWO HITS

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.

Samuel Gheller
Annex 3 – Configuration of Apache for PKI server
<VirtualHost 172.16.1.63:443>
ServerAdmin sam_gheller@hotmail.com
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
#Protect CA files form intrusions

<Directory /var/www/ca/ >
SSLOptions +StdEnvVars
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 >
SSLVerifyDepth 5
</Location>
#Protect CA-node files from intrusion

<Directory /var/www/ca-node >
SSLVerifyDepth 5
</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 >
SSLVerifyDepth 5
</Location>
#Protect RA files from intrusion

<Directory /var/www/ra >

Samuel Gheller
SSLVerifyDepth 5
#The client certificate must be RA's ("IT Software RA")
SSLRequire (%{SSL_CLIENT_S_DN_CN} eq "IT Software RA")
</Directory>
in /cgi-bin/ra/RAServer...
<Location /cgi-bin/ra/RAServer >
SSLVerifyDepth 5
</Location>
#Protect RA-node files from intrusion

<Directory /var/www/ra-node >
SSLVerifyDepth 5
</Directory>
in /cgi-bin/ra-node/node...
<Location /cgi-bin/ra-node/node >
SSLVerifyDepth 5
</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

Samuel Gheller
# 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>

Samuel Gheller
Annex 4 – config.xml of the CA (the global configuration file of the

CA)
<?xml version="1.0" encoding="UTF-8"?>
<openca>
<software_config>

<prefix>@</prefix>
<suffix>@</suffix>




<option>
<name>default_language</name>
<value>C</value>
</option>
<option>
<name>default_charset</name>
<value>UTF-8</value>
</option>
<option>

<name>cert_chars</name>
<value>LATIN1</value>
</option>
<option>

<name>ca_organization</name>
<value>IT Software</value>
</option>

Samuel Gheller
<option>

<name>ca_locality</name>
<value>Milano</value>
</option>
<option>

<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>s.gheller@itsoftware.it</value>
</option>
<option>
<name>policy_link</name>
<value>https://172.16.1.63/pub/policy.html</value>
</option>




<option>
<name>httpd_protocol</name>
<value>https</value>
</option>
<option>
<name>httpd_host</name>
<value>172.16.1.63</value>
</option>
<option>


<name>httpd_port</name>
<value>:443</value>
</option>
<option>
<name>menu_logo_left</name>
<value>

</value>
</option>
<option>
<name>menu_logo_right</name>
<a href="__HTDOCS_PREFIX__/thanks.html">

Samuel Gheller
<img src="__HTDOCS_PREFIX__/images/openca-logo.png"
alt="OpenCA Logo"/>
</a>
<value></value>
</option>
<option>

<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>




<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>




<option>
<name>dbmodule</name>

<value>DBI</value>
</option>
<option>
<name>db_type</name>
<value>Pg</value>
</option>
<option>

Samuel Gheller
<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>
</option>
<option>
<name>db_passwd</name>
</option>
<option>
<name>db_namespace</name>

</option>




<option>
<name>module_shift</name>


<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>

Samuel Gheller
</option>




<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>




<option>
<name>batch_htdocs_fs_prefix</name>
<value>/var/www/batch</value>

Samuel Gheller
</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>




<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>

Samuel Gheller




<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>









Samuel Gheller























<option>
<value>VALID</value>
</option>
<option>
</option>
<option>
</option>
<option>
<value>ARCHIVED DELETED APPROVED</value>
</option>
<option>
<value>ARCHIVED DELETED</value>
</option>
<option>
<value>CRINS DEFAULT</value>
</option>
<option>
<value>APPROVED</value>
</option>
<option>
</option>
<option>
<value></value>
</option>
<option>
<value></value>

Samuel Gheller
</option>
<option>
<value></value>
</option>
<option>
<value></value>
</option>
<option>
<value></value>
</option>
<option>
<value></value>
</option>
<option>
<value></value>
</option>
<option>
<value></value>
</option>
















<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>

Samuel Gheller
Annex 5 – Apache configuration for web server (check validity with

CRL)
<VirtualHost 172.16.1.238:443>
ServerAdmin webmaster@localhost
SSLEngine on
SSLCACertificateFile /etc/apache2/webserver/ca/cacert.crt
SSLVerifyDepth 1
SSLCARevocationFile /etc/apache2/webserver/crls/cacrl.pem
DocumentRoot /var/www/
<Directory />
AllowOverride None
</Directory>
<Directory /var/www/>
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>

AllowOverride None
Order allow,deny
Allow from all
</Directory>

# alert, emerg.
LogLevel debug
#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

AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>

Samuel Gheller
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>)

Samuel Gheller
# 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

Samuel Gheller
# 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

Samuel Gheller
####################################################################
[ 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

Samuel Gheller
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
<VirtualHost 172.16.1.238:443>
ServerAdmin webmaster@localhost
SSLEngine on
SSLCAcertificateFile /usr/local/etc/ocspd/ca/cacert.crt
<Directory /var/www/TEST_CERTIF>
SSLRequireSSL
Options +Indexes
SSLVerifyDepth 5
SetHandler perl-script
PerlHandler Apache2::OCSP
</Directory>
DocumentRoot /var/www/
<Directory />
AllowOverride None
</Directory>
<Directory /var/www/>
AllowOverride None
Order allow,deny
allow from all
</Directory>

AllowOverride None
Order allow,deny
Allow from all
</Directory>

# alert, emerg.
LogLevel warn

ServerSignature On

AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
</VirtualHost>

Samuel Gheller
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" samuel.gheller@heig-vd.ch <
ALERTsend_final
fi
fi
done

Samuel Gheller
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

Samuel Gheller
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"
sam_gheller@hotmail.com < CRL_expire_send
fi
fi
done

Samuel Gheller
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)

Samuel Gheller
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/

Samuel Gheller
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

Samuel Gheller
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

Samuel Gheller
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

PKI - Thesis - Gheller Samuel

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PKI - Thesis - Gheller Samuel

Загружено:

Авторское право:

Доступные форматы

Samuel Gheller

Building of an infrastructure PKI used in an

PROFESSOR: STEFANO VENTURA

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

"Building of an infrastructure PKI1 used in an environment of a trading online system"

Currently, IT Software (www.itsoftware.it) develops and distributes trading online systems

٠ suggest and verify one or more architectural solutions

Work will be divided in two distinguished parts:

1) Logistic and organisation aspects

- Written definition of the proposed architecture

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

- Setting up of the organizational aspects (automatic procedures of

Web-based integration example

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

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

5.2 TECHNOLOGIES ............................................................................................................................................50

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

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

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

22.1 AUTHENTICATED STANDARD CERTIFICATE...............................................................................................152

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

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

Figure 45: Download certificate onto token ..........................................................................87

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

Figure 93: Choice of the correct certificate .........................................................................146

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

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

Results and state

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

M. Petracchi, for his precious know-how in Linux environment.

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

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

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

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

Building and realization:

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

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

< THEORY >

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

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

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

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

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

2.1 Symmetric key encryption

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

Figure 1: Symmetric encryption

Figure 2: Diffie-Hellman Algorithm

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

2.2 Asymmetric key encryption

The key management is consequently less critical as apposed to what is suggested by a

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

Figure 3: Asymmetric key encryption

2.3 Hybrid encryption

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

Green key: session key

Yellow key: public key

Figure 4: Hybrid encryption

2.4 Hash function

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

Here are some of the most popular hash functions:

2.5 "Man in the middle" attack (MITM)

Figure 5: Man in the middle attack

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