On Thu, 2021-04-01 at 18:50 +0530, Sumit Garg wrote:
> On Thu, 1 Apr 2021 at 15:36, Ahmad Fatoum
> wrote:
> > Hello Richard,
> >
> > On 31.03.21 21:36, Richard Weinberger wrote:
> > > James,
> > >
> > > - Ursprüngliche Mail -
> > > > Von: "James Bottomley"
> > > > Well, yes. For the TP
Sumit,
- Ursprüngliche Mail -
> Von: "Sumit Garg"
> IIUC, this would require support for multiple trusted keys backends at
> runtime but currently the trusted keys subsystem only supports a
> single backend which is selected via kernel module parameter during
> boot.
>
> So the trusted k
On Thu, 1 Apr 2021 at 19:29, Richard Weinberger wrote:
>
> Sumit,
>
> - Ursprüngliche Mail -
> > Von: "Sumit Garg"
> > In this case why would one prefer to use CAAM when you have standards
> > compliant TPM-Chip which additionally offers sealing to specific PCR
> > (integrity measurement)
Ahmad,
- Ursprüngliche Mail -
> Von: "Ahmad Fatoum"
>> But using LUKS would mean that cryptsetup has access to the plain disc
>> encryption key material?
>> This would be a no-go for many systems out there, key material must not
>> accessible to userspace.
>> I know, distrusting userspace
Hi Richard,
On Wed, 31 Mar 2021 at 03:34, Richard Weinberger
wrote:
>
> Ahmad,
>
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>
> Is there a reason why we can't pass the desired backend name in the
> trusted key parameters?
Hello Richard, Sumit,
On 01.04.21 15:17, Richard Weinberger wrote:
> Sumit,
>
> - Ursprüngliche Mail -
>> Von: "Sumit Garg"
>> IIUC, this would require support for multiple trusted keys backends at
>> runtime but currently the trusted keys subsystem only supports a
>> single backend whic
On Thu, 1 Apr 2021 at 15:36, Ahmad Fatoum wrote:
>
> Hello Richard,
>
> On 31.03.21 21:36, Richard Weinberger wrote:
> > James,
> >
> > - Ursprüngliche Mail -
> >> Von: "James Bottomley"
> >> Well, yes. For the TPM, there's a defined ASN.1 format for the keys:
> >>
> >> https://git.kerne
On Thu, 1 Apr 2021 at 19:00, Ahmad Fatoum wrote:
>
> Hello Richard, Sumit,
>
> On 01.04.21 15:17, Richard Weinberger wrote:
> > Sumit,
> >
> > - Ursprüngliche Mail -
> >> Von: "Sumit Garg"
> >> IIUC, this would require support for multiple trusted keys backends at
> >> runtime but current
Sumit,
- Ursprüngliche Mail -
> Von: "Sumit Garg"
> In this case why would one prefer to use CAAM when you have standards
> compliant TPM-Chip which additionally offers sealing to specific PCR
> (integrity measurement) values.
I don't think we can dictate what good/sane solutions are and
Hello Richard,
On 01.04.21 13:05, Richard Weinberger wrote:
> Ahmad,
>
> - Ursprüngliche Mail -
>> Von: "Ahmad Fatoum"
>>> I don't want you to force to use cryptsetup.
>>
>> I'd love to use cryptsetup with LUKS and trusted keys eventually. I'll take
>
> But using LUKS would mean that cr
Richard Weinberger wrote:
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>
> Is there a reason why we can't pass the desired backend name in the
> trusted key parameters?
> e.g.
> keyctl add trusted $KEYNAME "backendtype caam
Ahmad,
- Ursprüngliche Mail -
> Von: "Ahmad Fatoum"
>> I don't want you to force to use cryptsetup.
>
> I'd love to use cryptsetup with LUKS and trusted keys eventually. I'll take
But using LUKS would mean that cryptsetup has access to the plain disc
encryption key material?
This would
Hello Richard,
On 01.04.21 12:53, Richard Weinberger wrote:
> Ahmad,
>
> - Ursprüngliche Mail -
>> Do you mean systemd-cryptsetup? It looks to me like it's just a way to supply
>> the keyphrase. With trusted keys and a keyphrase unknown to userspace, this
>> won't work.
>
> Nah, I meant
Ahmad,
- Ursprüngliche Mail -
> Do you mean systemd-cryptsetup? It looks to me like it's just a way to supply
> the keyphrase. With trusted keys and a keyphrase unknown to userspace, this
> won't work.
Nah, I meant existing scripts/service Files.
> I don't (yet) see the utility of it wit
Hello,
On 01.04.21 12:20, Richard Weinberger wrote:
> Ahmad,
>
> - Ursprüngliche Mail -
>> Von: "Ahmad Fatoum"
>>> I'm pretty sure with minimal changes it will work with your recent approach
>>> too.
>>
>> I am using dmsetup directly in my project. I am not familiar with cryptsetup
>> p
Ahmad,
- Ursprüngliche Mail -
> Von: "Ahmad Fatoum"
>> I'm pretty sure with minimal changes it will work with your recent approach
>> too.
>
> I am using dmsetup directly in my project. I am not familiar with cryptsetup
> plain. What benefits do you see with this over direct dmsetup?
c
Hello Richard,
On 31.03.21 21:36, Richard Weinberger wrote:
> James,
>
> - Ursprüngliche Mail -
>> Von: "James Bottomley"
>> Well, yes. For the TPM, there's a defined ASN.1 format for the keys:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-
Hello Richard,
On 30.03.21 23:50, Richard Weinberger wrote:
> Ahmad,
>
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
>
>> TABLE="0 $BLOCKS crypt $ALGO :32:trusted:$KEYNAME 0 $DEV 0 1
>> allow_discards"
>> echo $TABLE | dmsetup create mydev
>> echo $TABLE | dmsetup load myde
James,
- Ursprüngliche Mail -
> Von: "James Bottomley"
> Well, yes. For the TPM, there's a defined ASN.1 format for the keys:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/tree/tpm2-asn.h
>
> and part of the design of the file is that it's distinguish
On Wed, 2021-03-31 at 20:36 +0200, Richard Weinberger wrote:
> James,
>
> - Ursprüngliche Mail -
> > Von: "James Bottomley"
> > > On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum <
> > > a.fat...@pengutronix.de wrote:
> > > > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
> > >
James,
- Ursprüngliche Mail -
> Von: "James Bottomley"
>> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum > > wrote:
>> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>>
>> Is there a reason why we can't pass the desired backend name in the
>> trusted key parameters?
>> e.g.
On Wed, 2021-03-31 at 00:04 +0200, Richard Weinberger wrote:
> Ahmad,
>
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum > wrote:
> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>
> Is there a reason why we can't pass the desired backend name in the
> trusted key parameters?
> e.g.
Ahmad,
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
Is there a reason why we can't pass the desired backend name in the
trusted key parameters?
e.g.
keyctl add trusted $KEYNAME "backendtype caam load $(cat ~/kmk.blob)" @s
--
Ahmad,
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> TABLE="0 $BLOCKS crypt $ALGO :32:trusted:$KEYNAME 0 $DEV 0 1
> allow_discards"
> echo $TABLE | dmsetup create mydev
> echo $TABLE | dmsetup load mydev
Do you also plan to add support for this to cryptsetup?
David and I h
On Tue, 23 Mar 2021 at 22:04, Ahmad Fatoum wrote:
>
> Hello Horia,
>
> On 21.03.21 21:01, Horia Geantă wrote:
> > On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
> >> This patch series builds on top of Sumit's rework to have the CAAM as yet
> >> another
> >> trusted key backend.
> >>
> > Shouldn't the
Hello Horia,
On 21.03.21 21:01, Horia Geantă wrote:
>> - [RFC] drivers: crypto: caam: key: Add caam_tk key type
>>Franck added[3] a new "caam_tk" key type based on Udit's work. The key
>>material stays within the kernel only, but can optionally be user-set
>>instead of coming from RNG
Hello Horia,
On 21.03.21 21:01, Horia Geantă wrote:
> On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
>> This patch series builds on top of Sumit's rework to have the CAAM as yet
>> another
>> trusted key backend.
>>
> Shouldn't the description under TRUSTED_KEYS (in security/keys/Kconfig)
> be updated
On 3/16/2021 7:02 PM, Ahmad Fatoum wrote:
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key. There has been mul
Hello Richard,
On 17.03.21 00:10, Richard Weinberger wrote:
> On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
>> This series has been tested with dmcrypt[5] on an i.MX6DL.
>
> Do have this series also in a git repo to pull from?
> I'd like to give it a test on various systems.
Yes, please p
Ahmad,
On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
>
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.
Its blob mechanism can AES encrypt/decrypt user data using a unique
never-disclosed device-specific key. There has been multiple
discussions on how to represent this within th
31 matches
Mail list logo
