Merge branch 'master' of https://git.bettercrypto.org/ach-master
[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,
17 or you run your own CA. In the later case you normally speak of self-signed 
18 certificates. For both cases there are pro and contra points 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, Teletrust, etc.
24 These certificates are mostly issued for 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 generate the 
28 private key not on the CAs system. You can generate a private key and a corresponding 
29 certificate request as follows:
30
31 \begin{lstlisting}[breaklines]
32 % openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
33 Country Name (2 letter code) [AU]:DE
34 State or Province Name (full name) [Some-State]:Bavaria
35 Locality Name (eg, city) []:Munich
36 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
37 Organizational Unit Name (eg, section) []:Example Section
38 Common Name (e.g. server FQDN or YOUR name) []:example.com
39 Email Address []:admin@example.com
40
41 Please enter the following 'extra' attributes
42 to be sent with your certificate request
43 A challenge password []:
44 An optional company name []:
45 \end{lstlisting}
46
47 \subsubsection{Setting up your own Certificate Authority}
48 \label{sec:setupownca}
49 In some situations it is sufficient to use your own CA certificates. An example is a own OpenVPN
50 installation or if only systems communicate with each other, which do not act with users. Creating
51 a own CA can be accomplished using OpenSSL:
52
53 \begin{lstlisting}
54 % cd /usr/lib/ssl/misc
55 % sudo ./CA.pl -newca
56 \end{lstlisting}
57
58 Answer the questions according to your setup. Now you have configured your basic settings and 
59 issued a new root certificate. Now you can issue new certificates as follows:
60
61 \begin{lstlisting}
62 % cd /usr/lib/ssl/misc
63 % sudo ./CA.pl -newreq
64 \end{lstlisting}
65
66 \subsection{Hardening PKI}
67 \label{sec:hardeningpki}
68 In recent years several CAs were compromised by attackers in order to
69 get trusted certificates for malicious activities. In 2011 the Dutch
70 CA Diginotar was hacked and all certificates were
71 revoked~\cite{diginotar-hack}. Recently Google found certificates
72 issued to them, which were not used by the
73 company~\cite{googlecahack}. The concept of PKIs heavily depends on the
74 security of CAs.  If they get compromised the whole PKI system will
75 fail.
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}.
81
82 % \subsubsection{DANE}
83 % \label{sec:dane}
84
85 % \subsubsection{Certificate Pinning}
86 % \label{sec:certpinning}
87
88
89
90 % This section deals with settings related to trusting CAs. However,
91 % our main recommendations for PKIs is: if you are able to run your
92 % own PKI and disable any other CA, do so. This makes sense most in
93 % environments where any machine-to-machine communication system
94 % compatibility with external entities is not an issue.
95 %% azet: this needs discussion! self-signed certificates simply do not
96 %% work in practices for real-world scenarios - i.e. websites that
97 %% actually serve a lot of people
98
99 % A good background on PKIs can be found in
100 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
101 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
102 % \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
103 % .
104
105 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
106 %   TLSA integration, When to use self-signed certificates, how to get
107 %   certificates from public CA authorities (CACert, StartSSL),
108 %   Best-practices how to create a CA and how to generate private
109 %   keys/CSRs, Discussion about OCSP and CRLs. TD: Useful Firefox
110 %   plugins: CipherFox, Conspiracy, Perspectives.}
111
112
113 % ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)