linux-kernel - Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY

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]

Message-ID: <YxcLqepquOuOOjvq@kernel.org>
Date:   Tue, 6 Sep 2022 11:58:17 +0300
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     Pankaj Gupta <pankaj.gupta@....com>
Cc:     a.fatoum@...gutronix.de, Jason@...c4.com, jejb@...ux.ibm.com,
        zohar@...ux.ibm.com, dhowells@...hat.com, sumit.garg@...aro.org,
        david@...ma-star.at, michael@...le.cc, john.ernberg@...ia.se,
        jmorris@...ei.org, serge@...lyn.com, herbert@...dor.apana.org.au,
        davem@...emloft.net, j.luebbe@...gutronix.de, ebiggers@...nel.org,
        richard@....at, keyrings@...r.kernel.org,
        linux-crypto@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org, sahil.malhotra@....com,
        kshitiz.varshney@....com, horia.geanta@....com, V.Sethi@....com
Subject: Re: [RFC PATCH HBK: 0/8] HW BOUND KEY as TRUSTED KEY

On Tue, Sep 06, 2022 at 12:21:49PM +0530, Pankaj Gupta wrote:
> Hardware Bound key(HBK), is never acessible as plain key outside of the
                                    ~~~~~~~~~
                                    accesible.

> hardware boundary. Thus, it is un-usable, even if somehow fetched
> from kernel memory. It ensures run-time security.

Why is it called "HBK" here and "hw" in the context of keyctl?

> This patchset adds generic support for classing the Hardware Bound Key,
> based on:
> 
> - Newly added flag-'is_hbk', added to the tfm.
> 
>   Consumer of the kernel crypto api, after allocating
>   the transformation, sets this flag based on the basis
>   of the type of key consumer has.
> 
> - This helps to influence the core processing logic
>   for the encapsulated algorithm.
> 
> - This flag is set by the consumer after allocating
>   the tfm and before calling the function crypto_xxx_setkey().
> 
> First implementation is based on CAAM.

CAAM is implementation of what exactly?

I'm sorry but I don't know your definition of unusable.

BR, Jarkko