keyrings

NOM

keyrings – Gestion interne au noyau de clés et mémorisation

DESCRIPTION

La fonction de gestion de clés de Linux est principalement un moyen pour divers composants du noyau de mémoriser ou de mettre en cache des données de sécurité, des clés d’authentification, des clés de chiffrement et d’autres données dans le noyau. Les interfaces d’appel système sont fournies de façon à ce que les programmes en espace utilisateur puissent gérer ces objets, et aussi en utiliser la fonctionnalité pour leurs propres besoins. Consultez add_key(2), request_key(2) et keyctl(2). Une bibliothèque et quelques utilitaires en espace utilisateur sont fournis pour autoriser l’accès à cette fonctionnalité. Consultez keyctl(1), keyctl(3) et keyutils(7) pour davantage d’informations.

Clés

Une clé possède les attributs suivants :

Numéro de série (ID)

IL s’agit d’un entier unique par lequel une clé est référencée dans des appels système. Le numéro de série est parfois appelé de manière synonyme l’identifiant de clé. En programmation, les numéros de série sont représentés en utilisant le type key_serial_t.

Type

Le type de clé précise quelle sorte de données sera gérée par la clé, de quelle manière le contenu présenté par la clé sera analysé et comment la charge utile sera utilisée.

Un certain nombre de types génériques sont disponibles en plus de types spécialisés définis par des composants particuliers du noyau.

Description (nom)

La description de la clé est une chaîne affichable qui est utilisée comme terme de recherche de la clé (conjointement avec le type de la clé) ainsi que comme nom à afficher. Lors des recherches, la description peut correspondre partiellement ou totalement.

Charge utile (données)

La charge utile est le contenu réel de la clé. Elle est habituellement définie au moment de la création de la clé, mais il est possible qu’un appel montant (upcall) du noyau dans l’espace utilisateur finisse l’instanciation de la clé si celle-ci n’était pas connue du noyau quand elle a été demandée. Pour plus de détails, consultez request_key(2).

Une charge utile de clé peut être lue et mise à jour si le type de clé le gère et si les permissions adéquates sont données à l’appelant.

Droits d’accès

Much as files do, each key has an owning user ID, an owning group ID, and a security label. Each key also has a set of permissions, though there are more than for a normal UNIX file, and there is an additional category—possessor—beyond the usual user, group, and other (see Possession, below).

Il est à remarquer que les clés sont sujettes à un quota puisqu’elles nécessitent de la mémoire du noyau non « swappable ». L’ID de l’utilisateur propriétaire indique quel quota doit être débité.

Heure d’expiration

Chaque clé peut avoir une heure d’expiration définie. Quand ce moment est atteint, la clé est marquée comme périmée et une demande d’accès à celle-ci échouera avec l’erreur EKEYEXPIRED. Si elle n’est pas supprimée, mise à jour ou remplacée, alors après un certain temps, la clé ayant expirée est automatiquement supprimée (collectée par le ramasse-miettes) avec tous les liens vers elle, et toute tentative d'accès à cette clé échouera avec l’erreur ENOKEY.

Comptage de références

Chaque clé possède un comptage de références. Les clés sont référencées par des trousseaux de clés, par les utilisateurs actuellement actifs, et par les identifiants d'un processus. Quand le comptage de références atteint zéro, la clé est programmée pour le ramasse-miettes.

Types de clé

Le noyau fournit plusieurs types basiques de clé :

"keyring"

Les trousseaux de clés sont des clés spéciales qui stockent un ensemble de liens vers d’autres clés (incluant d’autres trousseaux de clés), de manière analogue à un répertoire contenant des liens vers des fichiers. L’objectif principal d’un trousseau de clés est d’empêcher d’autres clés d’être collectées par le ramasse-miettes parce qu’elles ne servent de références à rien.

Keyrings with descriptions (names) that begin with a period ('.') are reserved to the implementation.

"user"

Il s’agit d’un type de clé générique. La clé est entièrement conservée dans la mémoire du noyau. La charge utile peut être lue et mise à jour par des applications de l’espace utilisateur.

La charge utile des clés de ce type est un objet binaire (blob) de données arbitraires pouvant contenir 32 767 octets.

La description peut être n’importe quelle chaîne autorisée, bien qu’il soit préférable qu’elle commence par un préfixe délimité par un deux-points représentant le service auquel la clé est destinée (par exemple, «  afs:mykey »).

"logon" (depuis Linux 3.3)

Ce type de clé est fondamentalement identique à «  user », mais ne permet pas la lecture (c’est-à-dire l’opération KEYCTL_READ de keyctl(2)), signifiant que la charge utile n’est jamais visible à partir de l’espace utilisateur. Cela est adapté au stockage de paires nom d’utilisateur/mot de passe qui ne doivent pas être lisibles à partir de l’espace utilisateur.

La description de la clé « logon » doit débuter par un préfixe non vide délimité par un deux-points dont le but est d’identifier le service auquel la clé appartient. Il est à remarquer que cela diffère du type de clé «  user » où l’incorporation du préfixe est recommandée mais pas obligée.

"big_key" (depuis Linux 3.13)

Ce type de clé est semblable au type «  user » de clé, mais il peut contenir une charge utile de taille 1 MiB. Ce type de clé est utile pour, par exemple, contenir des caches de ticket Kerberos.

Les données de la charge utile peuvent être stockées dans un système de fichiers tmpfs, plutôt que dans la mémoire du noyau si la taille des données excède la surcharge due au stockage des données dans le système de fichiers. Stocker les données dans un système de fichiers nécessite que des structures de système de fichiers soient allouées dans le noyau. La taille de ces structures détermine le seuil au-dessus duquel la méthode tmpfs de stockage est utilisée. Depuis Linux 4.8, les données de la charge utile sont chiffrées lorsqu’elles sont stockées en tmpfs, empêchant par conséquentqu’elles soient écrites dans l’espace d’échange sans être chiffrées.

Il existe aussi d’autres types de clé spécialisés, mais ils ne sont pas évoqués ici, car ils ne sont pas destinés à une utilisation normale en espace utilisateur. Key type names that begin with a period ('.') are reserved to the implementation.

Trousseaux de clés

Comme indiqué précédemment, les trousseaux de clés sont un type spécial de clé qui contient des liens vers d’autres clés (pouvant inclure d’autres trousseaux de clés). Les clés peuvent être liées à plusieurs trousseaux de clés. Les trousseaux de clés peuvent être considérés comme analogues à des répertoires UNIX où chaque répertoire contient un ensemble de liens physiques vers des fichiers. Différentes opérations (appels système) ne peuvent être appliquées qu’aux trousseaux de clés :

Ajout

Une clé peut être ajoutée dans un trousseau de clés par les appels système ayant créé les clés. Cela évite que la nouvelle clé soit détruite immédiatement quand l'appel système libère la dernière référence à la clé.

Liaison

Un lien peut être ajouté à un trousseau de clés pointant vers une clé déjà connue, si cela ne crée pas de cycle d’auto-référencement.

Déliaison

Un lien peut être supprimé d’un trousseau de clés. Quand le dernier lien vers une clé est supprimé, cette clé sera programmée pour être collectée par le ramasse-miettes.

Effacement

Tous les liens peuvent être supprimés d’un trousseau de clés.

Recherche

Un trousseau de clés peut être considéré comme la racine d’un arbre ou d’un sous-arbre dans lesquels les trousseaux de clés forment les branches et le reste les feuilles. Cet arbre peut être parcouru pour rechercher une clé d’une description ou d’un type particulier.

Consultez keyctl_clear(3), keyctl_link(3), keyctl_search(3) et keyctl_unlink(3) pour davantage d’informations.

Clés d’ancrage

Pour empêcher une clé d’être collectée par le ramasse-miettes, elle doit être ancrée pour conserver son comptage de références en cours lorsqu’elle n’est pas utilisée activement par le noyau. Les trousseaux de clés sont utilisés pour ancrer d’autres clés. Chaque lien est une référence à une clé. Il est à remarquer que les trousseaux de clés sont eux-mêmes des clés et sont aussi sujets à la même nécessité d’ancrage pour empêcher qu’ils soient collectés par le ramasse-miettes. Le noyau propose un certain nombre de trousseaux de clés d’ancrage. Il est à remarquer que certains de ces trousseaux de clés seront créés seulement lors de leur première accession.

Trousseaux de clés de processus

Les identifiants de processus eux-mêmes référencent les trousseaux de clés avec des sémantiques spécifiques. Ces trousseaux de clés sont attachés aussi longtemps que l’ensemble des identifiants existe, ce qui veut dire habituellement aussi longtemps que le processus existe.

Il existe trois trousseaux de clés avec des règles d’héritage et de partage différentes : session-keyring(7) (héritage et partage par tous les processus enfant), process-keyring(7) (partage par tous les threads dans un processus) et thread-keyring(7) (spécifique à un thread particulier).

Comme alternative à l’utilisation des identifiants réels de trousseau de clés dans les appels à add_key(2), keyctl(2) et request_key(2), les valeurs spéciales de trousseau de clés KEY_SPEC_SESSION_KEYRING, KEY_SPEC_PROCESS_KEYRING et KEY_SPEC_THREAD_KEYRING peuvent être utilisées comme références aux propres instances de l’appelant de ces trousseaux de clés.

Trousseau de clés utilisateur

Chaque UID connu du noyau possède un enregistrement qui contient deux trousseaux de clés : user-keyring(7) et user-session-keyring(7). Ceux-ci existent aussi longtemps que l’enregistrement de l’UID existe dans le noyau.

Comme alternative à l’utilisation des identifiants réels de trousseau de clés, dans les appels à add_key(2), keyctl(2) et request_key(2), les valeurs spéciales de trousseau de clés KEY_SPEC_USER_KEYRING et KEY_SPEC_USER_SESSION_KEYRING peuvent être utilisées comme références aux propres instances de l’appelant de ces trousseaux de clés.

Un lien vers le trousseau de clés utilisateur est placé dans le nouveau trousseau de clés de session par pam_keyinit(8) quand une nouvelle session de connexion est initiée.

Trousseaux de clés persistants

Il existe un persistent-keyring(7) disponible pour chaque UID connu du système. Il peut persister au-delà de la durée de l’enregistrement de l'UID précédemment mentionné, mais possède un ensemble de délais d’expiration de telle façon qu’il soit automatiquement nettoyé après un temps défini. Les trousseaux de clés persistants permettent, par exemple, aux scripts cron(8) d’utiliser les identifiants laissés dans le trousseau de clés persistant après la déconnexion de l’utilisateur.

Il est à remarquer que le délai d’expiration du trousseau de clés persistant est réinitialisé à chaque requête du trousseau de clés persistant.

Trousseaux de clés spéciaux

Il existe des trousseaux de clés spéciaux possédés par le noyau qui peuvent ancrer des clés pour des buts spéciaux. Un exemple de cela est le trousseau de clés système utilisé pour contenir les clés de chiffrement pour la vérification de signature des modèles.

Ces trousseaux de clés spéciaux sont habituellement fermés à une altération directe par l’espace utilisateur.

Un « trousseau de clés groupe », originellement prévu pour stocker des clés associées avec chaque GID connu du noyau, n’est pas encore implémenté et vraisemblablement ne le sera jamais. Néanmoins, la constante KEY_SPEC_GROUP_KEYRING a été définie pour ce type de trousseau de clés.

Possession

Le concept de possession est important pour comprendre le modèle de sécurité des trousseaux de clés. La possession par un thread d’une clé est déterminée par les règles suivantes :

(1)

Toute clé ou tout trousseau qui n’accorde pas la permission de recherche à l’appelant est ignoré dans toutes les règles qui suivent.

(2)

Un thread possède ses session-keyring(7), process-keyring(7) et thread-keyring(7) directement, car ces trousseaux de clés sont référencés par ses identifiants.

(3)

Si un trousseau de clés est possédé, alors toute clé liée est aussi possédée

(4)

Si une clé reliée à un trousseau de clés est elle-même un trousseau de clés, alors la règle (3) s’applique de manière récursive.

(5)

Si le noyau fait un appel montant de processus pour instancier une clé (consultez request_key(2)), alors il possède aussi les trousseaux de clés du requérant comme dans la règle (1) comme s’il était le requérant.

La possession n’est pas une propriété fondamentale de la clé, mais doit plutôt être calculée à chaque besoin de la clé. La possession est conçue pour permettre l’exécution de programmes set-user-ID à partir, par exemple, d’un interpréteur de commandes d’utilisateur pour accéder aux clés de l’utilisateur. Accorder la permission au possesseur de la clé tout en la refusant au propriétaire et au groupe de la clé permet d’empêcher l’accès à la clé sur la base de correspondance D’UID ou GID. Lorsqu’il crée un trousseau de clés de session, pam_keyinit(8) ajoute un lien à user-keyring(7), ce qui entraîne que le trousseau de clés d’utilisateur et tout ce qu’il contient sont possédés par défaut.

Droits d’accès

Chaque clé possède les attributs relatifs à la sécurité suivants :

•

l’ID de l’utilisateur propriétaire ;

•

l’ID du groupe autorisé à accéder à la clé ;

•

une étiquette de sécurité ;

•

un masque de permissions.

Le masque de permissions contient quatre ensembles de droits. Les trois premiers ensembles sont mutuellement exclusifs. Un et seulement un ensemble sera effectif pour une vérification particulière d’accès. Dans l’ordre décroissant de priorité, ces trois ensembles sont :

user

Cet ensemble indique les droits accordés si l’ID utilisateur de clé correspond à l’ID utilisateur de système de fichiers de l’appelant.

group

Cet ensemble indique les droits accordés si l’ID utilisateur ne correspond pas et que l’ID groupe de clé correspond au GID du système de fichiers de l’appelant ou à un de ses ID groupe supplémentaires.

other

Cet ensemble indique les droits accordés si ni l’ID utilisateur ni l’Id groupe de la clé ne correspondent.

Le quatrième ensemble de droits est :

possessor

Cet ensemble indique les droits accordés s’il est établi que l’appelant possède la clé.

L’ensemble complet des droits pour une clé est l’union de tout ce qui est applicable des trois premiers ensembles et du quatrième ensemble si la clé est possédée. L’ensemble des droits qui peuvent être accordés dans chacun des quatre masques est comme suit :

view

Les attributs de la clé peuvent être lus. Cela comprend le type, la description et les droits d’accès (à l’exclusion de l’étiquette de sécurité).

read

Pour une clé, sa charge utile peut être lue, pour un trousseau de clés, la liste des numéros de série (clés) auxquels le trousseau de clés est lié peut être lue.

write

La charge utile de la clé peut être mise à jour et la clé peut être révoquée. Pour un trousseau de clés, des liens peuvent y être ajoutés ou retirés et le trousseau de clés peut être complètement effacé (tous les liens sont retirés).

search

Pour une clé (ou un trousseau de clés), la clé peut être trouvée par une recherche. Pour un trousseau de clés, les clés ou trousseaux de clés liés peuvent être retrouvés.

link

Des liens peuvent être créés des trousseaux de clés vers la clé. Le lien initial vers une clé qui est établi quand la clé est créée n’a nul besoin de cette permission.

setattr

Les détails de possession et l’étiquette de sécurité de la clé peuvent être modifiés, le délai d’expiration de la clé peut être réglé et la clé peut être révoquée.

En plus des droits d’accès, tout module de sécurité de Linux (LSM) peut empêcher l’accès à une clé si sa politique l’indique. Une clé peut recevoir une étiquette de sécurité ou un autre attribut par le LSM. Cette étiquette est récupérable à l’aide de keyctl_get_security(3). Consultez keyctl_chown(3), keyctl_describe(3), keyctl_get_security(3), keyctl_setperm(3) et selinux(8) pour davantage d’informations.

Recherche de clés

Une des caractéristiques principales de la fonctionnalité de gestion de clés de Linux est la possibilité de trouver la clé qu’un processus conserve. L’appel système request_key(2) est le premier point d’accès pour les applications en espace utilisateur pour trouver la clé. En interne, le noyau a quelque chose de similaire disponible pour une utilisation par les composants internes qui utilisent des clés. L’algorithme de recherche fonctionne comme suit :

(1)

The process keyrings are searched in the following order: the thread-keyring(7) if it exists, the process-keyring(7) if it exists, and then either the session-keyring(7) if it exists or the user-session-keyring(7) if that exists.

(2)

Si l’appelant était un processus invoqué par le mécanisme d’appel montant request_key(2), alors les trousseaux de clés de l’appelant originel de request_key(2) seront aussi recherchés.

(3)

La recherche dans l’arbre des trousseaux est faite en largeur : chaque trousseau de clés est d’abord parcouru pour une correspondance puis les trousseaux de clés référencés par ce trousseau sont parcourus.

(4)

Si une clé correspondante valable est trouvée, alors la recherche se termine et cette clé est renvoyée.

(5)

Si une clé correspondante est trouvée à laquelle est attaché un état d’erreur, cet état d’erreur est noté et la recherche continue.

(6)

Si aucune clé correspondante valable n’est trouvée, alors le premier état d’erreur est renvoyé. Autrement, une erreur ENOKEY est renvoyée.

Il est aussi possible de rechercher une clé particulière, auquel cas seules les étapes (3) à (6) s’appliquent. Consultez request_key(2) et keyctl_search(3) pour davantage d’informations.

Création à la demande de clé

Si une clé ne peut être trouvée, et si un argument callout_info est fourni, request_key(2) créera une nouvelle clé et un appel montant dans l’espace utilisateur instanciera la clé. Cela permet de créer des clés selon les besoins. Classiquement, cela impliquera la création d’un nouveau processus par le noyau qui exécutera le programme request-key(8), qui lui-même exécutera alors le gestionnaire approprié basé sur sa configuration. Une clé d’autorisation spéciale est passée au gestionnaire qui lui permet, lui et seulement lui, d’instancier la nouvelle clé. Cela est aussi utilisé pour permettre des recherches réalisées par le programme gestionnaire pour aussi rechercher les trousseaux de clés du requérant. Consultez request_key(2), keyctl_assume_authority(3), keyctl_instantiate(3), keyctl_negate(3), keyctl_reject(3), request-key(8) et request-key.conf(5) pour davantage d’informations.

Fichiers /proc

Le noyau fournit divers fichiers /proc qui exposent les informations concernant les clés ou qui définissent les limites d’utilisation des clés.

/proc/keys (depuis Linux 2.6.10)

Ce fichier expose une liste de clés pour laquelle le thread lecteur possède la permission view, fournissant diverses informations à propos de chaque clé. Il n'est pas nécessaire que le thread possède la clé pour que cette dernière soit visible dans ce fichier.

Les seules clés incluses dans la liste sont celles qui accordent la permission view au processus lecteur (indépendamment du fait qu’il les possède ou non). Les vérifications de sécurité LSM sont toujours réalisées et peuvent supprimer par filtrage d’autres clés que le processus n’est pas autorisé à voir.

Voici un exemple de données pouvant être vues dans ce fichier (avec un numérotage des colonnes pour une référence facile dans les explications) :

  (1)     (2)     (3)(4)    (5)     (6)   (7)   (8)        (9)
009a2028 I--Q---   1 perm 3f010000  1000  1000 user     krb_ccache:primary: 12
1806c4ba I--Q---   1 perm 3f010000  1000  1000 keyring  _pid: 2
25d3a08f I--Q---   1 perm 1f3f0000  1000 65534 keyring  _uid_ses.1000: 1
28576bd8 I--Q---   3 perm 3f010000  1000  1000 keyring  _krb: 1
2c546d21 I--Q--- 190 perm 3f030000  1000  1000 keyring  _ses: 2
30a4e0be I------   4   2d 1f030000  1000 65534 keyring  _persistent.1000: 1
32100fab I--Q---   4 perm 1f3f0000  1000 65534 keyring  _uid.1000: 2
32a387ea I--Q---   1 perm 3f010000  1000  1000 keyring  _pid: 2
3ce56aea I--Q---   5 perm 3f030000  1000  1000 keyring  _ses: 1
    

Les champs affichés dans chaque ligne du fichier sont les suivants :

/proc/key-users (depuis Linux 2.6.10)

Ce fichier liste diverses informations pour chaque ID utilisateur qui possède au moins une clé dans le système. Voici un exemple des données visibles dans ce fichier :

   0:    10 9/9 2/1000000 22/25000000
  42:     9 9/9 8/200 106/20000
1000:    11 11/11 10/200 271/20000
    

Les champs affichés dans chaque ligne sont les suivants :

/proc/sys/kernel/keys/gc_delay (depuis Linux 2.6.32)

La valeur dans ce fichier indique l’intervalle, en seconde, après lequel les clés révoquées ou expirées seront collectées par le ramasse-miettes. Cet intervalle a pour but de disposer d'une fenêtre temporelle pendant laquelle l’espace utilisateur peut voir une erreur (respectivement EKEYREVOKED et EKEYEXPIRED) qui indique ce qui est arrivé à la clé.

La valeur par défaut dans ce fichier est 300 (c’est-à-dire cinq minutes).

/proc/sys/kernel/keys/persistent_keyring_expiry (depuis Linux 3.13)

Ce fichier définit un intervalle, en secondes, après lequel le programmateur de durée du trousseau de clés persistant est réinitialisé chaque fois que le trousseau de clés est accédé (à l’aide de l’opération keyctl_get_persistent(3) ou keyctl(2) KEYCTL_GET_PERSISTENT).

La valeur par défaut dans ce fichier est 259200 (c’est-à-dire trois jours).

Les fichiers suivants (pouvant être modifiés par les processus privilégiés) sont utilisés pour imposer des quotas sur le nombre de clés et le nombre d’octets de données pouvant être stockés dans les charges utiles des clés :

/proc/sys/kernel/keys/maxbytes (depuis Linux 2.6.26)

C’est le nombre maximal d’octets de données que les utilisateurs non privilégiés peuvent détenir dans les charges utiles des clés qu'ils possèdent.

La valeur par défaut dans ce fichier est 20 000.

/proc/sys/kernel/keys/maxkeys (depuis Linux 2.6.26)

C’est le nombre maximal de clés qu’un utilisateur non privilégié peut posséder.

La valeur par défaut dans ce fichier est 200.

/proc/sys/kernel/keys/root_maxbytes (depuis Linux 2.6.26)

C’est le nombre maximal d’octets de données que le superutilisateur (UID 0 dans l’espace de noms utilisateur racine) peut détenir dans les charges utiles des clés qu'il possède.

La valeur par défaut dans ce fichier est 25 000 000 (20 000 avant Linux 3.17).

/proc/sys/kernel/keys/root_maxkeys (depuis Linux 2.6.26)

C’est le nombre maximal de clés que le superutilisateur (UID 0 dans l’espace de noms utilisateur racine) peut détenir.

La valeur par défaut dans ce fichier est 1 000 000 (200 avant Linux 3.17).

En ce qui concerne les trousseaux de clés, il est à remarquer que chaque lien dans un trousseau consomme quatre octets de la charge utile du trousseau.

Utilisateurs

La fonctionnalité de gestion de clés de Linux a un certain nombre d’utilisateurs et d’usages, mais n’est pas limitée à ce qui existe déjà. Les utilisateurs du noyau de cette fonctionnalité comprennent :

Systèmes de fichiers réseau – DNS

Le noyau utilise le mécanisme d’appel montant fourni par les clés pour un appel montant dans l’espace utilisateur pour des recherches DNS et puis pour mettre en cache les résultats.

AF_RXRPC et kAFS – Authentification

Le protocole réseau AF_RXRPC et le système de fichiers AFS interne au noyau utilisent les clés pour enregistrer le ticket nécessaire pour un trafic sécurisé ou chiffré. Celles-ci sont recherchées par les opérations réseau lors d’opérations AF_RXRPC et de système de fichiers sur kAFS.

NFS – Mappage d’ID utilisateur

Le système de fichiers NFS utilise des clés pour stocker les mappages d’ID utilisateur étrangers à des ID utilisateur locaux.

CIFS – Mot de passe

Le système de fichiers CIFS utilise des clés pour stocker les mots de passe pour l'accès à des partages distants.

Vérification de module

Le processus de construction du noyau peut être conduit pour une signature chiffrée des modules.

Les utilisateurs de l’espace utilisateur de cette fonctionnalité incluent :

Stockage de clés Kerberos

La fonctionnalité Kerberos 5 du MIT (libkrb5) peut utiliser des clés pour stocker les jetons d’authentification. Cela peut servir à les supprimer automatiquement après une durée définie lorsque l'utilisateur les a utilisés pour la dernière fois, mais pendant ce temps leur permettre de se maintenir jusqu'à ce que l'utilisateur se soit déconnecté de façon à ce que les scripts cron(8) puissent les utiliser.

VOIR AUSSI

keyctl(1), add_key(2), keyctl(2), request_key(2), keyctl(3), keyutils(7), persistent-keyring(7), process-keyring(7), session-keyring(7), thread-keyring(7), user-keyring(7), user-session-keyring(7), pam_keyinit(8), request-key(8) Les fichiers source du noyau Documentation/crypto/asymmetric-keys.txt et dans Documentation/security/keys (ou, avant Linux 4.13, dans le fichier Documentation/security/keys.txt).

TRADUCTION

La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <[email protected]>, Thierry Vignaud <[email protected]>, François Micaux, Alain Portal <[email protected]>, Jean-Philippe Guérard <[email protected]>, Jean-Luc Coulon (f5ibh) <[email protected]>, Julien Cristau <[email protected]>, Thomas Huriaux <[email protected]>, Nicolas François <[email protected]>, Florentin Duneau <[email protected]>, Simon Paillard <[email protected]>, Denis Barbier <[email protected]>, David Prévot <[email protected]> et Jean-Paul Guillonneau <[email protected]> Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à [email protected]