moved PKIs.tex to theory/
authorAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 20:31:26 +0000 (21:31 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Mon, 23 Dec 2013 20:31:26 +0000 (21:31 +0100)
src/theory/PKIs.tex [new file with mode: 0644]

diff --git a/src/theory/PKIs.tex b/src/theory/PKIs.tex
new file mode 100644 (file)
index 0000000..a5b87ac
--- /dev/null
@@ -0,0 +1,155 @@
+\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.
+
+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.
+
+\subsection{Certificate Authorities}
+\label{sec:cas}
+In order to get a certificate, you can find an external CA willing to issue
+a certificate for you, run your own CA, or use self-signed certificates.
+As always, there are advantages and disadvantages for every one of these
+options; a balance of security versus usability needs to be found.
+
+\subsubsection{Certificates From an External Certificate Authority}
+\label{sec:signcertfromca}
+
+There is a fairly large number of commercial CAs that will issue
+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
+is a non-profit volunteer-based organisation 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.
+
+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:
+
+\begin{lstlisting}[breaklines]
+% openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
+Country Name (2 letter code) [AU]:DE
+State or Province Name (full name) [Some-State]:Bavaria
+Locality Name (eg, city) []:Munich
+Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
+Organizational Unit Name (eg, section) []:Example Section
+Common Name (e.g. server FQDN or YOUR name) []:example.com
+Email Address []:admin@example.com
+
+Please enter the following 'extra' attributes
+to be sent with your certificate request
+A challenge password []:
+An optional company name []:
+\end{lstlisting}
+
+\subsubsection{Setting Up Your Own Certificate Authority}
+\label{sec:setupownca}
+In some situations it is advisable to run your own certificate authority.
+Whether this is a good idea depends on the exact circumstances.  Generally
+speaking, the more centralized the control of the systems in your
+environment, the fewer pains you will have to go through to deploy your own
+CA.  On the other hand, running your own CA maximizes the trust level that
+you can achieve because it minimizes external trust dependencies.
+
+Again using OpenSSL as an example, you can set up your own CA with the
+following commands on a Debian system:
+
+\begin{lstlisting}
+% cd /usr/lib/ssl/misc
+% sudo ./CA.pl -newca
+\end{lstlisting}
+
+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}
+% cd /usr/lib/ssl/misc
+% sudo ./CA.pl -newreq
+\end{lstlisting}
+
+\subsubsection{Creating a Self-Signed Certificate}
+\label{sec:pki:selfsignedcert}
+If the desired trust level is very high and the number of systems involved
+is limited, the easiest way to set up a secure environment may be to use
+self-signed certificates.  A self-signed certificate is not issued by any
+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.
+
+With OpenSSL, a self-signed certificate may be created with this command:
+
+\begin{lstlisting}
+% openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
+\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.
+
+
+\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
+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}.
+
+Therefore several security enhancements were introduced by different
+organisations 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
+a new system to detect malicous CAs and certificates  called Certificate 
+Transparency~\cite{certtransparency}.
+
+% \subsubsection{DANE}
+% \label{sec:dane}
+
+% \subsubsection{Certificate Pinning}
+% \label{sec:certpinning}
+
+
+
+% This section deals with settings related to trusting CAs. However,
+% our main recommendations for PKIs is: if you are able to run your
+% own PKI and disable any other CA, do so. This makes sense most in
+% environments where any machine-to-machine communication system
+% compatibility with external entities is not an issue.
+%% azet: this needs discussion! self-signed certificates simply do not
+%% work in practices for real-world scenarios - i.e. websites that
+%% actually serve a lot of people
+
+% 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}}
+% .
+
+% \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
+%   TLSA integration, When to use self-signed certificates, how to get
+%   certificates from public CA authorities (CACert, StartSSL),
+%   Best-practices how to create a CA and how to generate private
+%   keys/CSRs, Discussion about OCSP and CRLs. TD: Useful Firefox
+%   plugins: CipherFox, Conspiracy, Perspectives.}
+
+
+% ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)