Added Certificate Authorization Authority records and corrected a few typos in my...
[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: \emph{Certificate Authorities}
9 and the \emph{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~\cite{https13}.
16
17 The Web of Trust is a decentralized system where people sign each
18 other's keys, so that there is a high chance that there is a ``trust
19 path'' from one key to another. This is used with PGP keys, and while
20 it avoids most of the problems of the CA system, it is more
21 cumbersome.
22
23 As alternatives to these public systems, there are two more choices:
24 running a private CA, and manually trusting keys (as it is used with
25 SSH keys or manually trusted keys in web browsers).
26
27 The first part of this section addresses how to obtain a certificate
28 in the CA system. The second part offers recommendations on how to
29 improve the security of your PKI.
30
31 \subsection{Certificate Authorities}
32 \label{sec:cas}
33 In order to get a certificate, you can find an external CA willing to issue
34 a certificate for you, run your own CA, or use self-signed certificates.
35 As always, there are advantages and disadvantages for every one of these
36 options; a balance of security versus usability needs to be found.
37
38 \subsubsection{Certificates From an External Certificate Authority}
39 \label{sec:signcertfromca}
40
41 There is a fairly large number of commercial CAs that will issue
42 certificates for money.  Some of the most ubiquitous commercial CAs are
43 Verisign, GoDaddy, and Teletrust.  However, there are also CAs that offer
44 certificates for free.  The most notable examples are StartSSL, which is a
45 company that offers some types of certificates for free, and CAcert, which
46 is a non-profit volunteer-based organization that does not charge at all
47 for issuing certificates.  Finally, in the research and education field, a
48 number of CAs exist that are generally well-known and well-accepted within
49 the higher-education community.
50
51 A large number of CAs is pre-installed in client software's or
52 operating system's``trust stores''; depending on your application, you
53 have to select your CA according to this, or have a mechanism to
54 distribute the chosen CA's root certificate to the clients.
55
56 When requesting a certificate from a CA, it is vital that you generate the
57 key pair yourself.  In particular, the private key should never be known to
58 the CA.  If a CA offers to generate the key pair for you, you should not
59 trust that CA.
60
61 Generating a key pair and a certificate request can be done with a number of
62 tools.  On Unix-like systems, it is likely that the OpenSSL suite is available
63 to you.  In this case, you can generate a private key and a corresponding
64 certificate request as follows:
65
66 \begin{lstlisting}
67 % openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
68 Country Name (2 letter code) [AU]:DE
69 State or Province Name (full name) [Some-State]:Bavaria
70 Locality Name (eg, city) []:Munich
71 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
72 Organizational Unit Name (eg, section) []:Example Section
73 Common Name (e.g. server FQDN or YOUR name) []:example.com
74 Email Address []:admin@example.com
75
76 Please enter the following 'extra' attributes
77 to be sent with your certificate request
78 A challenge password []:
79 An optional company name []:
80 \end{lstlisting}
81
82 \subsubsection{Setting Up Your Own Certificate Authority}
83 \label{sec:setupownca}
84 In some situations it is advisable to run your own certificate authority.
85 Whether this is a good idea depends on the exact circumstances.  Generally
86 speaking, the more centralized the control of the systems in your
87 environment, the fewer pains you will have to go through to deploy your own
88 CA.  On the other hand, running your own CA maximizes the trust level that
89 you can achieve because it minimizes external trust dependencies.
90
91 Again using OpenSSL as an example, you can set up your own CA with the
92 following commands on a Debian system:
93
94 \begin{lstlisting}
95 % cd /usr/lib/ssl/misc
96 % sudo ./CA.pl -newca
97 \end{lstlisting}
98
99 Answer the questions according to your setup. Now that you have configured your basic settings and
100 issued a new root certificate, you can issue new certificates as follows:
101
102 \begin{lstlisting}
103 % cd /usr/lib/ssl/misc
104 % sudo ./CA.pl -newreq
105 \end{lstlisting}
106
107 Alternatively, software such as TinyCA~\cite{Wikipedia:TinyCA} that
108 acts as a ``wrapper'' around OpenSSL and tries to make life easier is
109 available.
110
111 \subsubsection{Creating a Self-Signed Certificate}
112 \label{sec:pki:selfsignedcert}
113 If the desired trust level is very high and the number of systems involved
114 is limited, the easiest way to set up a secure environment may be to use
115 self-signed certificates.  A self-signed certificate is not issued by any
116 CA at all, but is signed by the entity that it is issued to.  Thus, the
117 organizational overhead of running a CA is eliminated at the expense of
118 having to establish all trust relationships between entities manually.
119
120 With OpenSSL, you can self-sign a previously created certificate with this command:
121
122 \begin{lstlisting}
123 % openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
124 \end{lstlisting}
125
126 You can also create a self-signed certificate in just one command:
127 \begin{lstlisting}
128 openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
129 \end{lstlisting}
130
131 The resulting certificate will by default not be trusted by anyone at all,
132 so in order to be useful, the certificate will have to be made known a
133 priori to all parties that may encounter it.
134
135
136 \subsection{Hardening PKI}
137 \label{sec:hardeningpki}
138
139 In recent years several CAs were compromised by attackers in order to get a
140 hold of trusted certificates for malicious activities. In 2011 the Dutch CA
141 Diginotar was hacked and all certificates were revoked~\cite{diginotar-hack}.
142 Recently Google found certificates issued to them, which were not used by the
143 company~\cite{googlecahack}. The concept of PKIs heavily depends on the
144 security of CAs.  If they get compromised the whole PKI system will fail. Some
145 CAs tend to incorrectly issue certificates that were designated to do a
146 different job than what they were intended to by the CA~\cite{gocode}.
147
148 Therefore several security enhancements were introduced by different
149 organizations and vendors~\cite{tschofenig-webpki}. Currently two
150 methods are used, DANE~\cite{rfc6698} and Certificate
151 Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
152 a new system to detect malicious CAs and certificates called Certificate
153 Transparency~\cite{certtransparency}. In addition, RFC 6844 describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.
154
155 % \subsubsection{DANE}
156 % \label{sec:dane}
157
158 % \subsubsection{Certificate Pinning}
159 % \label{sec:certpinning}
160
161 \subsection{Certification Authorization Records}
162 \label{sec:caarecords}
163
164 RFC 6844 describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.
165  
166 When a CAA record is defined for a particular domain, it specifies that the domain owner requests Certificate Authorities to validate any request against the CAA record. If the certificate issuer is not listed in the CAA record, it should not issue the certificate.
167  
168 The RFC also permits Certificate Evaluators to test an issued certificate against the CAA record, but should exercise caution, as the CAA record may change during the lifetime of a certificate, without affecting its validity.
169  
170 CAA also supports an iodef property type which can be requested by a Certificate Authority to report certificate issue requests which are inconsistent with the issuer’s Certificate Policy.
171
172 \subsubsection{Configuration of CAA records}
173 \label{sec:pki:caarecords:configuration}
174  
175 BIND supports CAA records as of version 9.9.6.
176  
177 A CAA record can be configured by adding it to the zone file:
178
179 \begin{lstlisting}
180 $ORIGIN example.com
181        CAA 0 issue "ca1.example"
182        CAA 0 iodef "mailto:security@example.com"
183 \end{lstlisting}
184  
185 If your organization uses multiple CA’s, you can configure multiple records:
186
187 \begin{lstlisting} 
188       CAA 0 issue "ca1.example"
189       CAA 0 issue "ca2.example"
190 \end{lstlisting}
191  
192 “ca1.example” and “ca2.example” are unique identifiers for the CA you plan on using. These strings can be obtained from your Certificate Authority, and typically are its top level domain. An example is “letsencrypt.org” for the Let’s Encrypt CA operated by the Internet Security Research Group.
193  
194 Knot-DNS supports CAA records as of version 2.2.0.
195  
196 \subsubsection{Validation of CAA records}
197 \label{sec:pki:caarecords:validation}
198  
199 Once a CAA record is deployed, it can be validated using the following dig query:
200  
201 \begin{lstlisting} 
202 user@system:~$ dig CAA google.com
203  
204 ; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com
205  
206 ;; ANSWER SECTION:
207 google.com.          3600 IN   CAA  0 issue "symantec.com"
208 \end{lstlisting}
209
210 On older versions of Dig, which do not support CAA records, you can query the record type manually:
211
212 \begin{lstlisting} 
213 dig +short -t TYPE257 google.com
214 \# 19 0005697373756573796D616E7465632E636F6D
215 \end{lstlisting}
216
217 % This section deals with settings related to trusting CAs. However,
218 % our main recommendations for PKIs is: if you are able to run your
219 % own PKI and disable any other CA, do so. This makes sense most in
220 % environments where any machine-to-machine communication system
221 % compatibility with external entities is not an issue.
222 %% azet: this needs discussion! self-signed certificates simply do not
223 %% work in practices for real-world scenarios - i.e. websites that
224 %% actually serve a lot of people
225
226 % A good background on PKIs can be found in
227 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
228 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
229 % \footnote{\url{https://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
230 % .
231
232 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
233 %   TLSA integration, When to use self-signed certificates, how to get
234 %   certificates from public CA authorities (CACert, StartSSL),
235 %   Best-practices how to create a CA and how to generate private
236 %   keys/CSRs, Discussion about OCSP and CRLs. TD: Useful Firefox
237 %   plugins: CipherFox, Conspiracy, Perspectives.}
238
239
240 % ``Certificate Policy''~\cite{Wikipedia:Certificate_Policy} (CA)