\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{textcomp}
\usepackage{geometry}
\geometry{top=15mm, bottom=15mm, left=1cm, right=1cm}
\usepackage[french]{babel}
\usepackage{pslatex}
\usepackage[colorlinks=true,urlcolor=black]{hyperref}
\usepackage{graphicx}
\usepackage{fancyhdr}
\pagestyle{fancy}
\renewcommand{\footrulewidth}{0.4pt}
\fancyfoot[L]{Uubu.fr}
\fancyfoot[R]{mar. mars 22 10:43:19 CET 2016}
\lfoot{\Large \textit{Uubu.fr}}
\hypersetup{pdfinfo={
Title={module-signing},
Author={Sylvain Girod},
Creator={Bash script from uubu.fr's format version 1},
Producer={Bash script and PDFLaTeX},
Subject={Signature des modules kernel},
CreationDate={D:20160322104319},
ModDate={D:20160322104319},
Keywords={Linux;linux features;chiffrement;sécurité}
}}
\begin{document}
 
\begin{center}
{\Huge module-signing }
\end{center}
\vspace{1cm}
 
\begin{flushleft}
 
{\large Signature des modules kernel}
 
\vspace{10mm}
 
\vspace{1cm}{\huge Présentation }
 
\
 
\hspace{1mm}  La facilité de signature de module kernel signe cryptographiquement les modules durant l'installation et vérifie la signature au chargement des modules. Cela augmente la sécurité de kernel en interdisant le chargement des modules non-signés ou les modules signés avec une clé invalide. La signature de module augmente la sécurité en rendant le chargement de code malicieux plus dur dans le kernel. La vérification de la signature est fait par le kernel donc il n'est pas nécessaire d'avoir de clé de confiance dans l'espace utilisateur.
\vspace{5mm} \\
 
 
\hspace{1mm}  Cette facilité utilise les certificats X.509 pour encoder les clé publiques. Les signature ne sont pas encodées par un type standard. La facilité supporte actuellement seulement RSA. Les algorithmes de hashage qui peuvent être utilisée sont SHA-1, SHA-224, SHA-256, SHA-384, et SHA-512.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Configuration }
 
\
 
\hspace{1mm}  La facilité de signature de module est activée par la section "Enable Loadable Module Support" de la configuration du kernel et en activant CONFIG\_MODULE\_SIG. Il y a quelques options disponibles:
\vspace{5mm} \\
 
 
\begin{description} \normalsize
\item[\hspace{1mm} Require modules to be validly signed]{CONFIG\_MODULE\_SIG\_FORCE - spécifie le comportement du kernel lorsque la signature d'un module ne peut pas être vérifiée. off, autorise les module non-signés ou non valides, restrictive impose une signature valide.}
\item[\hspace{1mm} Automatically sign all modules]{CONFIG\_MODULE\_SIG\_ALL - Signe les modules automatiquement durant la phase modules\_install. À off, les modules doivent être signés manuellement avec scripts/sign-file}
\item[\hspace{1mm} Which hash algorithm should modules be signed with?]{Présente un choix d'algorithmes de hashage pour signer les modules}
\item[\hspace{1mm} File name or PKCS\#11 URI of module signing key]{CONFIG\_MODULE\_SIG\_KEY - Définir cette option à une valeur différente que le défaut "certs/signing\_key.pem" désactive l'autogénération des clés de signatures. Cette chaîne devrait identifier un fichier contenant une clé privée et son certificat correspondant au format PEM, ou - sur les système où OpenSSL ENGINE pkcs11 est fonctionnel}
\item[\hspace{1mm} Additional X.509 keys for default system keyring]{CONFIG\_SYSTEM\_TRUSTED\_KEYS - Définis un fichier PEM contenant des certificats additionnels qui seront inclus dans le système par défaut.}
\end{description}
 
\vspace{1cm}{\huge Générer les clés }
 
\
 
\hspace{1mm}  Une paire de clé cryptographique est requise pour générer et vérifier les signatures. Une clé privée est utilisée pour générer une signature et la clé publique correspondante est utilisée pour la vérifier. La clé privée est seulement nécessaire durant le build, et peut être supprimée ensuite. La clé publique est embarquée dans le kernel.
\vspace{5mm} \\
 
 
\hspace{1mm}  Dans des conditions normales, CONFIG\_MODULE\_SIG\_KEY est inchangé de son défaut, le build génère automatiquement une nouvelle clé en utilisant openssl s'il n'existe pas de fichier certs/signing\_key.pem. certs/x509.genkey est également généré et contient les paramètres openssl.
\vspace{5mm} \\
 
 
\hspace{1mm} Par défaut la section req\_distinguished\_name contient:
 
{\ttfamily
\texttt{[} req\_distinguished\_name \texttt{]}\\ \#O = Unspecified company\\ CN = Build time autogenerated kernel key\\ \#emailAddress = unspecified.user@unspecified.company\\
}
\vspace{8mm}
 
\hspace{1mm} La taille de clé est également définie avec:
 
{\ttfamily
\texttt{[} req \texttt{]}\\ default\_bits = 4096\\
}
\vspace{8mm}
 
\hspace{1mm} Il est également possible de générer manuellement les fichiers avec le fichier x509.genkey: \\
\hspace{1mm} \textbf{openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 -config x509.genkey -outform PEM -out kernel\_key.pem -keyout kernel\_key.pem} \\
 
\vspace{1cm}{\huge Clés publiques dans le kernel }
 
\
 
\hspace{1mm}  Le kernel contient un jeu de clé publiques qui peuvent être vues par root (cat /proc/keys).
\vspace{5mm} \\
 
 
\hspace{1mm}  Au delà la clé publique générée spécifiquement pour la signature de module, des certificats additionnels peuvent être fournis au format PEM référencés par l'option kernel CONFIG\_SYSTEM\_TRUSTED\_KEYS.
\vspace{5mm} \\
 
 
\hspace{1mm}  De plus, le code peut prendre des clés publiques depuis un stockage hardware et les ajouter (ex: depuis une base de clé UEFI)
\vspace{5mm} \\
 
 
\hspace{1mm} Finalement, il est possible d'ajouter des clé publiques en faisant: \\
\hspace{1mm} \textbf{keyctl padd asymmetric "" [.system\_keyring-ID] <[key-file]>} \\
 
\hspace{1mm}  Noter cependant que le kernel ne permet que d'ajouter des clés dans .system\_keyring s'ils sont signés par une clé déjà présente dans le .system\_keyring au moment où elle est ajoutée.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Signer des modules manuellement }
 
\
 
\hspace{1mm}  Pour signer manuellement un module, utiliser le script sign-file. Ce script nécessite 4 arguments: l'algorithme de hashage, le nom de la clé privée ou une URI PKCS\#11, la clé publique et le module à signer.
\vspace{5mm} \\
 
 
\hspace{1mm} exemple: \\
\hspace{1mm} \textbf{scripts/sign-file sha512 kernel-signkey.priv kernel-signkey.x509 module.ko} \\
 
\hspace{1mm}  L'algorithme de hashage utilisé ne doit pas correspondre à celui configuré, mais l'algorithme utilisé doit être compilé dans le kernel ou un module chargeable. Si la clé privée nécessite une passphrase ou PIN, il peut être fournis dans la variable d'environnement \$KBUILD\_SIGN\_PIN
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Modules signés et stripping }
 
\
 
\hspace{1mm}  Un module signé a une signature numérique simplement ajouté à la fin. La chaîne '\textasciitilde Module signature appended\textasciitilde .' à la fin diu fichier du module confirme qu'une signature est présente mais ne confirme pas que la signature est valide.
\vspace{5mm} \\
 
 
\hspace{1mm}  Les modules signés sont embarqué comme signature hors du conteneur ELF. Donc, ils ne peuvent plus être stripped une fois la signature calculée. Noter que tout le module est le payload signé, incluant les informations de debug présents au moment de la signature.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Charger des modules signés }
 
\
 
\hspace{1mm}  Les modules sont chargés avec insmod, modprobe, init\_module() ou finit\_module(), exactement comme pour les modules non-signés et aucun traitement n'est fait dans l'espace utilisateur. La vérification de la signature est entièrement faite dans le kernel
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Signatures non-valides et modules non-signé }
 
\
 
\hspace{1mm}  Si CONFIG\_MODULE\_SIG\_FORCE est activé ou enforcemodulesig=1 est fournis au kernel, le kernel va seulement charger les modules signés et valides pour lequel il possède une clé publique. Un module pour lequel le kernel a une clé, mais qui prouve qu'une signature ne correspond pas ne sera pas chargé. Tout module dont la signature n'est pas lisible sera rejeté.
\vspace{5mm} \\
 
 
\vspace{1cm}{\huge Administrer/protéger la clé privée }
 
\
 
\hspace{1mm}  Vu que la clé privée est utilisée pour signer les modules, les virus et malware peuvent l'utiliser pour signer des modules et compromettre l'OS. La clé privée doit être soit détruite, soit placée dans une emplacement sûre et non possédé dans le nœud root du kernel.
\vspace{5mm} \\
 
\end{flushleft}
\end{document}
