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