319 lines
10 KiB
HTML
319 lines
10 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of ASYMMETRIC-KEY</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>ASYMMETRIC-KEY</H1>
|
|
Section: Asymmetric Kernel Key Type (7)<BR>Updated: 8 Nov 2018<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
asymmetric - Kernel key type for holding asymmetric keys
|
|
|
|
<A NAME="lbAC"> </A>
|
|
<H2>OVERVIEW</H2>
|
|
|
|
<P>
|
|
|
|
A kernel key of
|
|
<B>asymmetric</B>
|
|
|
|
type acts as a handle to an asymmetric key as used for public-key
|
|
cryptography. The key material itself may be held inside the kernel or it may
|
|
be held in hardware with operations being offloaded. This prevents direct
|
|
user access to the cryptographic material.
|
|
<P>
|
|
|
|
Keys may be any asymmetric type (RSA, ECDSA, ...) and may have both private and
|
|
public components present or just the public component.
|
|
<P>
|
|
|
|
Asymmetric keys can be made use of by both the kernel and userspace. The
|
|
kernel can make use of them for module signature verification and kexec image
|
|
verification for example. Userspace is provided with a set of
|
|
<B>keyctl</B>(<B>KEYCTL_PKEY_*</B>)
|
|
|
|
calls for querying and using the key. These are wrapped by
|
|
<B>libkeyutils</B>
|
|
|
|
as functions named
|
|
<B>keyctl_pkey_*()</B>.
|
|
|
|
<P>
|
|
|
|
An asymmetric-type key can be loaded by the keyctl utility using a command
|
|
line like:
|
|
<P>
|
|
|
|
|
|
|
|
openssl x509 -in key.x509 -outform DER |
|
|
keyctl padd asymmetric foo @s
|
|
|
|
|
|
|
|
<A NAME="lbAD"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
<P>
|
|
|
|
The asymmetric-type key can be viewed as a container that comprises of a
|
|
number of components:
|
|
<DL COMPACT>
|
|
<DT id="1">Parsers<DD>
|
|
The asymmetric key parsers attempt to identify the content of the payload blob
|
|
and extract useful data from it with which to instantiate the key. The parser
|
|
is only used when adding, instantiating or updating a key and isn't thereafter
|
|
associated with the key.
|
|
<DT id="2"><DD>
|
|
Available parsers include ones that can deal with
|
|
DER-encoded <B>X.509</B>, DER-encoded <B>PKCS#8</B> and DER-encoded <B>TPM</B>-wrapped blobs.
|
|
|
|
<DT id="3">Public and private keys<DD>
|
|
These are the cryptographic components of the key pair. The public half
|
|
should always be available, but the private half might not be. What
|
|
operations are available can be queried, as can the size of the key. The key
|
|
material may or may not actually reside in the kernel.
|
|
<DT id="4">Identifiers<DD>
|
|
In addition to the normal key description (which can be generated by the
|
|
parser), a number of supplementary identifiers may be available that can be
|
|
searched for. These may be obtained, for example, by hashing the public key
|
|
material or from the subjectKeyIdentifier in an X.509 certificate.
|
|
<DT id="5"><DD>
|
|
Identifier-based searches are selected by passing as the description to
|
|
<B>keyctl_search</B>()
|
|
|
|
a string constructed of hex characters prefixed with either "id:" or "ex:".
|
|
The "id:" prefix indicates that a partial tail match is permissible whereas
|
|
"ex:" requires an exact match on the full string. The hex characters indicate
|
|
the data to match.
|
|
<DT id="6">Subtype<DD>
|
|
This is the driver inside the kernel that accesses the key material and
|
|
performs operations on it. It might be entirely software-based or it may
|
|
offload the operations to a hardware key store, such as a
|
|
<B>TPM</B>.
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
Note that expiry times from the payload are ignored as these patches may be
|
|
used during boot before the system clock is set.
|
|
|
|
<A NAME="lbAE"> </A>
|
|
<H2>PARSERS</H2>
|
|
|
|
<P>
|
|
|
|
The asymmetric key parsers can handle keys in a number of forms:
|
|
<DL COMPACT>
|
|
<DT id="7"><B>X.509</B><DD>
|
|
DER-encoded X.509 certificates can be accepted. Two identifiers are
|
|
constructed: one from from the certificate issuer and serial number and the
|
|
other from the subjectKeyIdentifier, if present. If left blank, the key
|
|
description will be filled in from the subject field plus either the
|
|
subjectKeyIdentifier or the serialNumber. Only the public key is filled in
|
|
and only the encrypt and verify operations are supported.
|
|
<DT id="8"><DD>
|
|
The signature on the X.509 certificate may be checked by the keyring it is
|
|
being added to and it may also be rejected if the key is blacklisted.
|
|
<DT id="9"><B>PKCS#8</B><DD>
|
|
Unencrypted DER-encoded PKCS#8 key data containers can be accepted. Currently
|
|
no identifiers are constructed. The private key and the public key are loaded
|
|
from the PKCS#8 blobs. Encrypted PKCS#8 is not currently supported.
|
|
<DT id="10"><B>TPM-Wrapped keys</B><DD>
|
|
DER-encoded TPM-wrapped TSS key blobs can be accepted. Currently no
|
|
identifiers are constructed. The public key is extracted from the blob but
|
|
the private key is expected to be resident in the TPM. Encryption and
|
|
signature verification is done in software, but decryption and signing are
|
|
offloaded to the TPM so as not to expose the private key.
|
|
<DT id="11"><DD>
|
|
This parser only supports TPM-1.2 wrappings and enc=pkcs1 encoding type. It
|
|
also uses a hard-coded null SRK password; password-protected SRKs are not yet
|
|
supported.
|
|
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H2>USERSPACE API</H2>
|
|
|
|
<P>
|
|
|
|
In addition to the standard keyutils library functions, such as
|
|
<I>keyctl_update</I>(),
|
|
|
|
there are five calls specific to the asymmetric key type (though they are open
|
|
to being used by other key types also):
|
|
<P>
|
|
|
|
<DL COMPACT><DT id="12"><DD>
|
|
<I>keyctl_pkey_query</I>()
|
|
<BR>
|
|
|
|
<I>keyctl_pkey_encrypt</I>()
|
|
<BR>
|
|
|
|
<I>keyctl_pkey_decrypt</I>()
|
|
<BR>
|
|
|
|
<I>keyctl_pkey_sign</I>()
|
|
<BR>
|
|
|
|
<I>keyctl_pkey_verify</I>()
|
|
</DL>
|
|
|
|
<P>
|
|
|
|
The query function can be used to retrieve information about an asymmetric key,
|
|
such as the key size, the amount of space required by buffers for the other
|
|
operations and which operations are actually supported.
|
|
<P>
|
|
|
|
The other operations form two pairs: encrypt/decrypt and create/verify
|
|
signature. Not all of these operations will necessarily be available;
|
|
typically, encrypt and verify only require the public key to be available
|
|
whereas decrypt and sign require the private key as well.
|
|
<P>
|
|
|
|
All of these operations take an information string parameter that supplies
|
|
additional information such as encoding type/form and the password(s) needed to
|
|
unlock/unwrap the key. This takes the form of a comma-separated list of
|
|
"key[=value]" pairs, the exact set of which depends on the subtype driver used
|
|
by a particular key.
|
|
<P>
|
|
|
|
Available parameters include:
|
|
<DL COMPACT>
|
|
<DT id="13">enc=<type><DD>
|
|
The encoding type for use in an encrypted blob or a signature. An example
|
|
might be "enc=pkcs1".
|
|
<DT id="14">hash=<name><DD>
|
|
The name of the hash algorithm that was used to digest the data to be signed.
|
|
Note that this is only used to construct any encoding that is used in a
|
|
signature. The data to be signed or verified must have been parsed by the
|
|
caller and the hash passed to <I>keyctl_pkey_sign</I>() or
|
|
<I>keyctl_pkey_verify</I>() beforehand. An example might be "hash=sha256".
|
|
</DL>
|
|
<P>
|
|
|
|
Note that not all parameters are used by all subtypes.
|
|
|
|
<A NAME="lbAG"> </A>
|
|
<H2>RESTRICTED KEYRINGS</H2>
|
|
|
|
<P>
|
|
|
|
An additional keyutils function,
|
|
<I>keyctl_restrict_keyring</I>(),
|
|
|
|
can be used to gate a keyring so that a new key can only be added to the
|
|
affected keyring if (a) it's an asymmetric key, (b) it's validly signed by a
|
|
key in some appropriate keyring and (c) it's not blacklisted.
|
|
<P>
|
|
|
|
|
|
|
|
<BR> keyctl_restrict_keyring(keyring, "asymmetric",
|
|
<BR> "key_or_keyring:<signing-key>[:chain]");
|
|
|
|
|
|
<P>
|
|
|
|
Where <I><signing-key></I> is the ID of a key or a ring of keys that act as the
|
|
authority to permit a new key to be added to the keyring. The <I>chain</I> flag
|
|
indicates that keys that have been added to the keyring may also be used to
|
|
verify new keys. Authorising keys must themselves be asymmetric-type keys that
|
|
can be used to do a signature verification on the key being added.
|
|
<P>
|
|
|
|
Note that there are various system keyrings visible to the root user that may
|
|
permit additional keys to be added. These are typically gated by keys that
|
|
already exist, preventing unauthorised keys from being used for such things as
|
|
module verification.
|
|
|
|
<A NAME="lbAH"> </A>
|
|
<H2>BLACKLISTING</H2>
|
|
|
|
<P>
|
|
|
|
When the attempt is made to add a key to the kernel, a hash of the public key
|
|
is checked against the
|
|
<B>blacklist.</B>
|
|
|
|
This is a system keyring named
|
|
<B>.blacklist</B>
|
|
|
|
and contains keys of type
|
|
<B>blacklist</B>.
|
|
|
|
If the blacklist contains a key whose description matches the hash of the new
|
|
key, that new key will be rejected with error
|
|
<B>EKEYREJECTED</B>.
|
|
|
|
<P>
|
|
|
|
The blacklist keyring may be loaded from multiple sources, including a list
|
|
compiled into the kernel and the UEFI
|
|
<B>dbx</B>
|
|
|
|
variable. Further hashes may also be blacklisted by the administrator. Note
|
|
that blacklisting is not retroactive, so an asymmetric key that is already on
|
|
the system cannot be blacklisted by adding a matching blacklist entry later.
|
|
|
|
<A NAME="lbAI"> </A>
|
|
<H2>VERSIONS</H2>
|
|
|
|
The
|
|
<B>asymmetric</B>
|
|
|
|
key type first appeared in v3.7 of the Linux kernel, the
|
|
<B>restriction</B>
|
|
|
|
function in v4.11 and the
|
|
<B>public key operations</B>
|
|
|
|
in v4.20.
|
|
<A NAME="lbAJ"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?1+keyctl">keyctl</A></B>(1),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?2+add_key">add_key</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl">keyctl</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_pkey_encrypt">keyctl_pkey_encrypt</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_pkey_query">keyctl_pkey_query</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_pkey_sign">keyctl_pkey_sign</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+keyrings">keyrings</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+keyutils">keyutils</A></B>(7)
|
|
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="15"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="16"><A HREF="#lbAC">OVERVIEW</A><DD>
|
|
<DT id="17"><A HREF="#lbAD">DESCRIPTION</A><DD>
|
|
<DT id="18"><A HREF="#lbAE">PARSERS</A><DD>
|
|
<DT id="19"><A HREF="#lbAF">USERSPACE API</A><DD>
|
|
<DT id="20"><A HREF="#lbAG">RESTRICTED KEYRINGS</A><DD>
|
|
<DT id="21"><A HREF="#lbAH">BLACKLISTING</A><DD>
|
|
<DT id="22"><A HREF="#lbAI">VERSIONS</A><DD>
|
|
<DT id="23"><A HREF="#lbAJ">SEE ALSO</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:07 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|