\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 \emph{Wikipedia}~\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 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{OAEP} (\emph{PKCS\#1 v2}) 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 \emph{Wikipedia}~\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 où 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 de toutes attaques.
+Toujours d'après \emph{Wikipedia}~\cite{wiki-key-size}, une taille de clef \emph{AES} de 128 bits reste, actuellement, hors de portée de toutes attaques.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\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 = 512\,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.
Le type \texttt{vint} correspond à un entier de taille variable, initialement occupant un octet.
-Comme les clefs (\emph{AES} et \emph{HMAC-SHA256}) sont différentes à chaque chiffrement, que le \emph{MAC} dépend de sa clef et des données chiffrées et que la signature dépend du \emph{MAC} alors l'ensemble des octets des différentes parties du fichier résultat va être fortement différent d'un chiffrement à l'autre pour le même fichier en entrée.
+Comme les clefs (\emph{AES} et \emph{HMAC-SHA256}) sont différentes à chaque chiffrement, que le \emph{MAC} dépend de sa clef et des données chiffrées et que la signature dépend du \emph{MAC}, alors l'ensemble des octets des différentes parties du fichier résultat va être fortement différent d'un chiffrement à l'autre pour le même fichier en entrée.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Il est possible de compiler la solution à l'aide de \emph{MonoDevelop}\footnote{\monodevelop} ou de \emph{Visual Studio 2012}. Le script \emph{Bash} \texttt{labo2-fsharp/run\_tests.sh} permet de compiler la solution puis d'exécuter un certain nombre de tests.
-À partir du dossier \texttt{labo2-fsharp} et après avoir compiler en \emph{release} la solution, voici ce qu'il est possible d'effectuer :
+À partir du dossier \texttt{labo2-fsharp} et après avoir compilé en \emph{release} la solution, voici ce qu'il est possible d'effectuer :
\begin{itemize}
\item \texttt{CryptoFileTests/bin/Release/CryptoFileTests.exe tests} : Réalise une série de tests.
\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.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}.
+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 à 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}. Cet ensemble d'instructions est normalement supporté par l’implémentation du \emph{runtime} \emph{.NET} de \emph{Microsoft}.
+Les tests sous \emph{Windows 8} ont été fais 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} \\
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 ?}
+\subsection{Quelles sont les parties critiques du code et comment s'assure-t-on que ces parties sont correctement implémentées ?}
-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}}.
+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 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}.
projects / crypto_lab2.git / blobdiff