reformat ECC section
[ach-master.git] / src / theory / PKIs.tex
1 \section{Public Key Infrastructures}
2 \label{section:PKIs}
3
4 Public-Key Infrastructures try to solve the problem of verifying
5 whether a public key belongs to a given entity, so as to prevent Man
6 In The Middle attacks.
7
8 There are two approaches to achieve that: {\it Certificate Authorities}
9 and the {\it Web of Trust}.
10
11 Certificate Authorities (CAs) sign end-entities' certificates, thereby
12 associating some kind of identity (e.g. a domain name or an email
13 address) with a public key. CAs are used with TLS and S/MIME
14 certificates, and the CA system has a big list of possible and real
15 problems which are summarized in section \ref{sec:hardeningpki} and
16 \cite{https13}.
17
18 The Web of Trust is a decentralized system where people sign each
19 others keys, so that there is a high chance that there is a ``trust
20 path'' from one key to another. This is used with PGP keys, and while
21 it avoids most of the problems of the CA system, it is more
22 cumbersome.
23
24 As alternatives to these public systems, there are two more choices:
25 running a private CA, and manually trusting keys (as it is used with
26 SSH keys or manually trusted keys in web browsers).
27
28 The first part of this section addresses how to obtain a certificate
29 in the CA system. The second part offers recommendations on how to
30 improve the security of your PKI.
31
32 \subsection{Certificate Authorities}
33 \label{sec:cas}
34 In order to get a certificate, you can find an external CA willing to issue
35 a certificate for you, run your own CA, or use self-signed certificates.
36 As always, there are advantages and disadvantages for every one of these
37 options; a balance of security versus usability needs to be found.
38
39 \subsubsection{Certificates From an External Certificate Authority}
40 \label{sec:signcertfromca}
41
42 There is a fairly large number of commercial CAs that will issue
43 certificates for money.  Some of the most ubiquitous commercial CAs are
44 Verisign, GoDaddy, and Teletrust.  However, there are also CAs that offer
45 certificates for free.  The most notable examples are StartSSL, which is a
46 company that offers some types of certificates for free, and CAcert, which
47 is a non-profit volunteer-based organization that does not charge at all
48 for issuing certificates.  Finally, in the research and education field, a
49 number of CAs exist that are generally well-known and well-accepted within
50 the higher-education community.
51
52 A large number of CAs is pre-installed in client software's or
53 operating system's``trust stores''; depending on your application, you
54 have to select your CA according to this, or have a mechanism to
55 distribute the chosen CA's root certificate to the clients.
56
57 When requesting a certificate from a CA, it is vital that you generate the
58 key pair yourself.  In particular, the private key should never be known to
59 the CA.  If a CA offers to generate the key pair for you, you should not
60 trust that CA.
61
62 Generating a key pair and a certificate request can be done with a number of
63 tools.  On Unix-like systems, it is likely that the OpenSSL suite is available
64 to you.  In this case, you can generate a private key and a corresponding
65 certificate request as follows:
66
67 \begin{lstlisting}[breaklines]
68 % openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
69 Country Name (2 letter code) [AU]:DE
70 State or Province Name (full name) [Some-State]:Bavaria
71 Locality Name (eg, city) []:Munich
72 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
73 Organizational Unit Name (eg, section) []:Example Section
74 Common Name (e.g. server FQDN or YOUR name) []:example.com
75 Email Address []:admin@example.com
76
77 Please enter the following 'extra' attributes
78 to be sent with your certificate request
79 A challenge password []:
80 An optional company name []:
81 \end{lstlisting}
82
83 \subsubsection{Setting Up Your Own Certificate Authority}
84 \label{sec:setupownca}
85 In some situations it is advisable to run your own certificate authority.
86 Whether this is a good idea depends on the exact circumstances.  Generally
87 speaking, the more centralized the control of the systems in your
88 environment, the fewer pains you will have to go through to deploy your own
89 CA.  On the other hand, running your own CA maximizes the trust level that
90 you can achieve because it minimizes external trust dependencies.
91
92 Again using OpenSSL as an example, you can set up your own CA with the
93 following commands on a Debian system:
94
95 \begin{lstlisting}
96 % cd /usr/lib/ssl/misc
97 % sudo ./CA.pl -newca
98 \end{lstlisting}
99
100 Answer the questions according to your setup. Now that you have configured your basic settings and 
101 issued a new root certificate, you can issue new certificates as follows:
102
103 \begin{lstlisting}
104 % cd /usr/lib/ssl/misc
105 % sudo ./CA.pl -newreq
106 \end{lstlisting}
107
108 Alternatively, software such as TinyCA\cite{Wikipedia:TinyCA} that
109 acts as a ``wrapper'' around OpenSSL and tries to make life easier is
110 available.
111
112 \subsubsection{Creating a Self-Signed Certificate}
113 \label{sec:pki:selfsignedcert}
114 If the desired trust level is very high and the number of systems involved
115 is limited, the easiest way to set up a secure environment may be to use
116 self-signed certificates.  A self-signed certificate is not issued by any
117 CA at all, but is signed by the entity that it is issued to.  Thus, the
118 organizational overhead of running a CA is eliminated at the expense of
119 having to establish all trust relationships between entities manually.
120
121 With OpenSSL, a self-signed certificate may be created with this command:
122
123 \begin{lstlisting}
124 % openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
125 \end{lstlisting}
126
127 The resulting certificate will by default not be trusted by anyone at all,
128 so in order to be useful, the certificate will have to be made known a
129 priori to all parties that may encounter it.
130
131
132 \subsection{Hardening PKI}
133 \label{sec:hardeningpki}
134
135 In recent years several CAs were compromised by attackers in order to get a
136 hold of trusted certificates for malicious activities. In 2011 the Dutch CA
137 Diginotar was hacked and all certificates were revoked~\cite{diginotar-hack}.
138 Recently Google found certificates issued to them, which were not used by the
139 company~\cite{googlecahack}. The concept of PKIs heavily depends on the
140 security of CAs.  If they get compromised the whole PKI system will fail. Some
141 CAs tend to incorrectly issue certificates that were designated to do a
142 different job than what they were intended to by the CA~\cite{gocode}.
143
144 Therefore several security enhancements were introduced by different
145 organizations and vendors~\cite{tschofenig-webpki}. Currently two
146 methods are used, DANE~\cite{rfc6698} and Certificate
147 Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
148 a new system to detect malicious CAs and certificates  called Certificate 
149 Transparency~\cite{certtransparency}.
150
151 % \subsubsection{DANE}
152 % \label{sec:dane}
153
154 % \subsubsection{Certificate Pinning}
155 % \label{sec:certpinning}
156
157
158
159 % This section deals with settings related to trusting CAs. However,
160 % our main recommendations for PKIs is: if you are able to run your
161 % own PKI and disable any other CA, do so. This makes sense most in
162 % environments where any machine-to-machine communication system
163 % compatibility with external entities is not an issue.
164 %% azet: this needs discussion! self-signed certificates simply do not
165 %% work in practices for real-world scenarios - i.e. websites that
166 %% actually serve a lot of people
167
168 % A good background on PKIs can be found in
169 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
170 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
171 % \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
172 % .
173
174 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
175 %   TLSA integration, When to use self-signed certificates, how to get
176 %   certificates from public CA authorities (CACert, StartSSL),
177 %   Best-practices how to create a CA and how to generate private
178 %   keys/CSRs, Discussion about OCSP and CRLs. TD: Useful Firefox
179 %   plugins: CipherFox, Conspiracy, Perspectives.}
180
181
182 % ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)