X-Git-Url: http://git.euphorik.ch/?p=crypto_lab2.git;a=blobdiff_plain;f=rapport%2Fmain.tex;fp=rapport%2Fmain.tex;h=773437102be5e82f6263d28669ea7bc94ad935c7;hp=b7bb2dd5500655dca405d0141d423112e171619c;hb=95f772ef77baee15929c1feccc4de4c9a795f81d;hpb=0126bf5a082b8e37ad1dc5f7686802146269ae97 diff --git a/rapport/main.tex b/rapport/main.tex index b7bb2dd..7734371 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{\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} @@ -70,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 ?} @@ -115,13 +116,14 @@ Ces clefs sont générées aléatoirement à chaque création d'un container. \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 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. +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. @@ -160,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 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 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 $mac + sig + keys + ciphertext \rightarrow c$. \end{enumerate} Où $+$ dénote la concaténation. @@ -187,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. @@ -234,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}. @@ -265,7 +282,7 @@ module API = \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}. Cet ensemble d'instructions est normalement supporté par l’implémentation du \emph{runtime} \emph{.NET} de \emph{Microsoft}. @@ -284,14 +301,14 @@ Les tests sous \emph{Windows 8} ont été fait sur une machine ne possédant pas \subsection{Quelles sont les parties critiques du code et comment s'assure-t-on que ces parties soient correctement implémentées ?} -Le choix des algorithmes, de leurs paramètres et de leur implémentations est une partie critique. +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{RSACryptoServiceProvider}\footnote{\rsacryptoserviceprovider}. +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é. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%