2012-09-13 08:17:21 -06:00
|
|
|
/* Asymmetric public-key cryptography key type
|
|
|
|
*
|
|
|
|
* See Documentation/security/asymmetric-keys.txt
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public Licence
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the Licence, or (at your option) any later version.
|
|
|
|
*/
|
|
|
|
#include <keys/asymmetric-subtype.h>
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
#include <keys/asymmetric-parser.h>
|
2012-09-13 08:17:21 -06:00
|
|
|
#include <linux/seq_file.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
2014-09-16 10:36:11 -06:00
|
|
|
#include <linux/ctype.h>
|
2012-09-13 08:17:21 -06:00
|
|
|
#include "asymmetric_keys.h"
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
static LIST_HEAD(asymmetric_key_parsers);
|
|
|
|
static DECLARE_RWSEM(asymmetric_key_parsers_sem);
|
|
|
|
|
2014-09-16 10:36:11 -06:00
|
|
|
/**
|
|
|
|
* asymmetric_key_generate_id: Construct an asymmetric key ID
|
|
|
|
* @val_1: First binary blob
|
|
|
|
* @len_1: Length of first binary blob
|
|
|
|
* @val_2: Second binary blob
|
|
|
|
* @len_2: Length of second binary blob
|
|
|
|
*
|
|
|
|
* Construct an asymmetric key ID from a pair of binary blobs.
|
|
|
|
*/
|
|
|
|
struct asymmetric_key_id *asymmetric_key_generate_id(const void *val_1,
|
|
|
|
size_t len_1,
|
|
|
|
const void *val_2,
|
|
|
|
size_t len_2)
|
|
|
|
{
|
|
|
|
struct asymmetric_key_id *kid;
|
|
|
|
|
|
|
|
kid = kmalloc(sizeof(struct asymmetric_key_id) + len_1 + len_2,
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!kid)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
kid->len = len_1 + len_2;
|
|
|
|
memcpy(kid->data, val_1, len_1);
|
|
|
|
memcpy(kid->data + len_1, val_2, len_2);
|
|
|
|
return kid;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(asymmetric_key_generate_id);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* asymmetric_key_id_same - Return true if two asymmetric keys IDs are the same.
|
|
|
|
* @kid_1, @kid_2: The key IDs to compare
|
|
|
|
*/
|
|
|
|
bool asymmetric_key_id_same(const struct asymmetric_key_id *kid1,
|
|
|
|
const struct asymmetric_key_id *kid2)
|
|
|
|
{
|
|
|
|
if (!kid1 || !kid2)
|
|
|
|
return false;
|
|
|
|
if (kid1->len != kid2->len)
|
|
|
|
return false;
|
|
|
|
return memcmp(kid1->data, kid2->data, kid1->len) == 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(asymmetric_key_id_same);
|
|
|
|
|
2014-10-06 08:21:05 -06:00
|
|
|
/**
|
|
|
|
* asymmetric_key_id_partial - Return true if two asymmetric keys IDs
|
|
|
|
* partially match
|
|
|
|
* @kid_1, @kid_2: The key IDs to compare
|
|
|
|
*/
|
|
|
|
bool asymmetric_key_id_partial(const struct asymmetric_key_id *kid1,
|
|
|
|
const struct asymmetric_key_id *kid2)
|
|
|
|
{
|
|
|
|
if (!kid1 || !kid2)
|
|
|
|
return false;
|
|
|
|
if (kid1->len < kid2->len)
|
|
|
|
return false;
|
|
|
|
return memcmp(kid1->data + (kid1->len - kid2->len),
|
|
|
|
kid2->data, kid2->len) == 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(asymmetric_key_id_partial);
|
|
|
|
|
2014-09-16 10:36:11 -06:00
|
|
|
/**
|
|
|
|
* asymmetric_match_key_ids - Search asymmetric key IDs
|
|
|
|
* @kids: The list of key IDs to check
|
|
|
|
* @match_id: The key ID we're looking for
|
2014-10-06 08:21:05 -06:00
|
|
|
* @match: The match function to use
|
2014-09-16 10:36:11 -06:00
|
|
|
*/
|
2014-10-06 08:21:05 -06:00
|
|
|
static bool asymmetric_match_key_ids(
|
|
|
|
const struct asymmetric_key_ids *kids,
|
|
|
|
const struct asymmetric_key_id *match_id,
|
|
|
|
bool (*match)(const struct asymmetric_key_id *kid1,
|
|
|
|
const struct asymmetric_key_id *kid2))
|
2014-09-16 10:36:11 -06:00
|
|
|
{
|
2014-10-06 08:21:05 -06:00
|
|
|
int i;
|
|
|
|
|
2014-09-16 10:36:11 -06:00
|
|
|
if (!kids || !match_id)
|
|
|
|
return false;
|
2014-10-06 08:21:05 -06:00
|
|
|
for (i = 0; i < ARRAY_SIZE(kids->id); i++)
|
|
|
|
if (match(kids->id[i], match_id))
|
|
|
|
return true;
|
2014-09-16 10:36:11 -06:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* asymmetric_key_hex_to_key_id - Convert a hex string into a key ID.
|
|
|
|
* @id: The ID as a hex string.
|
|
|
|
*/
|
|
|
|
struct asymmetric_key_id *asymmetric_key_hex_to_key_id(const char *id)
|
|
|
|
{
|
|
|
|
struct asymmetric_key_id *match_id;
|
2014-09-21 17:02:01 -06:00
|
|
|
size_t hexlen;
|
|
|
|
int ret;
|
2014-09-16 10:36:11 -06:00
|
|
|
|
|
|
|
if (!*id)
|
|
|
|
return ERR_PTR(-EINVAL);
|
2014-09-21 17:02:01 -06:00
|
|
|
hexlen = strlen(id);
|
2014-09-16 10:36:11 -06:00
|
|
|
if (hexlen & 1)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
match_id = kmalloc(sizeof(struct asymmetric_key_id) + hexlen / 2,
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!match_id)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
match_id->len = hexlen / 2;
|
2014-09-21 17:02:01 -06:00
|
|
|
ret = hex2bin(match_id->data, id, hexlen / 2);
|
|
|
|
if (ret < 0) {
|
|
|
|
kfree(match_id);
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
}
|
2014-09-16 10:36:11 -06:00
|
|
|
return match_id;
|
|
|
|
}
|
|
|
|
|
2014-06-17 02:56:57 -06:00
|
|
|
/*
|
2014-10-06 08:21:05 -06:00
|
|
|
* Match asymmetric keys by an exact match on an ID.
|
2012-09-13 08:17:21 -06:00
|
|
|
*/
|
2014-09-16 10:36:08 -06:00
|
|
|
static bool asymmetric_key_cmp(const struct key *key,
|
|
|
|
const struct key_match_data *match_data)
|
2012-09-13 08:17:21 -06:00
|
|
|
{
|
2014-09-16 10:36:13 -06:00
|
|
|
const struct asymmetric_key_ids *kids = asymmetric_key_ids(key);
|
|
|
|
const struct asymmetric_key_id *match_id = match_data->preparsed;
|
2012-09-13 08:17:21 -06:00
|
|
|
|
2014-10-06 08:21:05 -06:00
|
|
|
return asymmetric_match_key_ids(kids, match_id,
|
|
|
|
asymmetric_key_id_same);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Match asymmetric keys by a partial match on an IDs.
|
|
|
|
*/
|
|
|
|
static bool asymmetric_key_cmp_partial(const struct key *key,
|
|
|
|
const struct key_match_data *match_data)
|
|
|
|
{
|
|
|
|
const struct asymmetric_key_ids *kids = asymmetric_key_ids(key);
|
|
|
|
const struct asymmetric_key_id *match_id = match_data->preparsed;
|
|
|
|
|
|
|
|
return asymmetric_match_key_ids(kids, match_id,
|
|
|
|
asymmetric_key_id_partial);
|
2012-09-13 08:17:21 -06:00
|
|
|
}
|
|
|
|
|
2014-09-16 10:36:02 -06:00
|
|
|
/*
|
|
|
|
* Preparse the match criterion. If we don't set lookup_type and cmp,
|
|
|
|
* the default will be an exact match on the key description.
|
|
|
|
*
|
|
|
|
* There are some specifiers for matching key IDs rather than by the key
|
|
|
|
* description:
|
|
|
|
*
|
2014-10-06 08:21:05 -06:00
|
|
|
* "id:<id>" - find a key by partial match on any available ID
|
|
|
|
* "ex:<id>" - find a key by exact match on any available ID
|
2014-09-16 10:36:02 -06:00
|
|
|
*
|
|
|
|
* These have to be searched by iteration rather than by direct lookup because
|
|
|
|
* the key is hashed according to its description.
|
|
|
|
*/
|
|
|
|
static int asymmetric_key_match_preparse(struct key_match_data *match_data)
|
|
|
|
{
|
2014-09-16 10:36:13 -06:00
|
|
|
struct asymmetric_key_id *match_id;
|
|
|
|
const char *spec = match_data->raw_data;
|
|
|
|
const char *id;
|
2014-10-06 08:21:05 -06:00
|
|
|
bool (*cmp)(const struct key *, const struct key_match_data *) =
|
|
|
|
asymmetric_key_cmp;
|
2014-09-16 10:36:13 -06:00
|
|
|
|
|
|
|
if (!spec || !*spec)
|
|
|
|
return -EINVAL;
|
|
|
|
if (spec[0] == 'i' &&
|
|
|
|
spec[1] == 'd' &&
|
|
|
|
spec[2] == ':') {
|
|
|
|
id = spec + 3;
|
2014-10-06 08:21:05 -06:00
|
|
|
cmp = asymmetric_key_cmp_partial;
|
|
|
|
} else if (spec[0] == 'e' &&
|
|
|
|
spec[1] == 'x' &&
|
|
|
|
spec[2] == ':') {
|
|
|
|
id = spec + 3;
|
2014-09-16 10:36:13 -06:00
|
|
|
} else {
|
|
|
|
goto default_match;
|
|
|
|
}
|
|
|
|
|
|
|
|
match_id = asymmetric_key_hex_to_key_id(id);
|
2014-10-03 02:53:28 -06:00
|
|
|
if (IS_ERR(match_id))
|
|
|
|
return PTR_ERR(match_id);
|
2014-09-16 10:36:13 -06:00
|
|
|
|
|
|
|
match_data->preparsed = match_id;
|
2014-10-06 08:21:05 -06:00
|
|
|
match_data->cmp = cmp;
|
2014-09-16 10:36:13 -06:00
|
|
|
match_data->lookup_type = KEYRING_SEARCH_LOOKUP_ITERATE;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
default_match:
|
2014-09-16 10:36:02 -06:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Free the preparsed the match criterion.
|
|
|
|
*/
|
|
|
|
static void asymmetric_key_match_free(struct key_match_data *match_data)
|
|
|
|
{
|
2014-09-16 10:36:13 -06:00
|
|
|
kfree(match_data->preparsed);
|
2014-09-16 10:36:02 -06:00
|
|
|
}
|
|
|
|
|
2012-09-13 08:17:21 -06:00
|
|
|
/*
|
|
|
|
* Describe the asymmetric key
|
|
|
|
*/
|
|
|
|
static void asymmetric_key_describe(const struct key *key, struct seq_file *m)
|
|
|
|
{
|
|
|
|
const struct asymmetric_key_subtype *subtype = asymmetric_key_subtype(key);
|
2014-09-16 10:36:13 -06:00
|
|
|
const struct asymmetric_key_ids *kids = asymmetric_key_ids(key);
|
|
|
|
const struct asymmetric_key_id *kid;
|
|
|
|
const unsigned char *p;
|
|
|
|
int n;
|
2012-09-13 08:17:21 -06:00
|
|
|
|
|
|
|
seq_puts(m, key->description);
|
|
|
|
|
|
|
|
if (subtype) {
|
|
|
|
seq_puts(m, ": ");
|
|
|
|
subtype->describe(key, m);
|
|
|
|
|
2014-10-06 10:25:45 -06:00
|
|
|
if (kids && kids->id[1]) {
|
|
|
|
kid = kids->id[1];
|
2012-09-13 08:17:21 -06:00
|
|
|
seq_putc(m, ' ');
|
2014-09-16 10:36:13 -06:00
|
|
|
n = kid->len;
|
|
|
|
p = kid->data;
|
2014-10-06 10:25:45 -06:00
|
|
|
if (n > 4) {
|
|
|
|
p += n - 4;
|
|
|
|
n = 4;
|
2014-09-16 10:36:13 -06:00
|
|
|
}
|
|
|
|
seq_printf(m, "%*phN", n, p);
|
2012-09-13 08:17:21 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
seq_puts(m, " [");
|
|
|
|
/* put something here to indicate the key's capabilities */
|
|
|
|
seq_putc(m, ']');
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
/*
|
|
|
|
* Preparse a asymmetric payload to get format the contents appropriately for the
|
|
|
|
* internal payload to cut down on the number of scans of the data performed.
|
|
|
|
*
|
|
|
|
* We also generate a proposed description from the contents of the key that
|
|
|
|
* can be used to name the key if the user doesn't want to provide one.
|
|
|
|
*/
|
|
|
|
static int asymmetric_key_preparse(struct key_preparsed_payload *prep)
|
|
|
|
{
|
|
|
|
struct asymmetric_key_parser *parser;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
pr_devel("==>%s()\n", __func__);
|
|
|
|
|
|
|
|
if (prep->datalen == 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
down_read(&asymmetric_key_parsers_sem);
|
|
|
|
|
|
|
|
ret = -EBADMSG;
|
|
|
|
list_for_each_entry(parser, &asymmetric_key_parsers, link) {
|
|
|
|
pr_debug("Trying parser '%s'\n", parser->name);
|
|
|
|
|
|
|
|
ret = parser->parse(prep);
|
|
|
|
if (ret != -EBADMSG) {
|
|
|
|
pr_debug("Parser recognised the format (ret %d)\n",
|
|
|
|
ret);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
up_read(&asymmetric_key_parsers_sem);
|
|
|
|
pr_devel("<==%s() = %d\n", __func__, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clean up the preparse data
|
|
|
|
*/
|
|
|
|
static void asymmetric_key_free_preparse(struct key_preparsed_payload *prep)
|
|
|
|
{
|
|
|
|
struct asymmetric_key_subtype *subtype = prep->type_data[0];
|
2014-09-16 10:36:13 -06:00
|
|
|
struct asymmetric_key_ids *kids = prep->type_data[1];
|
2014-10-06 08:21:05 -06:00
|
|
|
int i;
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
|
|
|
|
pr_devel("==>%s()\n", __func__);
|
|
|
|
|
|
|
|
if (subtype) {
|
2014-07-18 11:56:34 -06:00
|
|
|
subtype->destroy(prep->payload[0]);
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
module_put(subtype->owner);
|
|
|
|
}
|
2014-09-16 10:36:13 -06:00
|
|
|
if (kids) {
|
2014-10-06 08:21:05 -06:00
|
|
|
for (i = 0; i < ARRAY_SIZE(kids->id); i++)
|
|
|
|
kfree(kids->id[i]);
|
2014-09-16 10:36:13 -06:00
|
|
|
kfree(kids);
|
|
|
|
}
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
kfree(prep->description);
|
|
|
|
}
|
|
|
|
|
2012-09-13 08:17:21 -06:00
|
|
|
/*
|
|
|
|
* dispose of the data dangling from the corpse of a asymmetric key
|
|
|
|
*/
|
|
|
|
static void asymmetric_key_destroy(struct key *key)
|
|
|
|
{
|
|
|
|
struct asymmetric_key_subtype *subtype = asymmetric_key_subtype(key);
|
2014-09-16 10:36:13 -06:00
|
|
|
struct asymmetric_key_ids *kids = key->type_data.p[1];
|
|
|
|
|
2012-09-13 08:17:21 -06:00
|
|
|
if (subtype) {
|
|
|
|
subtype->destroy(key->payload.data);
|
|
|
|
module_put(subtype->owner);
|
|
|
|
key->type_data.p[0] = NULL;
|
|
|
|
}
|
2014-09-16 10:36:13 -06:00
|
|
|
|
|
|
|
if (kids) {
|
|
|
|
kfree(kids->id[0]);
|
|
|
|
kfree(kids->id[1]);
|
|
|
|
kfree(kids);
|
|
|
|
key->type_data.p[1] = NULL;
|
|
|
|
}
|
2012-09-13 08:17:21 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
struct key_type key_type_asymmetric = {
|
|
|
|
.name = "asymmetric",
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
.preparse = asymmetric_key_preparse,
|
|
|
|
.free_preparse = asymmetric_key_free_preparse,
|
2014-07-18 11:56:34 -06:00
|
|
|
.instantiate = generic_key_instantiate,
|
2014-09-16 10:36:02 -06:00
|
|
|
.match_preparse = asymmetric_key_match_preparse,
|
|
|
|
.match_free = asymmetric_key_match_free,
|
2012-09-13 08:17:21 -06:00
|
|
|
.destroy = asymmetric_key_destroy,
|
|
|
|
.describe = asymmetric_key_describe,
|
|
|
|
};
|
|
|
|
EXPORT_SYMBOL_GPL(key_type_asymmetric);
|
|
|
|
|
KEYS: Asymmetric key pluggable data parsers
The instantiation data passed to the asymmetric key type are expected to be
formatted in some way, and there are several possible standard ways to format
the data.
The two obvious standards are OpenPGP keys and X.509 certificates. The latter
is especially useful when dealing with UEFI, and the former might be useful
when dealing with, say, eCryptfs.
Further, it might be desirable to provide formatted blobs that indicate
hardware is to be accessed to retrieve the keys or that the keys live
unretrievably in a hardware store, but that the keys can be used by means of
the hardware.
From userspace, the keys can be loaded using the keyctl command, for example,
an X.509 binary certificate:
keyctl padd asymmetric foo @s <dhowells.pem
or a PGP key:
keyctl padd asymmetric bar @s <dhowells.pub
or a pointer into the contents of the TPM:
keyctl add asymmetric zebra "TPM:04982390582905f8" @s
Inside the kernel, pluggable parsers register themselves and then get to
examine the payload data to see if they can handle it. If they can, they get
to:
(1) Propose a name for the key, to be used it the name is "" or NULL.
(2) Specify the key subtype.
(3) Provide the data for the subtype.
The key type asks the parser to do its stuff before a key is allocated and thus
before the name is set. If successful, the parser stores the suggested data
into the key_preparsed_payload struct, which will be either used (if the key is
successfully created and instantiated or updated) or discarded.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2012-09-13 08:17:32 -06:00
|
|
|
/**
|
|
|
|
* register_asymmetric_key_parser - Register a asymmetric key blob parser
|
|
|
|
* @parser: The parser to register
|
|
|
|
*/
|
|
|
|
int register_asymmetric_key_parser(struct asymmetric_key_parser *parser)
|
|
|
|
{
|
|
|
|
struct asymmetric_key_parser *cursor;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
down_write(&asymmetric_key_parsers_sem);
|
|
|
|
|
|
|
|
list_for_each_entry(cursor, &asymmetric_key_parsers, link) {
|
|
|
|
if (strcmp(cursor->name, parser->name) == 0) {
|
|
|
|
pr_err("Asymmetric key parser '%s' already registered\n",
|
|
|
|
parser->name);
|
|
|
|
ret = -EEXIST;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
list_add_tail(&parser->link, &asymmetric_key_parsers);
|
|
|
|
|
|
|
|
pr_notice("Asymmetric key parser '%s' registered\n", parser->name);
|
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
up_write(&asymmetric_key_parsers_sem);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(register_asymmetric_key_parser);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* unregister_asymmetric_key_parser - Unregister a asymmetric key blob parser
|
|
|
|
* @parser: The parser to unregister
|
|
|
|
*/
|
|
|
|
void unregister_asymmetric_key_parser(struct asymmetric_key_parser *parser)
|
|
|
|
{
|
|
|
|
down_write(&asymmetric_key_parsers_sem);
|
|
|
|
list_del(&parser->link);
|
|
|
|
up_write(&asymmetric_key_parsers_sem);
|
|
|
|
|
|
|
|
pr_notice("Asymmetric key parser '%s' unregistered\n", parser->name);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(unregister_asymmetric_key_parser);
|
|
|
|
|
2012-09-13 08:17:21 -06:00
|
|
|
/*
|
|
|
|
* Module stuff
|
|
|
|
*/
|
|
|
|
static int __init asymmetric_key_init(void)
|
|
|
|
{
|
|
|
|
return register_key_type(&key_type_asymmetric);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit asymmetric_key_cleanup(void)
|
|
|
|
{
|
|
|
|
unregister_key_type(&key_type_asymmetric);
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(asymmetric_key_init);
|
|
|
|
module_exit(asymmetric_key_cleanup);
|