Remove an extra space char in PKIs.tex
[ach-master.git] / src / theory / PKIs.tex
index a5b87ac..abd5fb8 100644 (file)
@@ -1,15 +1,32 @@
 \section{Public Key Infrastructures}
 \label{section:PKIs}
 
 \section{Public Key Infrastructures}
 \label{section:PKIs}
 
-Public-Key Infrastructures aim to provide a way to simplify the verification of
-a certificate's trustworthiness.  For this, certificate authorities (CAs) are
-used to create a signature chain from the root CA down to the server (or client).
-Accepting a CA as a generally-trusted mediator solves the trust-scaling problem
-at the cost of introducing an actor that magically is more trustworthy.
+Public-Key Infrastructures try to solve the problem of verifying
+whether a public key belongs to a given entity, so as to prevent Man
+In The Middle attacks.
 
 
-The first part of this section addresses how to obtain a certificate.  The
-second part offers recommendations on how to improve the security of your
-PKI.
+There are two approaches to achieve that: \emph{Certificate Authorities}
+and the \emph{Web of Trust}.
+
+Certificate Authorities (CAs) sign end-entities' certificates, thereby
+associating some kind of identity (e.g. a domain name or an email
+address) with a public key. CAs are used with TLS and S/MIME
+certificates, and the CA system has a big list of possible and real
+problems which are summarized in section \ref{sec:hardeningpki} and~\cite{https13}.
+
+The Web of Trust is a decentralized system where people sign each
+other's keys, so that there is a high chance that there is a ``trust
+path'' from one key to another. This is used with PGP keys, and while
+it avoids most of the problems of the CA system, it is more
+cumbersome.
+
+As alternatives to these public systems, there are two more choices:
+running a private CA, and manually trusting keys (as it is used with
+SSH keys or manually trusted keys in web browsers).
+
+The first part of this section addresses how to obtain a certificate
+in the CA system. The second part offers recommendations on how to
+improve the security of your PKI.
 
 \subsection{Certificate Authorities}
 \label{sec:cas}
 
 \subsection{Certificate Authorities}
 \label{sec:cas}
@@ -26,23 +43,28 @@ certificates for money.  Some of the most ubiquitous commercial CAs are
 Verisign, GoDaddy, and Teletrust.  However, there are also CAs that offer
 certificates for free.  The most notable examples are StartSSL, which is a
 company that offers some types of certificates for free, and CAcert, which
 Verisign, GoDaddy, and Teletrust.  However, there are also CAs that offer
 certificates for free.  The most notable examples are StartSSL, which is a
 company that offers some types of certificates for free, and CAcert, which
-is a non-profit volunteer-based organisation that does not charge at all
+is a non-profit volunteer-based organization that does not charge at all
 for issuing certificates.  Finally, in the research and education field, a
 number of CAs exist that are generally well-known and well-accepted within
 the higher-education community.
 
 for issuing certificates.  Finally, in the research and education field, a
 number of CAs exist that are generally well-known and well-accepted within
 the higher-education community.
 
+A large number of CAs is pre-installed in client software's or
+operating system's``trust stores''; depending on your application, you
+have to select your CA according to this, or have a mechanism to
+distribute the chosen CA's root certificate to the clients.
+
 When requesting a certificate from a CA, it is vital that you generate the
 key pair yourself.  In particular, the private key should never be known to
 the CA.  If a CA offers to generate the key pair for you, you should not
 trust that CA.
 
 When requesting a certificate from a CA, it is vital that you generate the
 key pair yourself.  In particular, the private key should never be known to
 the CA.  If a CA offers to generate the key pair for you, you should not
 trust that CA.
 
-Generating a key pair and a certificate request can be done with a number
-of tools.  On Unixoid systems, it is likely that the OpenSSL suite is
-available to you.  In this case, you can generate a private key and a
-corresponding certificate request as follows:
+Generating a key pair and a certificate request can be done with a number of
+tools.  On Unix-like systems, it is likely that the OpenSSL suite is available
+to you.  In this case, you can generate a private key and a corresponding
+certificate request as follows:
 
 
-\begin{lstlisting}[breaklines]
-% openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
+\begin{lstlisting}
+% openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
 Country Name (2 letter code) [AU]:DE
 State or Province Name (full name) [Some-State]:Bavaria
 Locality Name (eg, city) []:Munich
 Country Name (2 letter code) [AU]:DE
 State or Province Name (full name) [Some-State]:Bavaria
 Locality Name (eg, city) []:Munich
@@ -74,7 +96,7 @@ following commands on a Debian system:
 % sudo ./CA.pl -newca
 \end{lstlisting}
 
 % sudo ./CA.pl -newca
 \end{lstlisting}
 
-Answer the questions according to your setup. Now that you have configured your basic settings and 
+Answer the questions according to your setup. Now that you have configured your basic settings and
 issued a new root certificate, you can issue new certificates as follows:
 
 \begin{lstlisting}
 issued a new root certificate, you can issue new certificates as follows:
 
 \begin{lstlisting}
@@ -82,6 +104,10 @@ issued a new root certificate, you can issue new certificates as follows:
 % sudo ./CA.pl -newreq
 \end{lstlisting}
 
 % sudo ./CA.pl -newreq
 \end{lstlisting}
 
+Alternatively, software such as TinyCA~\cite{Wikipedia:TinyCA} that
+acts as a ``wrapper'' around OpenSSL and tries to make life easier is
+available.
+
 \subsubsection{Creating a Self-Signed Certificate}
 \label{sec:pki:selfsignedcert}
 If the desired trust level is very high and the number of systems involved
 \subsubsection{Creating a Self-Signed Certificate}
 \label{sec:pki:selfsignedcert}
 If the desired trust level is very high and the number of systems involved
@@ -91,12 +117,17 @@ CA at all, but is signed by the entity that it is issued to.  Thus, the
 organizational overhead of running a CA is eliminated at the expense of
 having to establish all trust relationships between entities manually.
 
 organizational overhead of running a CA is eliminated at the expense of
 having to establish all trust relationships between entities manually.
 
-With OpenSSL, a self-signed certificate may be created with this command:
+With OpenSSL, you can self-sign a previously created certificate with this command:
 
 \begin{lstlisting}
 % openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
 \end{lstlisting}
 
 
 \begin{lstlisting}
 % openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
 \end{lstlisting}
 
+You can also create a self-signed certificate in just one command:
+\begin{lstlisting}
+openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
+\end{lstlisting}
+
 The resulting certificate will by default not be trusted by anyone at all,
 so in order to be useful, the certificate will have to be made known a
 priori to all parties that may encounter it.
 The resulting certificate will by default not be trusted by anyone at all,
 so in order to be useful, the certificate will have to be made known a
 priori to all parties that may encounter it.
@@ -104,21 +135,21 @@ priori to all parties that may encounter it.
 
 \subsection{Hardening PKI}
 \label{sec:hardeningpki}
 
 \subsection{Hardening PKI}
 \label{sec:hardeningpki}
-In recent years several CAs were compromised by attackers in order to
-get ahold of trusted certificates for malicious activities. In 2011 
-the Dutch CA Diginotar was hacked and all certificates were
-revoked~\cite{diginotar-hack}. Recently Google found certificates
-issued to them, which were not used by the
+
+In recent years several CAs were compromised by attackers in order to get a
+hold of trusted certificates for malicious activities. In 2011 the Dutch CA
+Diginotar was hacked and all certificates were revoked~\cite{diginotar-hack}.
+Recently Google found certificates issued to them, which were not used by the
 company~\cite{googlecahack}. The concept of PKIs heavily depends on the
 company~\cite{googlecahack}. The concept of PKIs heavily depends on the
-security of CAs.  If they get compromised the whole PKI system will
-fail. Some CAs tend to incorrectly issue certificates that were designated
-to do a different job than what they were intended to by the CA~\cite{gocode}.
+security of CAs.  If they get compromised the whole PKI system will fail. Some
+CAs tend to incorrectly issue certificates that were designated to do a
+different job than what they were intended to by the CA~\cite{gocode}.
 
 Therefore several security enhancements were introduced by different
 
 Therefore several security enhancements were introduced by different
-organisations and vendors~\cite{tschofenig-webpki}. Currently two
+organizations and vendors~\cite{tschofenig-webpki}. Currently two
 methods are used, DANE~\cite{rfc6698} and Certificate
 Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
 methods are used, DANE~\cite{rfc6698} and Certificate
 Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
-a new system to detect malicous CAs and certificates  called Certificate 
+a new system to detect malicious CAs and certificates called Certificate
 Transparency~\cite{certtransparency}.
 
 % \subsubsection{DANE}
 Transparency~\cite{certtransparency}.
 
 % \subsubsection{DANE}
@@ -141,7 +172,7 @@ Transparency~\cite{certtransparency}.
 % A good background on PKIs can be found in
 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
 % A good background on PKIs can be found in
 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
-% \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
+% \footnote{\url{https://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
 % .
 
 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
 % .
 
 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
@@ -152,4 +183,4 @@ Transparency~\cite{certtransparency}.
 %   plugins: CipherFox, Conspiracy, Perspectives.}
 
 
 %   plugins: CipherFox, Conspiracy, Perspectives.}
 
 
-% ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)
+% ``Certificate Policy''~\cite{Wikipedia:Certificate_Policy} (CA)