linux-kernel - Re: [PATCH 2/2] crypto: caam - support tagged keys for skcipher algorithms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 15 Sep 2020 16:42:48 +0300
From:   Horia Geantă <horia.geanta@....com>
To:     Richard Weinberger <richard.weinberger@...il.com>,
        Iuliana Prodan <iuliana.prodan@....com>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        Aymen Sghaier <aymen.sghaier@....com>,
        "David S. Miller" <davem@...emloft.net>,
        Silvano Di Ninno <silvano.dininno@....com>,
        Franck Lenormand <franck.lenormand@....com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        David Gstir <david@...ma-star.at>
Subject: Re: [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
> <richard.weinberger@...il.com> wrote:
>>
>> On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan <iuliana.prodan@....com> 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:
https://lore.kernel.org/lkml/8060.1533226481@warthog.procyon.org.uk
(Note the difference b/w adding new key type - which was rejected -
and a key "subtype extension".)

Horia