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 get trusted 
69 certificates for malicious activities. In 2011 the Dutch CA Diginotar was hacked and
70 all certificates were revoked. Recently Google found certificates issued to them, which
71 were not used by the company. The concept of PKIs heavily depends on the security of CAs. 
72 If they get compromised the whole PKI system will fail.
73
74 Therefore several security enhancements were introduced by different organisations and
75 vendors~\ref{tschofenig-webpki}. Currently two methods are used, DANE and Certificate Pinning.
76
77 % \subsubsection{DANE}
78 % \label{sec:dane}
79
80 % \subsubsection{Certificate Pinning}
81 % \label{sec:certpinning}
82
83
84
85 % This section deals with settings related to trusting CAs. However, our main
86 % recommendations for PKIs is: if you are able to run your own PKI and disable
87 % any other CA, do so. This makes sense most in environments where any machine-to-machine
88 % communication system compatibility with external entities is not an issue.
89 %% azet:
90 %% this needs discussion! self-signed certificates simply do not work in practices
91 %% for real-world scenarios - i.e. websites that actually serve a lot of people
92
93 % A good background on PKIs can be found in 
94 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
95 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
96 % \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
97 % .
98
99 \todo{ts: Background and Configuration (EMET) of Certificate Pinning, TLSA integration, 
100   When to use self-signed certificates, how to get certificates from public CA authorities 
101   (CACert, StartSSL), Best-practices how to create a CA and how to generate private keys/CSRs, 
102   Discussion about OCSP and CRLs. TD: Useful Firefox plugins: CipherFox, Conspiracy, Perspectives.}
103
104
105 %``Certificate Policy''\cite{Wikipedia:Certificate_Policy}
106 %(CA)