| View previous topic :: View next topic |
| Author |
Message |
JensK
n00b
Joined: 04 Aug 2005
Posts: 29
|
 Posted: Wed Jun 18, 2008 8:27 pm Post subject: Can't access LVM volumes inside dm-crypt partition |
 |
|
Hi folks,
I have a big problem: I have a hard disk (/dev/sdb) which I encrypted using cryptsetup. The key file is on a usb stick. Up to now, I had no problems with this configuration. Today I caught up on some updates and wanted to install a new kernel.
During shutdown I already saw same strange error messages saying that this or that file or directory was missing. After the reboot (I didn't even try too boot the new kernel), suddenly LVM didn't see any of my partitions inside the dm-crypt mapper file.
The encrypted disk was always mounted using
| Code: | | cryptsetup create -s 256 --key-file /path/to/keyfile crypthd /dev/sdb |
Then LVM would find the following volumes:
| Code: | /dev/cryptlvm/home
/dev/cryptlvm/opt
/dev/cryptlvm/tmp
/dev/cryptlvm/var |
However, this is not the case any more. I get the /dev/mapper/crypthd file, but when I look at its contents with hexdump -C, I see only random noise (lvmdiskscan finds nothing either).
I know the following things:
- The hard disk does not seem to have any errors (no noises, passes SMART health check, all SMART selftests without errors, no strange data loss).
- The key size 256 is correct (visible in the config files)
- The key file itself is correct (checked against backup copies)
- The last reboot about 60 days ago worked without problems
- There were no problems until I issued the "reboot" command today
So I get the impression that for some reason dm-crypt incorrectly encrypts my partition. Since most of my files are in the encrypted partition, I can't even look up which updates I installed since the last boot to find some clue.
Did anything change about the way cryptsetup works? Or which cipher it uses by default? |
|
| Back to top |
|
 |
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Wed Jun 18, 2008 9:11 pm Post subject: |
|
|
Whoa, that's ugly. 
You shouldn't rely on a default cipher but specify which one you're actually using. (That's one of the things that LUKS takes care for you, but unfortunately you're not using LUKS). If you suspect something changed about the way cryptsetup works, an old cryptsetup (for example from an old Linux LiveCD) may work. However you should really determine which cipher you are actually using and pass it as an option to cryptsetup.
The manpage mentions this for default settings:
| Code: | --cipher, -c
set cipher specification string. Usually, this is "aes-cbc-
plain". For pre-2.6.10 kernels, use "aes-plain" as they don’t
understand the new cipher spec strings. To use ESSIV, use "aes-
cbc-essiv:sha256". |
So maybe you want to try the ciphers mentioned in this example?
Of course you could just ditch the partition, move on to LUKS, and restore your backup... LUKS is much more comfortable in general, as it knows which cipher you are using, you can have more than one key / passphrase, even change them later on, and it will tell you if something is wrong with your kernel (cipher not supported) or keyfile (if it's unknown/invalid). |
|
| Back to top |
|
|
JensK
n00b
Joined: 04 Aug 2005
Posts: 29
|
| Posted: Wed Jun 18, 2008 9:45 pm Post subject: |
|
|
| frostschutz wrote: | | You shouldn't rely on a default cipher but specify which one you're actually using. |
If I only knew for sure! I set the whole thing up more than a year ago and I don't remember ever specifying one.
| Quote: | | If you suspect something changed about the way cryptsetup works, an old cryptsetup (for example from an old Linux LiveCD) may work. However you should really determine which cipher you are actually using and pass it as an option to cryptsetup. |
I tried it with an older System Rescue CD, without success. I tried "aes-cbc-plain", "aes-cbc-plain:sha256", "aes-cbc-essiv", "aes-cbc-essiv:sha256", "aes-ecb-plain", "blowfish-ecb-plain", etc. etc. (more or less everything I read in /proc/crypto), also without any success.
| Quote: | | Of course you could just ditch the partition, move on to LUKS, and restore your backup... |
Unfortunately, there are a number of files on the partition I didn't backup yet  |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Thu Jun 19, 2008 7:35 am Post subject: |
|
|
Well, if you tried all ciphers, and none of them worked, we just have to assume that the default cipher did not change (would be a strange change too after all, I don't think cryptsetup would break compatibility for no reason), and that the default cipher is the correct one, but the header of the partition got damaged anyhow. On a really low level, you can verify wether there is any useable data at all on the device, by issuing this command:
| Code: | | strings -n 32 /dev/yourdevice |
|
|
| Back to top |
|
|
JensK
n00b
Joined: 04 Aug 2005
Posts: 29
|
| Posted: Thu Jun 19, 2008 8:08 am Post subject: |
|
|
I already tried that. There are some traces of an earlier, non-encrypted partition. But since the data I am looking for has been encrypted, I wouldn't expect to find any strings in the clear on the raw device.
(of course, I have also been looking for any strings on /dev/mapper/crypthd, to look whether maybe just the LVM format has been damaged. But there's only entropy)
A hex dump of /dev/sdb looks like that:
| Code: | 00000000 00 00 00 00 48 00 00 00 00 00 00 00 63 35 63 34 |....H.......c5c4|
00000010 34 38 38 62 2d 62 35 64 65 2d 34 39 00 00 00 00 |488b-b5de-49....|
00000020 24 00 00 00 12 00 00 00 24 00 00 00 00 00 73 69 |$.......$.....si|
00000030 76 3a 73 68 61 32 35 36 00 00 00 00 00 00 00 00 |v:sha256........|
00000040 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00 |........sha1....|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20 |............... |
00000070 96 91 00 00 00 00 24 01 00 00 00 00 00 00 35 36 |......$.......56|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 01 00 00 12 01 c3 00 80 00 f4 bc d4 55 |........Ã...ô¼ÔU|
000000a0 14 24 c8 09 00 00 00 0a 63 35 63 34 35 38 38 62 |.$È.....c5c4588b|
000000b0 2d 62 35 64 65 2d 34 39 33 62 2d 38 38 30 65 2d |-b5de-493b-880e-|
000000c0 62 33 32 39 30 32 38 32 31 62 61 38 00 00 00 00 |b32902821ba8....|
000000d0 00 ac 71 f3 00 01 4c 0d b5 b4 5f 6f 5d fa da a9 |.¬qó..L.µ´_o]úÚ©|
000000e0 12 ea 28 c4 0b 61 3c b9 3e d1 70 20 9a c1 23 5e |.ê(Ä.a<¹>Ñp .Á#^|
000000f0 b5 df 60 21 e4 9b a2 90 00 00 00 08 00 00 0f a0 |µß`!ä.¢........ |
|
The start has some similarity to LUKS partitions. Retrospectively, I'm not even 100% sure whether I used LUKS or not. I made some (small) changes to some init scripts so they would create the mapper file first and then mount the LVM partitions (they only supported the other way round), and the init scripts (as far as I can tell) determined the correct call to cryptsetup, depending on whether cryptsetup would recognize a LUKS partition or not.
Coming to think of it:
- When using LUKS, and the header is defective, the whole partition is un-decryptable - right?
- When NOT using LUKS, and the header is defective, the following blocks should still be readable?
|
|
| Back to top |
|
|
likewhoa
l33t
Joined: 04 Oct 2006
Posts: 778
Location: Brooklyn, New York
|
| Posted: Thu Jun 19, 2008 9:22 am Post subject: |
|
|
| JensK wrote: |
- When using LUKS, and the header is defective, the whole partition is un-decryptable - right?
RIGHT unless you had a backup of your luks Header.
- When NOT using LUKS, and the header is defective, the following blocks should still be readable?
|
I would assume NO, but did you try running "cryptsetup isLuks /dev/<DEVICE>" on it? |
|
| Back to top |
|
|
JensK
n00b
Joined: 04 Aug 2005
Posts: 29
|
| Posted: Thu Jun 19, 2008 9:27 am Post subject: |
|
|
| Of course, but it says "/dev/sdb is not a LUKS partition"... |
|
| Back to top |
|
|
likewhoa
l33t
Joined: 04 Oct 2006
Posts: 778
Location: Brooklyn, New York
|
| Posted: Thu Jun 19, 2008 9:39 am Post subject: |
|
|
| JensK wrote: | | Of course, but it says "/dev/sdb is not a LUKS partition"... |
do you remember if you used an old version of cryptsetup to encrypt your partition before, I had issues with using <=cryptsetup-1.0.5
anyways, I hope you'll learn to make backups next time, I've lost data multiple times and I hate seeing others lose it also. |
|
| Back to top |
|
|
JensK
n00b
Joined: 04 Aug 2005
Posts: 29
|
| Posted: Thu Jun 19, 2008 9:42 am Post subject: |
|
|
| Well, I tried to decrypt it with the cryptsetup version on an older System Rescue CD, to no avail. |
|
| Back to top |
|
|
frostschutz
Advocate
Joined: 22 Feb 2005
Posts: 2977
Location: Germany
|
| Posted: Thu Jun 19, 2008 10:39 am Post subject: |
|
|
Yes, if the LUKS header is damaged (or rather, all key slots stored in the luks header), then there is no way to restore anything. Yes, if you were not using LUKS, but any block cipher, you can still decrypt any block as long as you know which block it was (for ciphers that take the block number indo consideration so that same block contents look different for every block), and as long as you have the key. However no matter how I look at it, the main problem here seems to be that you don't know anything, not the cipher you used and not which encryption method (LUKS or not). You should really know these things because it's so easy to lock yourself out with encryption. And you should have a backup in any case.
Without further knowledge, chances of rescuing anything off an encrypted disk is zero. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
