X-Git-Url: http://git.euphorik.ch/?a=blobdiff_plain;f=rapport%2Fmain.tex;h=773437102be5e82f6263d28669ea7bc94ad935c7;hb=95f772ef77baee15929c1feccc4de4c9a795f81d;hp=bf0f64f4c335046215887566ba5555b3cda5ca79;hpb=2fcf3ed38874e9aa6d2ccd6b9917bd3113d76aee;p=crypto_lab2.git

diff --git a/rapport/main.tex b/rapport/main.tex
index bf0f64f..7734371 100644
--- a/rapport/main.tex
+++ b/rapport/main.tex
@@ -16,6 +16,9 @@
 \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}
 
 \title{ICR - Labo \#2 : \textit{Conception et implémentation d'un container sécurisé pour des données médicales}}
 \author{G.Burri}
@@ -68,7 +71,7 @@ Le but de ce laboratoire est de définir les algorithmes cryptographiques et leu
 
 \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 ?}
@@ -98,7 +101,7 @@ Concerne les clefs externes à l'\emph{API}.
 Concerne les clefs gérées à l'intérieur du container.
 
 \begin{itemize}
-   \item Une clef de 256 bits pour \emph{AES}.
+   \item Une clef de 128 bits pour \emph{AES}.
    \item Une clef de 256 bits pour \emph{HMAC}.
 \end{itemize}
 
@@ -108,14 +111,19 @@ Ces clefs sont générées aléatoirement à chaque création d'un container.
 \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-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{HMAC-SHA256} pour la vérification de l'intégrité ;
-   \item \emph{AES-CBC256} pour le chiffrement symétrique du contenu du fichier et des méta-données associées. Le bourrage \emph{PKCS7} est utilisé.
+   \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.
+
+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.
 
@@ -131,7 +139,7 @@ string = size[vint], content-utf8 ;
 
 \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 = 256 + 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-2048}. La taille des données chiffrées 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.
 
@@ -154,18 +162,25 @@ Entrées :
 \end{itemize}
 
 
+Sortie :
+
+\begin{itemize}
+   \item $c$ : container chiffré.
+\end{itemize}
+
+
 Processus :
 
 \begin{enumerate}
-   \item Génération d'une clef 256 bits pour \emph{AES} $\rightarrow  k_c$.
+   \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 Chiffrement du $plaintext$ avec \emph{AES-CBC256}, $k_c$ et $iv \rightarrow ciphertext$.
-   \item Calcul de MAC de $ciphertext$ $\rightarrow mac$.
+   \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 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.
@@ -181,13 +196,20 @@ Entrée :
    \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.
@@ -196,7 +218,7 @@ Ce processus nécessite deux cycles de lecture des données, le premier pour le
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \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 :
 
@@ -228,10 +250,11 @@ La \emph{ĺibrary} \emph{CryptoFile} est composée de trois fichiers :
    \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}.
 
@@ -259,44 +282,39 @@ module API =
 
 \subsection{Mesures de performance}
 
-Quelques mesures sur un fichier de 871 MiB. Sous \emph{Linux} avec \emph{Mono} 3.10.0. Des résultats similaires ont été obtenus sous \emph{Windows 8} avec \emph{Visual Studio 2012}.
+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}.
 
-Chiffrement :
+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{itemize}
-   \item Temps : 42 s.
-   \item Mémoire utilisée : 8.9 MiB.
-   \item Taux \emph{CPU} : un cœur à 100 \%
-\end{itemize}
-
-Déchiffrement :
-
-\begin{itemize}
-   \item Temps : 55 s.
-   \item Mémoire utilisée : 14.3 MiB.
-   \item Taux \emph{CPU} : un cœur à 100 \%
-\end{itemize}
+\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 & 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}
 
 
 \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}