\urldef{\dotnetcrypto}\url{http://msdn.microsoft.com/en-us/library/System.Security.Cryptography%28v=vs.110%29.aspx}
\urldef{\monodevelop}\url{http://www.monodevelop.com/}
\urldef{\rsacryptoserviceprovider}\url{http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsacryptoserviceprovider%28v=vs.110%29.aspx}
+\urldef{\rngcryptoserviceprovider}\url{http://msdn.microsoft.com/en-us/library/system.security.cryptography.rngcryptoserviceprovider%28v=vs.110%29.aspx}
\urldef{\rsasecurity}\url{http://en.wikipedia.org/wiki/RSA_Security}
+\urldef{\wikiml}\url{http://en.wikipedia.org/wiki/ML_%28programming_language%29}
+\urldef{\rsaxmlformat}\url{http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsa.toxmlstring%28v=vs.110%29.aspx}
\title{ICR - Labo \#2 : \textit{Conception et implémentation d'un container sécurisé pour des données médicales}}
\author{G.Burri}
\subsection{Quel est le niveau de sécurité que l'on souhaite atteindre ?}
+Le niveau souhaité est de 128 bits. Cela implique l'utilisation d'une clef \emph{AES} de 128 bits et de clefs \emph{RSA} de 3072 bits d'après~\cite{wiki-key-size}.
+
+Les éléments de sécurité suivants sont requis :
+
\begin{itemize}
\item Confidentialité : les données chiffrées ne doivent pas pouvoir être décryptées par un attaquant.
\item Authenticité : un attaquant ne doit pas pouvoir forger un container. Une signature est réalisée à l'aide d'une paire de clefs \emph{RSA} publique-privée.
\subsection{Comment s'assure-t-on que les données sont stockées de manière confidentielle ? En particulier en ce qui concerne les méta-données ?}
-Les méta-données ainsi que les données sont chiffrées ensemble. Voir le format du container décrit ci-après.
+Les méta-données ainsi que les données sont chiffrées ensemble. Voir le format du container décrit à la section~\ref{sec:format_container}.
\subsection{Comment s'assure-t-on que les données stockées sont authentiques ? Quels sont les risques à prendre en compte ?}
-L'empreinte des données est signée à l'aide d'une clef privée donnée en paramètre de l'\emph{API} : ceci représente la signature qui est placée dans le container. Lors du déchiffrement, la clef publique correspondante est fournie puis utilisée pour déchiffrer l'empreinte qui est comparée à l'empreinte des données.
+L'empreinte des données chiffrées est signée à l'aide d'une clef privée donnée en paramètre de l'\emph{API} : ceci représente la signature qui est placée dans le container. Lors du déchiffrement, la clef publique correspondante est fournie puis utilisée pour vérifier la signature avec l'empreinte des données chiffrées.
\subsection{Comment s'assure-t-on que les données stockées sont intègres ?}
Concerne les clefs externes à l'\emph{API}.
\begin{itemize}
- \item Une paire de clefs \emph{RSA-2048} pour la signature.
- \item Une paire de clefs \emph{RSA-2048} pour le chiffrement des clefs \emph{AES}.
+ \item Une paire de clefs \emph{RSA-3072} pour la signature.
+ \item Une paire de clefs \emph{RSA-3072} pour le chiffrement des clefs \emph{AES}.
\end{itemize}
\section{Choix des algorithmes et des paramètres}
\begin{itemize}
- \item \emph{RSA-2048} pour la signature ainsi que pour le chiffrage des clefs \emph{AES} et \emph{HMAC}. Le bourrage \emph{PKCS\#1 v1.5} est utilisé ;
+ \item \emph{RSA-3072} pour la signature ainsi que pour le chiffrage des clefs \emph{AES} et \emph{HMAC}. Le bourrage \emph{OAEP} (\emph{PKCS\#1 v2}) est utilisé ;
\item \emph{HMAC-SHA256} pour la vérification de l'intégrité ;
\item \emph{AES-CBC128} pour le chiffrement symétrique du contenu du fichier et des méta-données associées. Le bourrage \emph{PKCS7} est utilisé.
\end{itemize}
-D'après \cite{wiki-key-size}, la société \emph{RSA Security}\footnote{\rsasecurity} annonce qu'une taille de clefs \emph{RSA} de 2048 bits est suffisante jusqu'en 2030. Cela dépend également du niveau d'importance des documents que l'on souhaite chiffrer dans la mesure ou une attaque demande énormément de moyens.
+D'après~\cite{wiki-key-size}, la société \emph{RSA Security}\footnote{\rsasecurity} annonce qu'une taille de clefs \emph{RSA} de 3072 bits est suffisante pour une utilisation au delà de 2030. Cela dépend également du niveau d'importance des documents que l'on souhaite chiffrer dans la mesure ou une attaque demande énormément de moyens.
-Toujours d'après \cite{wiki-key-size}, une taille de clef \emph{AES} de 128 bits reste actuellement hors de portée d'une attaque.
+Toujours d'après~\cite{wiki-key-size}, une taille de clef \emph{AES} de 128 bits reste, actuellement, hors de portée de toutes attaques.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Format du container}
+\label{sec:format_container}
Le format est défini comme suit en \emph{EBNF}. Les valeurs entre crochets correspondent soit à une taille en bits soit à un type.
\begin{lstlisting}[frame=single, breaklines, basicstyle=\ttfamily\footnotesize]
container = header, ciphertext ;
-header = mac[256], signature[2048], keys[2048] ;
+header = mac[256], signature[3072], keys[3072] ;
ciphertext = AES(plaintext) ;
plaintext = meta-data, file-content ;
meta-data = nb-meta-data[byte], { key-value-pair } ;
\texttt{nb-meta-data} est le nombre de paires clef-valeur des méta-données.
-\texttt{keys} correspond aux clefs $k_c$ et $k_a$ ainsi qu'à l'\emph{IV}, le tout chiffré avec \emph{RSA-2048}. La taille des données chiffrées est égale à $k_c + k_a + iv = 128 + 256 + 128 = 640\,bits$.
+\texttt{keys} correspond aux clefs $k_c$ et $k_a$ ainsi qu'à l'\emph{IV}, le tout chiffré avec \emph{RSA-3072}. La taille des données à chiffrer est égale à $k_c + k_a + iv = 128 + 256 + 128 = 512\,bits$.
Les méta-données (\texttt{meta-data}) peuvent contenir, par exemple, le nom du fichier, sa date de création, ses droits, ou toutes autres données associées.
\end{itemize}
+Sortie :
+
+\begin{itemize}
+ \item $c$ : container chiffré.
+\end{itemize}
+
+
Processus :
\begin{enumerate}
\item Génération d'une clef 128 bits pour \emph{AES} $\rightarrow k_c$.
\item Génération d'une clef 256 bits pour \emph{MAC} $\rightarrow k_a$.
\item Génération d'un \emph{IV} 128 bits pour le mode \emph{CBC} $\rightarrow iv$.
- \item Construction du $plaintext$, voir format ci dessus.
+ \item Construction du $plaintext$ à partir de $f$, voir format décrit à la section~\ref{sec:format_container}.
\item Chiffrement du $plaintext$ avec \emph{AES-CBC128}, $k_c$ et $iv \rightarrow ciphertext$.
- \item Calcul de MAC de $ciphertext$ $\rightarrow mac$.
+ \item Calcul du \emph{HMAC-SHA256} de $ciphertext$ $\rightarrow mac$.
\item Signature de $mac$ avec $k_{signpriv}$ $\rightarrow sig$.
- \item Chiffrement de $k_c + k_a + iv$ avec $k_pub \rightarrow keys$.
- \item Renvoie $mac + sig + keys + ciphertext$.
+ \item Chiffrement de $k_c + k_a + iv$ avec $k_{pub} \rightarrow keys$.
+ \item $mac + sig + keys + ciphertext \rightarrow c$.
\end{enumerate}
Où $+$ dénote la concaténation.
\item $k_{signpub}$ : la clef publique de signature RSA
\end{itemize}
+Sortie :
+
+\begin{itemize}
+ \item $f$ : fichier original
+\end{itemize}
+
+
Processus :
\begin{enumerate}
- \item Lecture de $mac$, calcul de $mac'$ sur $c$ comparaison des deux afin de vérifier l'intégrité.
+ \item Lecture de $mac$, calcul de $mac'$ sur $c$, comparaison des deux valeurs afin de vérifier l'intégrité.
\item Vérification de la signature avec $k_{signpub}$.
\item Déchiffrement de $k_c + k_a + iv$ avec $k_{priv}$.
- \item Déchiffrement du reste des données ($ciphertext$).
+ \item Déchiffrement du reste des données ($ciphertext$) $\rightarrow f$.
\end{enumerate}
Ce processus nécessite deux cycles de lecture des données, le premier pour le calcul de $mac'$ et le deuxième pour le déchiffrement. Le deuxième cycle n'est effectué que si l'intégrité et l'authenticité ont été validées.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Implémentation}
-Nous utilisons ici la plate-forme \emph{.NET} ainsi que le langage \emph{F\#}. L'ensemble des éléments cryptographiques requis sont fournis par \emph{.NET} \footnote{\dotnetcrypto}.
+Nous utilisons ici la plate-forme \emph{.NET} ainsi que le langage \emph{F\#}, un dialecte de \emph{ML}\footnote{\wikiml}. L'ensemble des éléments cryptographiques requis sont fournis par \emph{.NET} \footnote{\dotnetcrypto}.
Deux \emph{assemblies} sont créées :
\item \emph{Types.fs} : Quelques types publics.
\item \emph{Crypto.fs} : Toutes les primitives cryptographiques nécessaires.
\item \emph{UnitTests.fs} : Quelques tests unitaires du module \emph{Crypto}.
- \item \emph{API.fs} : L'interface publique de la \emph{library}. Elle est détaillée ci-après.
+ \item \emph{API.fs} : L'interface publique de la \emph{library}. Elle est détaillée à la section~\ref{sec:api}.
\end{itemize}
\subsubsection{API}
+\label{sec:api}
Voici la partie publique de la \emph{library} \emph{CryptoFile}.
\end{lstlisting}
\end{minipage}
+Les formats des clefs, publique et privée, sont décrits sur cette page~\footnote{\rsaxmlformat}.
+
\subsection{Mesures de performance}
-Quelques mesures sur un fichier de 871 MiB ont été effectuées sous \emph{Linux} avec \emph{Mono} 3.10.0 ainsi que sous \emph{Windows 8} avec \emph{Visual Studio 2012}. Il est a noter que l'implémentation \emph{AES} de \emph{Mono} est en \emph{C\#} et n'utilise évidemment pas l’accélération matérielle d'\emph{Intel} présente sur la machine : \emph{AES-NI}.
+Quelques mesures sur un fichier de 871 MiB ont été effectuées sous \emph{Linux} avec \emph{Mono} 3.10.0 ainsi que sous \emph{Windows 8.1} avec \emph{Visual Studio 2012}. Il est a noter que l'implémentation \emph{AES} de \emph{Mono} est en \emph{C\#} et n'utilise évidemment pas l’accélération matérielle d'\emph{Intel} présente sur la machine : \emph{AES-NI}.
-Les tests sous \emph{Windows 8} ont été fait sur une machine ne possédant pas \emph{AES-NI}. Cette fonctionnalité est normalement utilisée par la version de \emph{Microsoft} du \emph{runtime} \emph{.NET}.
+Les tests sous \emph{Windows 8} ont été fait sur une machine ne possédant pas \emph{AES-NI}. Cet ensemble d'instructions est normalement supporté par l’implémentation du \emph{runtime} \emph{.NET} de \emph{Microsoft}.
\begin{tabular}{ l | r | r | r | r }
& \multicolumn{2}{c|}{Chiffrement} & \multicolumn{2}{|c}{Déchiffrement} \\
\cline{2-5}
& \multicolumn{1}{c}{\emph{Mono}} & \multicolumn{1}{|c|}{\emph{MS .NET}} & \multicolumn{1}{|c|}{\emph{Mono}} & \multicolumn{1}{c}{\emph{MS .NET}} \\
\cline{2-5}
- Temps & 39 s & 21 s & 55 s & 22 s \\
- Mémoire utilisée & 7.0 MiB & 14 MiB & 14.3 MiB & 13.9 MiB \\
+ Temps & 39 s & 20 s & 48 s & 20 s \\
+ Mémoire utilisée & 7.0 MiB & 14 MiB & 15.2 MiB & 13.9 MiB \\
Taux \emph{CPU} & 1 x 100 \% & 1 x 100 \% & 1 x 100 \% & 1 x 100 \% \\
\end{tabular}
+\subsubsection{Génération de paire de clefs \emph{RSA}}
+
+La génération de clefs \emph{RSA} est très lente sous \emph{Mono}. Pour une taille de 2048 bits cela prend environ une seconde, pour une taille de 3072 bits cela prend environ dix secondes. Sous \emph{Windows}, la version \emph{.NET} de \emph{Microsoft} est environ dix fois plus rapide.
+
\section{Analyse de la sécurité de l'implémentation}
\subsection{Quelles sont les parties critiques du code et comment s'assure-t-on que ces parties soient correctement implémentées ?}
-La génération des clefs \emph{AES} doit être faite avec un générateur cryptographique. Dans notre cas nous utilisons \emph{RSACryptoServiceProvider}\footnote{\rsacryptoserviceprovider}.
+Le choix des algorithmes, de leurs paramètres et de leur implémentation est une partie critique. Il est possible de se référer aux recommandations de certains organismes comme par exemple le \emph{NIST}\footnote{\emph{National Institute of Standards and Technology}}.
-La mémoire correspondant aux clefs générées devrait être effacée. Dans notre cas si un attaquant a accès à la mémoire de notre programme, alors il a accès au contenu des fichiers à chiffrer : il n'y a donc pas de précautions prises en particulier à ce sujet.
+La génération des clefs \emph{AES} doit être faite avec un générateur cryptographique. Dans notre cas nous utilisons \emph{RNGCryptoServiceProvider}\footnote{\rngcryptoserviceprovider}.
\subsection{Quels sont les points faibles restants et quelles sont les possibilités de les corriger ?}
-Les deux clefs privées \emph{RSA} doivent absolument rester secrètes. Pour ce faire il faudrait chiffrer les fichiers contenant ces clefs à l'aide d'une \emph{passphrase} robuste et garder celle-ci en sécurité.
+Les deux clefs privées \emph{RSA} doivent absolument rester secrètes. Pour ce faire, il faudrait chiffrer les fichiers contenant ces clefs à l'aide d'une \emph{passphrase} robuste et garder celle-ci en sécurité.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusion}
-[TODO]
-
+Ce laboratoire a permis de mettre en évidence la problématique de la sécurisation de fichiers ainsi que de leurs méta-données associées. Le choix de bons algorithmes et des bons paramètres associés est capital pour garantir la sécurité des fichiers.
\bibliographystyle{plain}
projects / crypto_lab2.git / blobdiff