[dm-crypt] Reading the serial number of an HDD encrypted with dm-crypt

[dm-crypt] Reading the serial number of an HDD encrypted with dm-crypt

[Rehan Iftikhar]

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

Hello

if I plug in an HDD that is encrypted with dm-crypt should I be able to use
tools like lsblk or udevadm to get the HDD's manufacturers serial number
*before* I decrypt the device?

-- 
-Rehan

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

Re: [dm-crypt] Reading the serial number of an HDD encrypted with dm-crypt

[Daniel P. Berrange]

On Fri, Jun 23, 2017 at 07:01:28AM -0700, Rehan Iftikhar wrote:
> Hello
> 
> if I plug in an HDD that is encrypted with dm-crypt should I be able to use
> tools like lsblk or udevadm to get the HDD's manufacturers serial number
> *before* I decrypt the device?

Yes, you can easily get the hardware serial number. LUKS only protects
the disk sectors - the serial number is accessed via SCSI commands and
so not affected by disk sector encryption.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [dm-crypt] Reading the serial number of an HDD encrypted with dm-crypt

[Michael Kjörling]

On 23 Jun 2017 07:01 -0700, from rehan.iftikhar@gmail.com (Rehan Iftikhar):
> if I plug in an HDD that is encrypted with dm-crypt should I be able to use
> tools like lsblk or udevadm to get the HDD's manufacturers serial number
> *before* I decrypt the device?

Yes, because the serial number of the hard disk drive is a property of
the physical device itself, whereas dm-crypt (including LUKS) only
affects the data that is stored on the device.

What you should not (and absent mistakes, will not) be able to get is
any identifying information about the encrypted _file system_, such as
the file system type or GUID. Absent a successful dm-crypt mapping,
the encrypted data should be completely opaque to an observer;
however, an observer can look at LUKS metadata and determine that the
data is a LUKS container, along with basic cryptographic settings for
it (cipher, master key size, etc.).

To see roughly what can be derived from an unmapped LUKS device, you
can use `cryptsetup luksDump` without first mapping the device. Below
is an example from one of my drives, when unmapped. Plain dm-crypt has
no on-disk metadata (keeping track of settings is your responsibility
as the system administrator in that case) so won't even tell you this
much.

    LUKS header information for /dev/sdX

    Version:        1
    Cipher name:    aes
    Cipher mode:    xts-plain64
    Hash spec:      sha512
    Payload offset: 4096
    MK bits:        512
    MK digest:      xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
    MK salt:        xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
                    xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
    MK iterations:  1383750
    UUID:           3d9a73c1-75f5-4d0b-96e2-a6c78590fa3e

    Key Slot 0: ENABLED
            Iterations:             5562509
            Salt:                   xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
                                    xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
            Key material offset:    8
            AF stripes:             4000
    Key Slot 1: DISABLED
    Key Slot 2: DISABLED
    Key Slot 3: DISABLED
    Key Slot 4: DISABLED
    Key Slot 5: DISABLED
    Key Slot 6: DISABLED
    Key Slot 7: DISABLED

I have masked the master key digest and salt, and the key slot salt,
above, even though those aren't _particularly sensitive_; they are
just unnecessary to have publicly archived for no good reason.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)