[dm-crypt] LUKS header and token

[dm-crypt] LUKS header and token

[JT Morée]

Hello all,
  I am researching the LUKS2 format for a project I am working on. After reading the LUKS2 spec and searching for information on the token feature using the JSON header sections I still have lots of questions.  In this post Milan mentions that he wants to write an article on the token feature
https://marc.info/?l=dm-crypt&m=157235464607551&w=2

It's not that long ago and I'm assuming the article is not done.  Is there any other place I can look for examples and info on the token feature?  

To get started, I need to make sure that I understand the LUKS header.  It's stored in the clear?  Both binary and json data?  It is metadata that includes keyslots that are encrypted data but the header itself is not encrypted.

The json sections can store arbitrary data that allows processes to use the LUKS header to implement other features such as working with smart cards?  That's what I understand from the docs I have read so far.

Am I correct or did I misunderstand something?

Thank you,
JT

Re: [dm-crypt] LUKS header and token

[Milan Broz]

On 23/02/2020 04:08, JT Morée wrote:
> Hello all, I am researching the LUKS2 format for a project I am
> working on. After reading the LUKS2 spec and searching for
> information on the token feature using the JSON header sections I
> still have lots of questions.  In this post Milan mentions that he
> wants to write an article on the token feature 
> https://marc.info/?l=dm-crypt&m=157235464607551&w=2
> 
> It's not that long ago and I'm assuming the article is not done.  Is
> there any other place I can look for examples and info on the token
> feature?

Currently there is only LUKS2 doc. I had unfortunately some other
serious issues so I cannot promise any ETA here.
 
> To get started, I need to make sure that I understand the LUKS
> header.  It's stored in the clear?  Both binary and json data?  It is
> metadata that includes keyslots that are encrypted data but the
> header itself is not encrypted.

Read https://gitlab.com/cryptsetup/LUKS2-docs

Token is basically just JSON object that user application can process itself,
it is stored in clear LUKS header area.

Some trivial example is in source code in misc/luks2_keyslot_example.
There is a plan to extend this interface in next major version,
I expect we have some better examples in that time.

> The json sections can store arbitrary data that allows processes to
> use the LUKS header to implement other features such as working with
> smart cards?  That's what I understand from the docs I have read so
> far.

Partially, it can store these data, but there is no dynamic loading of
any extension, so you need to write own application to process these data.

So yes, the plan is to use it for TPM or SmartCard data, but keep the hw
dependence out of the core cryptsetup library.

Sorry for late response,
Milan

Re: [dm-crypt] LUKS header and token

[JT Morée]

On Friday, February 28, 2020, 4:22:43 AM MST, Milan Broz <gmazyland@gmail.com> wrote: 

> Read cryptsetup / LUKS2-docs

 
 
 
   
cryptsetup / LUKS2-docs
 Documentation to the LUKS2 format.   
Thank you, I read through that doc a few times.  It did give me a basic understanding.

>Some trivial example is in source code in misc/luks2_keyslot_example.
>There is a plan to extend this interface in next major version,
>I expect we have some better examples in that time.

I would be happy to help with documentation and maybe even coding in C but I'd prefer to keep my coding at a higher level such as at the system level where users would be.  My goal is to wire everything together from the user perspective.  It's difficult to quickly follow what's going on in the C code.  I'll use this example as one of my resources.

I think my plan complements your philosophy of letting users store a token in the header and then an external program handles everything else.   I would also be interested in hearing/reading/seeing any preliminary ideas you have on the new interface.

> Sorry for late response,
No problem. Thank you for your feedback.
--
JT