[lkml]   [2020]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] crypto: caam - support tagged keys for skcipher algorithms
On 9/14/2020 9:38 AM, Richard Weinberger wrote:
> On Thu, Jul 16, 2020 at 4:12 PM Richard Weinberger
> <> wrote:
>> On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan <> wrote:
>>> Tagged keys are keys that contain metadata indicating what
>>> they are and how to handle them using tag_object API.
>>> Add support, for tagged keys, to skcipher algorithms by
>>> adding new transformations, with _tk_ prefix to distinguish
>>> between plaintext and tagged keys.
>>> For job descriptors a new option (key_cmd_opt) was added for KEY command.
>>> Tagged keys can be loaded using only a KEY command with ENC=1
>>> and the proper setting of the EKT bit. The EKT bit in the
>>> KEY command indicates which encryption algorithm (AES-ECB or
>>> AES-CCM) should be used to decrypt the key. These options will be kept in
>>> key_cmd_opt.
>>> The tk_ transformations can be used directly by their name:
>>> struct sockaddr_alg sa = {
>>> .salg_family = AF_ALG,
>>> .salg_type = "skcipher", /* this selects the symmetric cipher */
>>> .salg_name = "tk(cbc(aes))" /* this is the cipher name */
>>> };
>>> or for dm-crypt, e.g. using dmsetup:
>>> dmsetup -v create encrypted --table "0 $(blockdev --getsz /dev/mmcblk2p10)
>>> crypt capi:tk(cbc(aes))-plain :32:logon:seckey 0 /dev/mmcblk2p10 0 1
>>> sector_size:512".
>> How to use it with cryptsetup?
>> I'm asking because it is not clear to me why you are not implementing
>> a new kernel key type (KEYS subsystem)
>> to utilize tagged keys.
>> Many tools already support the keyctl userspace interface (cryptsetup,
>> fscrypt, ...).
> *friendly ping*
We didn't include the key management part in this series,
just the crypto API support for algorithms with protected keys,
to get early feedback.

Wrt. key management:
The NXP vendor / downstream kernel (to be included in i.MX BSP Q3 release)
will have support for protected keys generation.
Besides this, a dedicated ioctl-based interface will allow userspace to
generate and export these keys. After this, user can use standard keyctl
to add a key (as user / logon type) in the keyring, such that it would be
available to dm-crypt.

We know that adding new ioctls is frowned upon, so before trying to upstream
the ioctl-based solution the plan is checking the feasibility of
extending keyctl as David Howells suggested:
(Note the difference b/w adding new key type - which was rejected -
and a key "subtype extension".)


 \ /
  Last update: 2020-09-16 02:33    [W:0.063 / U:1.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site