+\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é.
+\end{itemize}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Format du 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] ;
+ciphertext = AES(plaintext) ;
+plaintext = meta-data, file-content ;
+meta-data = nb-meta-data[byte], { key-value-pair } ;
+key-value-pair = key[string], value[string] ;
+string = size[vint], content-utf8 ;
+\end{lstlisting}
+
+\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$.
+
+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.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\section{Processus}
+
+\subsection{Chiffrement}
+
+Entrées :
+
+\begin{itemize}
+ \item $f$ : fichier
+ \item $k_{pub}$ : clef publique RSA
+ \item $k_{signpriv}$ : clef privée de signature RSA
+\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 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 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$.
+\end{enumerate}
+
+Où $+$ dénote la concaténation.
+
+
+\subsection{Déchiffrement}
+
+Entrée :
+
+\begin{itemize}
+ \item $c$ : container chiffrés
+ \item $k_{priv}$ : clef privée RSA
+ \item $k_{signpub}$ : la clef publique de signature RSA
+\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 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$).
+\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}.
+
+Deux \emph{assemblies} sont créées :
+
+\begin{itemize}
+ \item \emph{CryptoFile} : \emph{Library} mettant à disposition l'\emph{API} de chiffrement de fichier et de déchiffrement de container.
+ \item \emph{CryptoFileTests} : Exécutable utilisant la \emph{library} \emph{CryptoFile} et permettant d'utiliser l'\emph{API} à l'aide d'arguments fournis par la ligne de commande.
+\end{itemize}
+
+\subsection{Utilisation}
+
+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 :
+
+\begin{itemize}
+ \item \texttt{CryptoFileTests/bin/Release/CryptoFileTests.exe tests} : Réalise une série de tests.
+ \item \texttt{CryptoFileTests/bin/Release/CryptoFileTests.exe encrypt <file> <container>} : Chiffre le fichier \texttt{<file>} vers le container \texttt{<container>}.
+ \item \texttt{CryptoFileTests/bin/Release/CryptoFileTests.exe decrypt <container> <output directory>} : Déchiffre le container \texttt{<container>} dans le dossier \texttt{<output directory>}.
+\end{itemize}
+
+Les clefs publiques et privées pour le chiffrement ainsi que pour la réalisation de la signature se trouvent dans les fichiers \texttt{keys-crypt.priv}, \texttt{keys-crypt.pub}, \texttt{keys-sign.priv} et \texttt{keys-sign.pub}. Ceux-ci sont automatiquement générés dans le cas où ils sont introuvables.
+
+
+\subsection{Organisation du code}
+
+La \emph{ĺibrary} \emph{CryptoFile} est composée de trois fichiers :
+
+\begin{itemize}
+ \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.
+\end{itemize}
+
+\subsubsection{API}
+
+Voici la partie publique de la \emph{library} \emph{CryptoFile}.
+
+\begin{minipage}{\linewidth} % Pour éviter que le listing soit séparé sur deux pages.
+\begin{lstlisting}[language=FSharp, frame=single, basicstyle=\ttfamily\footnotesize]
+module API =
+ (* Generates a pair of keys (public * private)
+ to be used in the following two functions.
+ You have the reponsability of keeping
+ the private part secret. *)
+ let generatKeysPair : Key * Key
+
+ let encryptFile (inputFilePath : string)
+ (outputFilePath : string)
+ (signaturePrivKey: Key)
+ (cryptPubKey : Key)
+
+ let decryptFile (sourceFilePath : string)
+ (targetDirPath : string)
+ (signaturePubKey: Key)
+ (decryptPrivKey : Key)
+\end{lstlisting}
+\end{minipage}
+
+
+\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}.
+
+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{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 & 42 s & 21 s & 55 s & 22 s \\
+ Mémoire utilisée & 8.9 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}
+
+\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}.
+
+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.
+
+
+\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é.