rapport/main.tex

   1 \documentclass[a4paper,10pt]{article}
   2
   3 \usepackage[francais]{babel}
   4 \usepackage[utf8]{inputenc}
   5 \usepackage[T1]{fontenc}
   6 \usepackage{lmodern}
   7
   8 \usepackage{graphicx}
   9 \usepackage{listings}
  10 \usepackage{url}
  11 \usepackage{upquote}
  12 \usepackage{color}
  13 \usepackage[usenames,dvipsnames]{xcolor}
  14
  15 %%% URLs %%%
  16 \urldef{\dotnetcrypto}\url{http://msdn.microsoft.com/en-us/library/System.Security.Cryptography%28v=vs.110%29.aspx}
  17 \urldef{\monodevelop}\url{http://www.monodevelop.com/}
  18 \urldef{\rsacryptoserviceprovider}\url{http://msdn.microsoft.com/en-us/library/system.security.cryptography.rsacryptoserviceprovider%28v=vs.110%29.aspx}
  19 \urldef{\rngcryptoserviceprovider}\url{http://msdn.microsoft.com/en-us/library/system.security.cryptography.rngcryptoserviceprovider%28v=vs.110%29.aspx}
  20 \urldef{\rsasecurity}\url{http://en.wikipedia.org/wiki/RSA_Security}
  21 \urldef{\wikiml}\url{http://en.wikipedia.org/wiki/ML_%28programming_language%29}
  22
  23 \title{ICR - Labo \#2 : \textit{Conception et implémentation d'un container sécurisé pour des données médicales}}
  24 \author{G.Burri}
  25
  26 \lstdefinelanguage{FSharp}%
  27 {morekeywords={let, new, match, with, rec, open, module, namespace, type, of, member, %
  28 and, for, while, true, false, in, do, begin, end, fun, function, return, yield, try, %
  29 mutable, if, then, else, cloud, async, static, use, abstract, interface, inherit, finally },
  30   otherkeywords={ let!, return!, do!, yield!, use!, var, from, select, where, order, by },
  31   keywordstyle=\color{blue}\bfseries,
  32   sensitive=true,
  33   basicstyle=\ttfamily,
  34         breaklines=true,
  35   xleftmargin=\parindent,
  36   aboveskip=\bigskipamount,
  37         tabsize=4,
  38   morecomment=[l][\color{OliveGreen}]{///},
  39   morecomment=[l][\color{OliveGreen}]{//},
  40   morecomment=[s][\color{OliveGreen}]{{(*}{*)}},
  41   morestring=[b]",
  42   showstringspaces=false,
  43   literate={`}{\`}1,
  44   stringstyle=\color{red},
  45 }
  46
  47 \begin{document}
  48
  49 \nocite{*}
  50
  51 \maketitle
  52
  53
  54 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  55 \section{Introduction}
  56
  57 Le but de ce laboratoire est de définir les algorithmes cryptographiques et leurs paramètres afin de sécuriser des données médicales. Une donnée médicale est représentée par un fichier qui devra être sécurisé au sein d'un container dont le format sera défini par nos soins. Une implémentation sera ensuite proposée.
  58
  59
  60 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  61 \section{Niveaux de sécurité}
  62
  63 \subsection{Quel est le niveau de sécurité que l'on souhaite atteindre ?}
  64
  65 \begin{itemize}
  66    \item Confidentialité : les données chiffrées ne doivent pas pouvoir être décryptées par un attaquant.
  67    \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.
  68    \item Intégrité : il ne faut pas que les données chiffrées aient pu être altérées par un attaquant.
  69 \end{itemize}
  70
  71
  72 \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 ?}
  73
  74 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}.
  75
  76
  77 \subsection{Comment s'assure-t-on que les données stockées sont authentiques ? Quels sont les risques à prendre en compte ?}
  78
  79 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.
  80
  81
  82 \subsection{Comment s'assure-t-on que les données stockées sont intègres ?}
  83
  84 Cela est réalisé avec un \emph{MAC}, dans notre cas nous utilisons \emph{HMAC-SHA256} sur l'ensemble des données chiffrées (\emph{Encrypt-then-MAC}).
  85
  86
  87 \subsection{Quels sont les clefs cryptographiques requises qu'il est nécessaire de gérer ?}
  88
  89 \subsubsection{Clefs externes}
  90
  91 Concerne les clefs externes à l'\emph{API}.
  92
  93 \begin{itemize}
  94    \item Une paire de clefs \emph{RSA-2048} pour la signature.
  95    \item Une paire de clefs \emph{RSA-2048} pour le chiffrement des clefs \emph{AES}.
  96 \end{itemize}
  97
  98
  99 \subsubsection{Clefs internes}
 100
 101 Concerne les clefs gérées à l'intérieur du container.
 102
 103 \begin{itemize}
 104    \item Une clef de 128 bits pour \emph{AES}.
 105    \item Une clef de 256 bits pour \emph{HMAC}.
 106 \end{itemize}
 107
 108 Ces clefs sont générées aléatoirement à chaque création d'un container.
 109
 110
 111 \section{Choix des algorithmes et des paramètres}
 112
 113 \begin{itemize}
 114    \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é ;
 115    \item \emph{HMAC-SHA256} pour la vérification de l'intégrité ;
 116    \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é.
 117 \end{itemize}
 118
 119 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.
 120
 121 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.
 122
 123
 124 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 125 \section{Format du container}
 126 \label{sec:format_container}
 127
 128 Le format est défini comme suit en \emph{EBNF}. Les valeurs entre crochets correspondent soit à une taille en bits soit à un type.
 129
 130 \begin{lstlisting}[frame=single, breaklines, basicstyle=\ttfamily\footnotesize]
 131 container = header, ciphertext ;
 132 header = mac[256], signature[2048], keys[2048] ;
 133 ciphertext = AES(plaintext) ;
 134 plaintext = meta-data, file-content ;
 135 meta-data = nb-meta-data[byte], { key-value-pair } ;
 136 key-value-pair = key[string], value[string] ;
 137 string = size[vint], content-utf8 ;
 138 \end{lstlisting}
 139
 140 \texttt{nb-meta-data} est le nombre de paires clef-valeur des méta-données.
 141
 142 \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$.
 143
 144 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.
 145
 146 Le type \texttt{vint} correspond à un entier de taille variable, initialement occupant un octet.
 147
 148 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.
 149
 150
 151 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 152 \section{Processus}
 153
 154 \subsection{Chiffrement}
 155
 156 Entrées :
 157
 158 \begin{itemize}
 159    \item $f$ : fichier
 160    \item $k_{pub}$ : clef publique RSA
 161    \item $k_{signpriv}$ : clef privée de signature RSA
 162 \end{itemize}
 163
 164
 165 Sortie :
 166
 167 \begin{itemize}
 168    \item $c$ : container chiffré.
 169 \end{itemize}
 170
 171
 172 Processus :
 173
 174 \begin{enumerate}
 175    \item Génération d'une clef 128 bits pour \emph{AES} $\rightarrow  k_c$.
 176    \item Génération d'une clef 256 bits pour \emph{MAC} $\rightarrow k_a$.
 177    \item Génération d'un \emph{IV} 128 bits pour le mode \emph{CBC} $\rightarrow iv$.
 178    \item Construction du $plaintext$ à partir de $f$, voir format décrit à la section~\ref{sec:format_container}.
 179    \item Chiffrement du $plaintext$ avec \emph{AES-CBC128}, $k_c$ et $iv \rightarrow ciphertext$.
 180    \item Calcul du \emph{HMAC-SHA256} de $ciphertext$ $\rightarrow mac$.
 181    \item Signature de $mac$ avec $k_{signpriv}$ $\rightarrow sig$.
 182    \item Chiffrement de $k_c + k_a + iv$ avec $k_{pub} \rightarrow keys$.
 183    \item $mac + sig + keys + ciphertext \rightarrow c$.
 184 \end{enumerate}
 185
 186 Où $+$ dénote la concaténation.
 187
 188
 189 \subsection{Déchiffrement}
 190
 191 Entrée :
 192
 193 \begin{itemize}
 194    \item $c$ : container chiffrés
 195    \item $k_{priv}$ : clef privée RSA
 196    \item $k_{signpub}$ : la clef publique de signature RSA
 197 \end{itemize}
 198
 199 Sortie :
 200
 201 \begin{itemize}
 202    \item $f$ : fichier original
 203 \end{itemize}
 204
 205
 206 Processus :
 207
 208 \begin{enumerate}
 209    \item Lecture de $mac$, calcul de $mac'$ sur $c$, comparaison des deux valeurs afin de vérifier l'intégrité.
 210    \item Vérification de la signature avec $k_{signpub}$.
 211    \item Déchiffrement de $k_c + k_a + iv$ avec $k_{priv}$.
 212    \item Déchiffrement du reste des données ($ciphertext$) $\rightarrow f$.
 213 \end{enumerate}
 214
 215 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.
 216
 217
 218 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 219 \section{Implémentation}
 220
 221 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}.
 222
 223 Deux \emph{assemblies} sont créées :
 224
 225 \begin{itemize}
 226    \item \emph{CryptoFile} : \emph{Library} mettant à disposition l'\emph{API} de chiffrement de fichier et de déchiffrement de container.
 227    \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.
 228 \end{itemize}
 229
 230 \subsection{Utilisation}
 231
 232 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.
 233
 234 À partir du dossier \texttt{labo2-fsharp} et après avoir compiler en \emph{release} la solution, voici ce qu'il est possible d'effectuer :
 235
 236 \begin{itemize}
 237    \item \texttt{CryptoFileTests/bin/Release/CryptoFileTests.exe tests} : Réalise une série de tests.
 238    \item \texttt{CryptoFileTests/bin/Release/CryptoFileTests.exe encrypt <file> <container>} : Chiffre le fichier \texttt{<file>} vers le container \texttt{<container>}.
 239    \item \texttt{CryptoFileTests/bin/Release/CryptoFileTests.exe decrypt <container> <output directory>} : Déchiffre le container \texttt{<container>} dans le dossier \texttt{<output directory>}.
 240 \end{itemize}
 241
 242 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.
 243
 244
 245 \subsection{Organisation du code}
 246
 247 La \emph{ĺibrary} \emph{CryptoFile} est composée de trois fichiers :
 248
 249 \begin{itemize}
 250    \item \emph{Types.fs} : Quelques types publics.
 251    \item \emph{Crypto.fs} : Toutes les primitives cryptographiques nécessaires.
 252    \item \emph{UnitTests.fs} : Quelques tests unitaires du module \emph{Crypto}.
 253    \item \emph{API.fs} : L'interface publique de la \emph{library}. Elle est détaillée à la section~\ref{sec:api}.
 254 \end{itemize}
 255
 256 \subsubsection{API}
 257 \label{sec:api}
 258
 259 Voici la partie publique de la \emph{library} \emph{CryptoFile}.
 260
 261 \begin{minipage}{\linewidth} % Pour éviter que le listing soit séparé sur deux pages.
 262 \begin{lstlisting}[language=FSharp, frame=single, basicstyle=\ttfamily\footnotesize]
 263 module API =
 264     (* Generates a pair of keys (public * private)
 265        to be used in the following two functions.
 266        You have the reponsability of keeping
 267        the private part secret. *)
 268     let generatKeysPair : Key * Key
 269
 270     let encryptFile (inputFilePath : string)
 271                     (outputFilePath : string)
 272                     (signaturePrivKey: Key)
 273                     (cryptPubKey : Key)
 274
 275     let decryptFile (sourceFilePath : string)
 276                     (targetDirPath : string)
 277                     (signaturePubKey: Key)
 278                     (decryptPrivKey : Key)
 279 \end{lstlisting}
 280 \end{minipage}
 281
 282
 283 \subsection{Mesures de performance}
 284
 285 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}.
 286
 287 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}.
 288
 289 \begin{tabular}{ l | r | r | r | r }
 290   & \multicolumn{2}{c|}{Chiffrement} & \multicolumn{2}{|c}{Déchiffrement} \\
 291   \cline{2-5}
 292   & \multicolumn{1}{c}{\emph{Mono}} & \multicolumn{1}{|c|}{\emph{MS .NET}} & \multicolumn{1}{|c|}{\emph{Mono}} & \multicolumn{1}{c}{\emph{MS .NET}} \\
 293   \cline{2-5}
 294   Temps & 39 s & 20 s & 48 s & 20 s \\
 295   Mémoire utilisée & 7.0 MiB & 14 MiB & 15.2 MiB & 13.9 MiB \\
 296   Taux \emph{CPU} & 1 x 100 \% & 1 x 100 \% & 1 x 100 \% & 1 x 100 \% \\
 297 \end{tabular}
 298
 299
 300 \section{Analyse de la sécurité de l'implémentation}
 301
 302 \subsection{Quelles sont les parties critiques du code et comment s'assure-t-on que ces parties soient correctement implémentées ?}
 303
 304 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}}.
 305
 306 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}.
 307
 308
 309 \subsection{Quels sont les points faibles restants et quelles sont les possibilités de les corriger ?}
 310
 311 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é.
 312
 313
 314 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 315 \section{Conclusion}
 316
 317 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.
 318
 319
 320 \bibliographystyle{plain}
 321 \bibliography{main}
 322
 323 \end{document}