PKI: CA.pl is debian/ubuntu. specific, no such thing on RHEL or SLES or EL
[ach-master.git] / src / 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 In the first part of this section an overview is given, how to get a certificate from
11 a trusted CA, or how to setup your own CA. In the second part recommendations will be 
12 given how you can improve the security of PKIs.
13
14 \section{Certificate Authorities}
15 \label{sec:cas}
16 In order to get a certificate, you either go to a CA which will issue a certificate for you,
17 or you run your own CA. In the latter case one normally speaks of self-signed 
18 certificates. For both cases there are pros and contras and the decision is
19 as always security versus usability.
20
21 \subsubsection{Signed Certificates form a trusted Certificate Authority}
22 \label{sec:signcertfromca}
23 Trusted certificates are mostly issued by commercial CAs, such as Verisign, GoDaddy, Teletrust, etc.
24 These certificates are mostly issued for a specified time period and cost money. Nevertheless
25 there are also free trusted CAs available, such as StartSSL, or CACert.
26
27 If you consider getting a signed certificate from a trusted CA, you should not let the CA generate the 
28 private key for you. You can generate a private key and a corresponding certificate request as follows:
29
30 \begin{lstlisting}[breaklines]
31 % openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
32 Country Name (2 letter code) [AU]:DE
33 State or Province Name (full name) [Some-State]:Bavaria
34 Locality Name (eg, city) []:Munich
35 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
36 Organizational Unit Name (eg, section) []:Example Section
37 Common Name (e.g. server FQDN or YOUR name) []:example.com
38 Email Address []:admin@example.com
39
40 Please enter the following 'extra' attributes
41 to be sent with your certificate request
42 A challenge password []:
43 An optional company name []:
44 \end{lstlisting}
45
46 \subsubsection{Setting up your own Certificate Authority}
47 \label{sec:setupownca}
48 In some situations it is sufficient to use your own certificate authority. An example is an OpenVPN
49 installation or if only internal systems communicate with each other, without interaction with users. 
50 Creating a CA can be accomplished using OpenSSL (Debian):
51
52 \begin{lstlisting}
53 % cd /usr/lib/ssl/misc
54 % sudo ./CA.pl -newca
55 \end{lstlisting}
56
57 Answer the questions according to your setup. Now you have configured your basic settings and 
58 issued a new root certificate. Now you can issue new certificates as follows:
59
60 \begin{lstlisting}
61 % cd /usr/lib/ssl/misc
62 % sudo ./CA.pl -newreq
63 \end{lstlisting}
64
65 \subsection{Hardening PKI}
66 \label{sec:hardeningpki}
67 In recent years several CAs were compromised by attackers in order to
68 get ahold of trusted certificates for malicious activities. In 2011 
69 the Dutch CA Diginotar was hacked and all certificates were
70 revoked~\cite{diginotar-hack}. Recently Google found certificates
71 issued to them, which were not used by the
72 company~\cite{googlecahack}. The concept of PKIs heavily depends on the
73 security of CAs.  If they get compromised the whole PKI system will
74 fail. Some CAs tend to incorrectly issue certificates that were designated
75 to do a different job than what they were intended to by the CA~\cite{gocode}.
76
77 Therefore several security enhancements were introduced by different
78 organisations and vendors~\cite{tschofenig-webpki}. Currently two
79 methods are used, DANE~\cite{rfc6698} and Certificate
80 Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
81 a new system to detect malicous CAs and certificates  called Certificate 
82 Transparency~\cite{certtransparency}.
83
84 % \subsubsection{DANE}
85 % \label{sec:dane}
86
87 % \subsubsection{Certificate Pinning}
88 % \label{sec:certpinning}
89
90
91
92 % This section deals with settings related to trusting CAs. However,
93 % our main recommendations for PKIs is: if you are able to run your
94 % own PKI and disable any other CA, do so. This makes sense most in
95 % environments where any machine-to-machine communication system
96 % compatibility with external entities is not an issue.
97 %% azet: this needs discussion! self-signed certificates simply do not
98 %% work in practices for real-world scenarios - i.e. websites that
99 %% actually serve a lot of people
100
101 % A good background on PKIs can be found in
102 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
103 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
104 % \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
105 % .
106
107 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
108 %   TLSA integration, When to use self-signed certificates, how to get
109 %   certificates from public CA authorities (CACert, StartSSL),
110 %   Best-practices how to create a CA and how to generate private
111 %   keys/CSRs, Discussion about OCSP and CRLs. TD: Useful Firefox
112 %   plugins: CipherFox, Conspiracy, Perspectives.}
113
114
115 % ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)