[dm-crypt] about invalid key slots

[dm-crypt] about invalid key slots

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

> $ sudo cryptsetup luksOpen /dev/sdc dsk
> LUKS keyslot 6 is invalid.
> LUKS keyslot 7 is invalid.

A user with a problem with invalid key slots had the above in one of the
recent mailing list post.

Does cryptsetup check all slots if they are valid before it tries to open a
volume and bail out when it finds an invalid one or does it give the above
error if it cant get a valid key on on valid key slots?

example, if a valid slot was on slot number 1 and he entered a passphrase
that is on slot number 1.Would he have got the same error message?

did cryptsetup went through all the valid keyslots, didnt find the key and
suspect that the key might be on the two invalid slots and reported the
error?

[-- Attachment #2: Type: text/html, Size: 765 bytes --]

Re: [dm-crypt] about invalid key slots

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

On Sun, Apr 1, 2012 at 8:41 PM, .. ink .. <mhogomchungu@gmail.com> wrote:

> > $ sudo cryptsetup luksOpen /dev/sdc dsk
> > LUKS keyslot 6 is invalid.
> > LUKS keyslot 7 is invalid.
>
> A user with a problem with invalid key slots had the above in one of the
> recent mailing list post.
>
> Does cryptsetup check all slots if they are valid before it tries to open
> a volume and bail out when it finds an invalid one or does it give the
> above error if it cant get a valid key on on valid key slots?
>
> example, if a valid slot was on slot number 1 and he entered a passphrase
> that is on slot number 1.Would he have got the same error message?
>
> did cryptsetup went through all the valid keyslots, didnt find the key and
> suspect that the key might be on the two invalid slots and reported the
> error?
>
>
>
is it possible to get or how can i create a volume with an invalid key? i
would lik3 to test this for my program zulucrypt but i cant seem to manage
to corrupt a volume. The best i have got after trying for hours is
inconsistency at best.

crypt_keyslot_status API shows the key is invalid but cryptsetup luksDump
shown the key slot as disabled and cryptsetup executable just says the
password does not exist when trying to open the volume with the a key in
slot i try to make invalid

[-- Attachment #2: Type: text/html, Size: 1580 bytes --]

Re: [dm-crypt] about invalid key slots

[Arno Wagner]

On Mon, Apr 02, 2012 at 01:43:28AM -0400, .. ink .. wrote:
> On Sun, Apr 1, 2012 at 8:41 PM, .. ink .. <mhogomchungu@gmail.com> wrote:
> 
> > > $ sudo cryptsetup luksOpen /dev/sdc dsk
> > > LUKS keyslot 6 is invalid.
> > > LUKS keyslot 7 is invalid.
> >
> > A user with a problem with invalid key slots had the above in one of the
> > recent mailing list post.
> >
> > Does cryptsetup check all slots if they are valid before it tries to open
> > a volume and bail out when it finds an invalid one or does it give the
> > above error if it cant get a valid key on on valid key slots?
> >
> > example, if a valid slot was on slot number 1 and he entered a passphrase
> > that is on slot number 1.Would he have got the same error message?
> >
> > did cryptsetup went through all the valid keyslots, didnt find the key and
> > suspect that the key might be on the two invalid slots and reported the
> > error?
> >
> >
> >
> is it possible to get or how can i create a volume with an invalid key? i
> would lik3 to test this for my program zulucrypt but i cant seem to manage
> to corrupt a volume. The best i have got after trying for hours is
> inconsistency at best.
> 
> crypt_keyslot_status API shows the key is invalid but cryptsetup luksDump
> shown the key slot as disabled and cryptsetup executable just says the
> password does not exist when trying to open the volume with the a key in
> slot i try to make invalid

As far as I understand Milan, this is not the keyslot being
invalid, but its offset and/or size, i.e. the keyslot descriptor
in the header has been corrupted.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

Re: [dm-crypt] about invalid key slots

[Milan Broz]

On 04/02/2012 07:43 AM, .. ink .. wrote:

> is it possible to get or how can i create a volume with an invalid
> key? i would lik3 to test this for my program zulucrypt but i cant
> seem to manage to corrupt a volume. The best i have got after trying
> for hours is inconsistency at best.

You do not need to add test for anything - crypt_load reports invalid header.

Obviously you cannot create invalid LUKS header with libcryptsetup
(or you found a bug :-) but you can easily simulate similar problem
e.g. by overwriting the second sector of device:

# cryptsetup luksFormat /dev/sdb
# dd if=/dev/urandom of=/dev/sdb seek=1 bs=512 count=1

# cryptsetup luksDump /dev/sdb
LUKS keyslot 6 is invalid.
LUKS keyslot 7 is invalid.

Note it is visible header, just keyslot info area, not the keyslot
itself. (Perhaps I should fix the error message.)

> crypt_keyslot_status API shows the key is invalid but cryptsetup
> luksDump shown the key slot as disabled and cryptsetup executable
> just says the password does not exist when trying to open the volume
> with the a key in  slot i try to make invalid

You are parsing some error code wrong, it should fail during
crypt_load() already. If it fails, using any api function
over invalid crypt context is undefined, whatever function it is.

Milan

Re: [dm-crypt] about invalid key slots

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 3042 bytes --]

resending the email to the list as i think the first one was sent not to
the mailing list

i am seeing something odd, i can not explain it but this is what i am
seeing, atleast there is consistency finally.

i wrote a simple program to test this and this is what i have found out.
the program is called cik in this example and it takes 4 args,path to luks
volume,offset,junk to write at the offset,new hopefully corrupted volume

on-disk-format.pdf says key-slot-2 is at offset 256, luksDump says its at
264. Is this expected?

the output of "zuluCrypt-cli -b" to show slot status :
0 - inactive slot
1- active slot
2- invalid slot

test1
[ink@mtz ~]$ ./cik luks 256  tiufvtfbuybougougbtvtvviytrf  cvol
[ink@mtz ~]$ zuluCrypt-cli -b -d cvol
12100000
[ink@mtz ~]$

when i try my test with offset 256 , luksDump reports the slot as disabled
but crypt_keyslot_status API reports it as invalid as the above test show.

the above is output as reported by crypt_keyslot_max(), full code at the
end of this email.

test2
[ink@mtz ~]$ ./cik luks 264  tiufvtfbuybougougbtvtvviytrf  cvol
[ink@mtz ~]$ zuluCrypt-cli -b -d cvol
11100000
[ink@mtz ~]$

when i add junk at offset 264 of length less than 32 characters as
above,crypt_keyslot_max() and luksDump reports the slot as active and
cryptsetup ask for a passphrase when attempting to open the volume.

test3
[ink@mtz ~]$ ./cik luks 264  tiufvtfbuybougougbtvtfgytfvytr

    yfbyfvviytrf  cvol
    [ink@mtz ~]$ zuluCrypt-cli -b -d cvol
    device "cvol" is not a luks device
    [ink@mtz ~]$

    if i increase the junk to above 32 characters as above, luksDump
reports:
    [root@mtz ink]# cryptsetup luksDump cvol
    LUKS keyslot 1 is invalid.

    and zuluCrypt reports:

     ./cik luks 264  tiufvtfbuybougougbtvtfgytfvytryfbyfvviytrf  cvol
    [ink@mtz ~]$ zuluCrypt-cli -b -d cvol
    device "cvol" is not a luks device

    can these 3 tests be explained? i am using cryptsetup 1.4.1



    zuluCypt code that check for keyslots as promised above:

    char * empty_slots( const char * device )
    {
        crypt_keyslot_info cki ;
        struct crypt_device * cd;
        int i ;
        int j ;
        int k ;
        char * slot ;

        if( is_luks( device ) == 1 )
            return NULL ;

        i = crypt_init( &cd,device ) ;

        if( i != 0 )
            return NULL ;

        i = crypt_load( cd, CRYPT_LUKS1, NULL ) ;

        if( i != 0 )
            return NULL ;

        k = crypt_keyslot_max( CRYPT_LUKS1 ) ;

        slot = ( char * ) malloc( sizeof( char ) * ( k + 1 ) ) ;

        for( j = 0 ; j < k ; j++){
            cki = crypt_keyslot_status(cd, j);
            switch ( cki ){
                case CRYPT_SLOT_INACTIVE :   slot[j] = '0' ; break ;
                case CRYPT_SLOT_ACTIVE :     slot[j] = '1' ; break ;
                case CRYPT_SLOT_INVALID :    slot[j] = '2' ; break ;
                case CRYPT_SLOT_ACTIVE_LAST: slot[j] = '3' ; break
;
            }
        }
        slot[j] = '\0' ;
        crypt_free( cd );
        return slot ;
    }

[-- Attachment #2: Type: text/html, Size: 3532 bytes --]

Re: [dm-crypt] about invalid key slots

[Milan Broz]

On 04/02/2012 12:10 PM, .. ink .. wrote:
> on-disk-format.pdf says key-slot-2 is at offset 256, luksDump says its at 264. Is this expected?

Seems I sent that just private - so here: 256 is offset in bytes of keyslot info struct
in LUKS header, 264 is value (stored in this info struct) describing offset of keyslot area
on disk, in sectors.

IOW two separate things.

Milan

Re: [dm-crypt] about invalid key slots

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

> Please do not try to parse physical header structure outside of cryptsetup,
> header can change in future (new version) etc. libcryptsetup should
> be wrapper over these internals.
>
> was not going to. I was puzzled by the "CRYPT_SLOT_INVALID" entry in the
"crypt_keyslot_info" structure when i looked at the API couple of months
ago but i never asked about it. All these posts about invalid key slots
just made me relooked the puzzle and ask about it.


CRYPT_SLOT_INVALID is returned if e.g. slot # is above limit, not
> if header is corrupted.
>
> Milan
>
ok,i guess this solves my confusion.The same term is used for two different
things. crypt_load() will fail when the header is corrupt and my code will
just return "its not luks device",i can live with this or come up with
something within the API. Will not even attempt to go over or under the API.

An invalid key slot due to a corrupted header is a serious problem and
everybody seem to be reporting on this. How serious is the
"CRYPT_SLOT_INVALID" status on a key slot as reported by
crypt_keyslot_status()?

Since my code goes further enoght to see this one( crypt_load() pass ) and
can open volumes if key is on another slot,it seem useful to inform my
users of this status but not confuse them with the more serious one.

This is the output i made the tool generate when it encounters
"CRYPT_SLOT_INVALID"

[ink@mtz ~]$ zuluCrypt-cli -O -d cvol -p xxx
SUCCESS: Volume opened successfully
WARNING: the volume has atleast one corrupted key slot

does "corrupt" differ enough from "invalid"? any suggestion on the term to
use to describe "CRYPT_SLOT_INVALID" status?

[-- Attachment #2: Type: text/html, Size: 2151 bytes --]

Re: [dm-crypt] about invalid key slots

[Milan Broz]

On 04/02/2012 02:14 PM, .. ink .. wrote:
> 
> Please do not try to parse physical header structure outside of
> cryptsetup, header can change in future (new version) etc.
> libcryptsetup should be wrapper over these internals.
> 
> was not going to. I was puzzled by the "CRYPT_SLOT_INVALID" entry in
> the "crypt_keyslot_info" structure when i looked at the API couple of
> months ago but i never asked about it. All these posts about invalid
> key slots just made me relooked the puzzle and ask about it.

Well, then we should add better documentation...

> CRYPT_SLOT_INVALID is returned if e.g. slot # is above limit, not if
> header is corrupted.

> An invalid key slot due to a corrupted header is a serious problem
> and everybody seem to be reporting on this. How serious is the
> "CRYPT_SLOT_INVALID" status on a key slot as reported by
> crypt_keyslot_status()?

Corrupted LUKS header is very rare.

crypt_keyslot_status() returns currently CRYPT_SLOT_INVALID 

- if you run it over crypto context which does not support keyslots
(non-LUKS)

- if keyslot number is out of limits for the crypt type

- for LUKS, if keyslot status is in some unexpected state
(either not active or active) - well, this one can be caused by
partial header corruption.
(This check should be perhaps in crypt_load as well...
Anyway, slot with invalid status is the same like non-active slot
- cannot be used for unlocking.

> Since my code goes further enoght to see this one( crypt_load() pass
> ) and can open volumes if key is on another slot,it seem useful to
> inform my users of this status but not confuse them with the more
> serious one.

Crypt_load checks only if keyslot area is in some limits (does not
overlap with user data). So some minor corruptuions
can be undetected by crypt_load but status returns invalid...
Nothing is perfect :)

(I am thinking to export current repair code, so it can suggest
to user to run something like "cryptsetup repair <device>" if
there is some invalid values... It is not 100% but should help.)

Milan

Re: [dm-crypt] about invalid key slots

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

forwarding the email to the mailing list because my initial reply was  sent
privately( again,should pay more attention to where i send my emails :-) )
On Mon, Apr 2, 2012 at 2:15 PM, .. ink .. <mhogomchungu@gmail.com> wrote:

>
> - for LUKS, if keyslot status is in some unexpected state
>> (either not active or active) - well, this one can be caused by
>> partial header corruption.
>> (This check should be perhaps in crypt_load as well...
>> Anyway, slot with invalid status is the same like non-active slot
>> - cannot be used for unlocking.
>>
>> Milan
>>
> this part perfectly explains what i was observing.
>
> did another test:
>
> [ink@mtz ~]$ ./test luks1 256 yyyyyyyyyyyyyyyyyyyy
> [ink@mtz ~]$ zuluCrypt-cli -b -d luks1
> 12100000
>
> [ink@mtz ~]$./test luks1 256
> yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
> [ink@mtz ~]$ zuluCrypt-cli -b -d luks1
> device "luks1" is not a luks device
>
> the test program is at the end of the email.
>
> so currently,it is possible to corrupt the header in a way that
> crypt_load()  will not detect the corruption but but crypt_keyslot_status()
> will if the minor corruption is in a key slot it run on.
>
> This explains why i couldnt seem to trigger the invalid key error that was
> being reported.My corruption wasnt big enough.
>
> the luks disk specification says key slot field in the header takes 48
> units of length(48 bytes??) and is of data type "key slot". what is data
> type "key slot"? i am asking purest as a matter of couriosity and not
> because i want to parse the header in any shape or form.
>
>
> int main( int argc,char * argv[] )
> {
>     const char * path = argv[1];
>     size_t offset = atoi(argv[2]);
>     const char * data = argv[3];
>     size_t len = strlen(data);
>
>     int i = open(path,O_WRONLY);
>     lseek(i,offset,SEEK_SET);
>     write(i,data,len);
>     close(i);
>     return 0 ;
> }
>
>

[-- Attachment #2: Type: text/html, Size: 2448 bytes --]