X-Git-Url: http://git.euphorik.ch/?p=crypto_lab1.git;a=blobdiff_plain;f=rapport%2Fmain.tex;fp=rapport%2Fmain.tex;h=2bfd029c1ad415dd655155ae5b26b14eccc1539d;hp=16b8e6c7dfb8f5b2ae13f2d8d91b3829b5a53574;hb=c484911fa250681026144ddb9e521daa2c2b4351;hpb=d3d8743586e533af4f32c1edfcff6377161d7cf4 diff --git a/rapport/main.tex b/rapport/main.tex index 16b8e6c..2bfd029 100644 --- a/rapport/main.tex +++ b/rapport/main.tex @@ -31,10 +31,38 @@ Nous utiliseront \emph{AES-256} en mode \emph{CBC} pour chiffrer les données ai %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Simulation du protocole} -\subsection{Utilisation du code} +\subsection{Utilisation du programme} + +Le code est écrit en langage Rust \footnote{\url{http://www.rust-lang.org}} et utilise le système de build \emph{Cargo} qui est livré en standard. Il est conseillé d'installer la version \emph{nightly} disponible ici : \url{http://www.rust-lang.org/install.html}. + +Pour construire et lancer l'application il faut se trouver dans le dossier contenant le fichier \emph{Cargo.toml} et lancer la commande suivante. + +\begin{lstlisting} +$> cargo run -- +\end{lstlisting} + +Où \emph{} peut valoir : + +\begin{itemize} + \item \emph{genkey} : génère une clef de 256 bits. Utilisé initialement pour définir la clef d'authentification $K_{a}$ et la clef de chiffrement $K_{c}$ ; + \item \emph{tests} : effectue un certain nombre de tests pour vérifier le comportement du serveur vis-à-vis du protocole ; + \item \emph{oracle-weak} : effectue une attaque sur la première version du serveur ; + \item \emph{oracle-fixed} : effectue une attaque sur la version corrigé du serveur. +\end{itemize} + \subsection{Structure du code} +Le code est structuré en quatre modules : + +\begin{itemize} + \item \emph{crypto} : fournit les primitives de chiffrement, déchiffrement, calcul du MAC. Utilise un binding \emph{Rust} vers \emph{OpenSSL} ; + \item \emph{packet} : définit le format des paquets et permet leur sérialisation et dé-sérialisation ; + \item \emph{end\_point} : permet la création de serveurs et de clients et gère la communication sur \emph{TCP/IP} ; + \item \emph{oracle\_machine} : implémente l'attaque par padding-oracle. +\end{itemize} + + \subsection{Quelle est la stratégie recommandée en pratique parmi les trois listées ci après ?} \begin{itemize} @@ -43,6 +71,9 @@ Nous utiliseront \emph{AES-256} en mode \emph{CBC} pour chiffrer les données ai \item \emph{Encrypt-then-MAC} : $Enc(M)|MAC(Enc(M))$. \end{itemize} +D'après \cite{wiki-authentication-encryption} la stratégie \emph{Encrypt-then-MAC} est la plus sûre dans le cadre de chiffrage authentifié. L'article de \emph{M. Bellare and C. Namprempre} \cite{authenticated-encryption-bellare-namprempre} évalue ces trois stratégies. + + \subsubsection{Quelle stratégie est utilisée par \emph{TLS} ?} \emph{TSL} utilise la deuxième version (\emph{MAC-then-Encrypt}). À noté que le \emph{MAC} est optionnel. @@ -73,7 +104,7 @@ TODO \subsection{Remarques concernant la sécurité de notre protocole} -TODO +A priori nous n'avons pas choisi la stratégie la plus recommandée en terme de sécurité. Comme nous le verrons par la suite, ce protocole est vulnérable à une attaque de type \emph{padding-oracle}. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -81,8 +112,11 @@ TODO \subsection{Historique de l'attaque par oracle à l'aide du remplissage} -TODO +L'attaque original a été publié en 2002 par \emph{Serge Vaudenay}. En 2010, cette attaque a été mise en pratique contre plusieurs frameworks web tel que \emph{JavaServer Faces}, \emph{Ruby on Rails} et \emph{ASP.NET}. En 2012, il a été montré qu'elle est efficace contre certain appareils hardware. + +Il existe une nouvelle variante, publiée en 2013, nommée \emph{the Lucky Thirteen attack}, permettant d'attaquer des implémentations ayant été corrigées. En février 2013, les personnes en charge des implémentations de \emph{TLS} travaillaient à la réalisation d'un correctif à cette attaque. +Cette section est largement inspirée de l'article de \emph{Wikipedia} sur la \emph{padding-oracle attack} \cite{wiki-padding-oracle-attack}. \subsection{Explication de l'attaque pour notre cas} @@ -108,12 +142,18 @@ Dès qu'un paquet d'erreur \emph{AuthError} est reçu alors nous pouvons calcule Une subtilité existe pour la recherche du premier octet, il est possible que le paquet d'erreur \emph{AuthError} correspond, avec une faible probabilité, à un autre bourrage que \emph{[0x01]}. Pour prévenir ce cas il faut, pour ce premier octet, envoyer un paquet de commande pour toutes les valeurs de $F_{1}$ et compter le nombre de paquet d'erreur \emph{AuthError} reçu. Si ce nombre est égal à 1 alors on peut passer à $b'$, sinon il faut recommencer en modifiant $F_{2} = (F_{2} + 1) mod 256$. +Le code correspondant à cette attaque peut être exécuté par la commande suivante : + +\begin{lstlisting} +$> cargo run --release -- oracle-weak +\end{lstlisting} + \subsection{Calcul de la complexité moyenne de l'attaque en terme de nombre de requête effectué auprès de l'oracle} Sans prendre en compte la particularité du premier octet illustré à la section précédente, la complexité moyenne pour le décryptage d'un bloc de 16 octets est de $16 * 256 / 2 = 2048$ requêtes. -Dans le cas présenté dans le code, le nombre de requête est de 1795. +Dans l'exemple présenté dans le code, le nombre de requête est de 2099. La durée d'exécution est de ~0.180 ms, ça relative longueur est certainement dû à l'overhead des couches \emph{TCP/IP}. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @@ -121,14 +161,24 @@ Dans le cas présenté dans le code, le nombre de requête est de 1795. \subsection{Description} +Le correctif proposé consiste à authentifier également le bourrage et non-plus que les données. Cela a pour conséquence de vérifier en premier l'authenticité du contenu avant de procéder à la validité du padding. Les deux messages d'erreur, \emph{CryptError} et \emph{AuthError}, font toujours partis du protocole. + +Le code correspondant à ce correctif peut être exécuté par la commande suivante : + +\begin{lstlisting} +$> cargo run --release -- oracle-fixed +\end{lstlisting} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Conclusion} +TODO + + + + -%http://crypto.stackexchange.com/a/205 -%https://en.wikipedia.org/wiki/Malleability_%28cryptography%29 \bibliographystyle{plain} \bibliography{main}