X-Git-Url: http://git.euphorik.ch/?a=blobdiff_plain;f=rapport%2Fmain.tex;h=36571ff3cafc13293789e96c1506e56dd84b311e;hb=f88f22ebc8d780fbd86358bf95dffcfb3803f509;hp=bf0f64f4c335046215887566ba5555b3cda5ca79;hpb=2fcf3ed38874e9aa6d2ccd6b9917bd3113d76aee;p=crypto_lab2.git diff --git a/rapport/main.tex b/rapport/main.tex index bf0f64f..36571ff 100644 --- a/rapport/main.tex +++ b/rapport/main.tex @@ -16,6 +16,7 @@ \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{\rsasecurity}\url{http://en.wikipedia.org/wiki/RSA_Security} \title{ICR - Labo \#2 : \textit{Conception et implémentation d'un container sécurisé pour des données médicales}} \author{G.Burri} @@ -98,7 +99,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} @@ -110,9 +111,13 @@ Ces clefs sont générées aléatoirement à chaque création d'un container. \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{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 d'une attaque. + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Format du container} @@ -131,7 +136,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 = 640\,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. @@ -157,11 +162,11 @@ Entrées : 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 Chiffrement du $plaintext$ avec \emph{AES-CBC128}, $k_c$ et $iv \rightarrow ciphertext$. \item Calcul de MAC 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$. @@ -196,7 +201,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\#}. L'ensemble des éléments cryptographiques requis sont fournis par \emph{.NET} \footnote{\dotnetcrypto}. Deux \emph{assemblies} sont créées : @@ -259,23 +264,19 @@ 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}. - -Chiffrement : - -\begin{itemize} - \item Temps : 42 s. - \item Mémoire utilisée : 8.9 MiB. - \item Taux \emph{CPU} : un cœur à 100 \% -\end{itemize} +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}. -Déchiffrement : +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}. -\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 & 21 s & 55 s & 22 s \\ + Mémoire utilisée & 7.0 MiB & 14 MiB & 14.3 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}