Nick Gordon | f3a9ecb | 2017-01-24 13:55:14 -0600 | [diff] [blame] | 1 | \section{Security} |
| 2 | \label{sec:security} |
| 3 | |
| 4 | The trust model of NLSR is semi-hierarchical. An example certificate signing hierarchy is show in Figure~\ref{fig:trust}. |
| 5 | In this hierarchy, each entity's name and corresponding certificate name follow the convention described in Table~\ref{table:kname}. |
| 6 | |
| 7 | \begin{figure} |
| 8 | \centering |
| 9 | \includegraphics[width=0.5\linewidth]{figures/trust-hierarchy.eps} |
| 10 | \caption{NLSR Trust Hierarchy} |
| 11 | \label{fig:trust} |
| 12 | %\vspace{-3mm} |
| 13 | \end{figure} |
| 14 | |
| 15 | \begin{table} |
| 16 | \centering |
| 17 | \caption{Key Names} |
| 18 | \small |
| 19 | \begin{tabular}{|l|l|} |
| 20 | \hline |
| 21 | \bfseries {Key Owner} & \bfseries {Key Name}\\ \hline |
| 22 | Network & /$<$network$>$/KEY/$<$key$>$\\ \hline |
| 23 | Site & /$<$network$>$/$<$site$>$/KEY/$<$key$>$\\ \hline |
| 24 | Operator & /$<$network$>$/$<$site$>$/$<$operator$>$/KEY/$<$key$>$\\\hline |
| 25 | Router & /$<$network$>$/$<$site$>$/$<$router$>$/KEY/$<$key$>$\\\hline |
| 26 | NLSR & /$<$network$>$/$<$site$>$/$<$router$>$/NLSR/KEY/$<$key$>$\\\hline |
| 27 | \end{tabular} |
| 28 | \label{table:kname} |
| 29 | \vspace{-3mm} |
| 30 | \end{table} |
| 31 | |
| 32 | \subsection{Creating Keys and Certificates} |
| 33 | |
| 34 | The process to create keys and certificates for this hierarchy can be performed using the \texttt{ndnsec}~\cite{ndnsec} tools included with \texttt{ndn-cxx}~\cite{NDNCXX}. |
| 35 | The steps to create the keys and certificates is outlined below: |
| 36 | |
| 37 | \begin{enumerate} |
| 38 | \item Create keys for Root: \\ \texttt{ndnsec-keygen \$ROOT\_NAME > \$ROOT\_KEY\_OUTPUT\_FILE} |
| 39 | \item Create certificate for Root: \\ \texttt{ndnsec-certgen -N \$ROOT\_NAME -p \$ROOT\_NAME \$ROOT\_KEY\_OUTPUT\_FILE > \$ROOT\_CERT\_OUTPUT\_FILE} |
| 40 | \item For each site, create keys and certificates: |
| 41 | \begin{enumerate} |
| 42 | \item On the Site machine, generate keys for the Site: \\ \texttt{ndnsec-keygen \$SITE\_NAME > \$SITE\_KEY\_OUTPUT\_FILE} |
| 43 | \item Copy \texttt{\$SITE\_KEY\_OUTPUT\_FILE} over to the machine where the Root certificate was created. |
| 44 | \item Generate a certificate for the Site on the Root machine: \\ \texttt{ndnsec-certgen -N \$SITE\_NAME -p \$SITE\_NAME -s \$ROOT\_NAME \$SITE\_KEY\_OUTPUT\_FILE > \$SITE\_CERT\_OUTPUT\_FILE} |
| 45 | \item Copy \texttt{\$SITE\_CERT\_OUTPUT\_FILE} over to the Site machine. |
| 46 | \item Install the certificate on the Site machine: \\ \texttt{ndnsec-cert-install -f \$SITE\_CERT\_OUTPUT\_FILE} |
| 47 | \item On the Site machine, create the Operator keys: \\ \texttt{ndnsec-keygen \$OP\_NAME > \$OP\_KEY\_OUTPUT\_FILE} |
| 48 | \item On the Site machine, create the Operator certificate: \\ \texttt{ndnsec-certgen -N \$OP\_NAME -p \$OP\_NAME -s \$SITE\_NAME \$OP\_KEY\_OUTPUT\_FILE > \$OP\_CERT\_OUTPUT\_FILE} |
| 49 | \item On the Site machine, create the Router keys: \\ \texttt{ndnsec-keygen \$ROUTER\_NAME > \$ROUTER\_KEY\_OUTPUT\_FILE} |
| 50 | \item On the Site machine, create the Router certificate: \\ \begin{small}\texttt{ndnsec-certgen -N \$ROUTER\_NAME -p \$ROUTER\_NAME -s \$OP\_NAME \$ROUTER\_KEY\_OUTPUT\_FILE > \$ROUTER\_CERT\_OUTPUT\_FILE}\end{small} |
| 51 | \end{enumerate} |
| 52 | \item When NLSR starts, it will automatically create the NLSR keys and certificates for the router. |
| 53 | \end{enumerate} |
| 54 | |
| 55 | \subsection{Certificate Publishing} |
| 56 | |
Nick Gordon | 221531c | 2017-06-08 11:44:45 -0500 | [diff] [blame^] | 57 | In a network, every router must have the root certificate configured as a trust anchor for the \texttt{validator} in the configuration file. If two routers in a network do not share a common trust anchor, then when one seeks to validate the data of the other, they may be unable to establish trust in their signature. This is, of course, because of how the trust hierarchy is set up: you trust the person that signed some router's certificate, because it was signed by the site certificate, and the site certificate was signed by the region, etc., and the $nth$ certificate was signed by the root certificate, which is your trust anchor, so you ``just trust it''. Moreover, if your trust anchor is \emph{before} their trust anchor in the ``chain'', then they will be able to trust you, but you will not be able to trust them. |
| 58 | |
Nick Gordon | f3a9ecb | 2017-01-24 13:55:14 -0600 | [diff] [blame] | 59 | For each site, at least one router should publish the site certificate, and at least one router should publish the certificate of the site operator. |
Nick Gordon | 221531c | 2017-06-08 11:44:45 -0500 | [diff] [blame^] | 60 | Each router should publish its own certificate. This is a matter of performance; a network would work if all certificates for all nodes were kept centrally, but distributing the certificates in this way improves performance. |
Nick Gordon | f3a9ecb | 2017-01-24 13:55:14 -0600 | [diff] [blame] | 61 | All this information must be explicitly specified in the configuration file. |
| 62 | |
| 63 | For example, the following configuration file indicates that NLSR should publish the site certificate and the router certificate: |
| 64 | |
| 65 | \begin{verbatim} |
| 66 | ... |
| 67 | security |
| 68 | { |
| 69 | validator |
| 70 | { |
| 71 | ... |
| 72 | } |
| 73 | cert-to-publish "$SITE_CERT_OUTPUT_FILE" ; name of the site certificate file |
| 74 | cert-to-publish "$SITE_CERT_OUTPUT_FILE" ; name of the router certificate file |
| 75 | ... |
| 76 | } |
Nick Gordon | 221531c | 2017-06-08 11:44:45 -0500 | [diff] [blame^] | 77 | \end{verbatim} |