Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #196072 > unrolled thread
| Started by | Robert Dodier <robert.dodier@gmail.com> |
|---|---|
| First post | 2018-05-25 21:00 +0200 |
| Last post | 2018-05-27 19:40 +0200 |
| Articles | 14 — 8 participants |
Back to article view | Back to linux.debian.user
Possible for full-disk encryption to encrypt /boot as well? Robert Dodier <robert.dodier@gmail.com> - 2018-05-25 21:00 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-25 21:50 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Robert Dodier <robert.dodier@gmail.com> - 2018-05-26 02:40 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Abdullah Ramazanoğlu <ar018@yahoo.com> - 2018-05-26 03:20 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-05-26 10:20 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Robert Dodier <robert.dodier@gmail.com> - 2018-05-26 18:00 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Curt <curty@free.fr> - 2018-05-26 19:00 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? David Wright <deblis@lionunicorn.co.uk> - 2018-05-26 21:10 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Celejar <celejar@gmail.com> - 2018-05-25 22:00 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? David Christensen <dpchrist@holgerdanske.com> - 2018-05-27 02:30 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Paul Johnson <baloo@ursamundi.org> - 2018-05-27 06:20 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? David Christensen <dpchrist@holgerdanske.com> - 2018-05-27 07:50 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? Paul Johnson <baloo@ursamundi.org> - 2018-05-27 08:50 +0200
Re: Possible for full-disk encryption to encrypt /boot as well? David Christensen <dpchrist@holgerdanske.com> - 2018-05-27 19:40 +0200
| From | Robert Dodier <robert.dodier@gmail.com> |
|---|---|
| Date | 2018-05-25 21:00 +0200 |
| Subject | Possible for full-disk encryption to encrypt /boot as well? |
| Message-ID | <vTq6t-1wc-1@gated-at.bofh.it> |
Hello, I'm working with Debian 9. I gather that there is a full-disk encryption option for the standard Debian installer, which, as I understand it, does not include encrypting /boot. (The system I'm working on wasn't encrypted when it was installed, so the system would have to be reinstalled, that's OK.) The only description of encrypting /boot that I was able to find is: https://gist.github.com/ppmathis/ccfbfce86484dc61834c1f17568d7b80 I wonder if there is any simpler approach. Is it possible that, perhaps, other Linux distributions have an option for encrypting /boot? I wasn't able to find any information about that. It's OK if the answer to these questions is no, I'm just trying to sort out the feasibility of encrypting /boot. Thanks in advance for any info, I appreciate it very much. Robert Dodier
[toc] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-05-25 21:50 +0200 |
| Message-ID | <vTqSS-21j-7@gated-at.bofh.it> |
| In reply to | #196072 |
Le 25/05/2018 à 20:55, Robert Dodier a écrit : > > I'm working with Debian 9. I gather that there is a full-disk > encryption option for the standard Debian installer, which, as I > understand it, does not include encrypting /boot. (The system I'm > working on wasn't encrypted when it was installed, so the system would > have to be reinstalled, that's OK.) > > The only description of encrypting /boot that I was able to find is: > https://gist.github.com/ppmathis/ccfbfce86484dc61834c1f17568d7b80 > I wonder if there is any simpler approach. > > Is it possible that, perhaps, other Linux distributions have an option > for encrypting /boot? I wasn't able to find any information about > that. I have managed to use the standard Debian installer to install with encrypted /boot (either including or excluding /boot/grub) but it was far from straightforward. I had to perform some steps with the embedded shell. Also, the installer insists that /boot should not be encrypted. Jessie's installer was quite easy to trick (just put /boot on LVM on encrypted volume). But the trick did not work with Stretch's installer, so I had to create a dummy /boot. > It's OK if the answer to these questions is no, I'm just trying to > sort out the feasibility of encrypting /boot. Why do you want an encrypted /boot ? It does not usually contain any sensitive information. Encrypted /boot is not tamper-proof unless extra steps are taken to protect the first stage boot such as booting from write-protected, authenticated or removable media.
[toc] | [prev] | [next] | [standalone]
| From | Robert Dodier <robert.dodier@gmail.com> |
|---|---|
| Date | 2018-05-26 02:40 +0200 |
| Message-ID | <vTvpv-4HK-3@gated-at.bofh.it> |
| In reply to | #196074 |
On Fri, May 25, 2018 at 12:44 PM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > Why do you want an encrypted /boot ? It does not usually contain any > sensitive information. Encrypted /boot is not tamper-proof unless extra > steps are taken to protect the first stage boot such as booting from > write-protected, authenticated or removable media. Thanks for your reply. I am working for an organization which requires computers to be full disk encrypted. They support Windows, but if I want to run Linux, I'm on my own. So to be precise I need something which is strictly comparable to whatever is provided by Symantec full disk encryption for Windows. If I can achieve that, I'll be in business. It may be true that encrypted /boot is not really relevant, but I don't want to try to argue with tech support staff that a system with unencrypted /boot is close enough. I feel like it needs to be all or nothing in order for me to press this issue with them. Thank you very much for your comments, and all the best. Robert Dodier
[toc] | [prev] | [next] | [standalone]
| From | Abdullah Ramazanoğlu <ar018@yahoo.com> |
|---|---|
| Date | 2018-05-26 03:20 +0200 |
| Message-ID | <vTw2e-59f-3@gated-at.bofh.it> |
| In reply to | #196078 |
On Fri, 25 May 2018 17:33:54 -0700 Robert Dodier said: > It may be true that encrypted /boot is not really relevant, but I > don't want to try to argue with tech support staff that a system with > unencrypted /boot is close enough. I feel like it needs to be all or > nothing in order for me to press this issue with them. Or you can offer them a setup more than full-disk encryption: Put the (unencrypted) /boot on a USB stick, and the rest of the system on fully encrypted disk. * With full disk encryption (Linux or Windows) all one needs is the pass-phrase. * With /boot on USB stick, one needs both the key (the stick) and the pass-phrase. At any rate, it is technically "full disk encryption" - there's nothing unencrypted on hard drive, is there? :) Regards -- Abdullah Ramazanoğlu
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-05-26 10:20 +0200 |
| Message-ID | <vTCAF-OH-5@gated-at.bofh.it> |
| In reply to | #196078 |
Le 26/05/2018 à 02:33, Robert Dodier a écrit : > On Fri, May 25, 2018 at 12:44 PM, Pascal Hambourg > <pascal@plouf.fr.eu.org> wrote: > >> Why do you want an encrypted /boot ? It does not usually contain any >> sensitive information. Encrypted /boot is not tamper-proof unless extra >> steps are taken to protect the first stage boot such as booting from >> write-protected, authenticated or removable media. > > Thanks for your reply. I am working for an organization which requires > computers to be full disk encrypted. They support Windows, but if I > want to run Linux, I'm on my own. So to be precise I need something > which is strictly comparable to whatever is provided by Symantec full > disk encryption for Windows. If I can achieve that, I'll be in > business. I don't know how Symantec's "full" disk encryption works, but AFAIK a boot disk cannot be fully encrypted, unless the platform firmware can handle the encryption format. IIUC Coreboot or Libreboot may do it. Otherwise the bootstrap code must not be encrypted so that the platform firmware can load and run it. Even if /boot is encrypted, the first stage of the boot loader (GRUB boot image and core image if using BIOS/legacy boot, the EFI partition if using EFI boot) cannot not be encrypted.
[toc] | [prev] | [next] | [standalone]
| From | Robert Dodier <robert.dodier@gmail.com> |
|---|---|
| Date | 2018-05-26 18:00 +0200 |
| Message-ID | <vTJLP-5b0-1@gated-at.bofh.it> |
| In reply to | #196086 |
On Sat, May 26, 2018 at 1:16 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > I don't know how Symantec's "full" disk encryption works, but AFAIK a boot > disk cannot be fully encrypted, Yes, this is an important question -- what, exactly, is provided by Symantec here, so that I can look for something to do the same for Linux. But not surprisingly I haven't been able to find a careful description -- so far all I have found is some marketing material. I will keep looking. best, Robert Dodier
[toc] | [prev] | [next] | [standalone]
| From | Curt <curty@free.fr> |
|---|---|
| Date | 2018-05-26 19:00 +0200 |
| Message-ID | <vTKHU-5Le-5@gated-at.bofh.it> |
| In reply to | #196094 |
On 2018-05-26, Robert Dodier <robert.dodier@gmail.com> wrote: > On Sat, May 26, 2018 at 1:16 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > >> I don't know how Symantec's "full" disk encryption works, but AFAIK a boot >> disk cannot be fully encrypted, > > Yes, this is an important question -- what, exactly, is provided by > Symantec here, so that I can look for something to do the same for > Linux. But not surprisingly I haven't been able to find a careful > description -- so far all I have found is some marketing material. I > will keep looking. They seem to be saying the boot loader is decrypted prior to the point at which it begins execution (a "pre-boot environment" is installed that prompts the user for pass phrase, etc.) https://www.symantec.com/content/en/us/enterprise/white_papers/b-pgp_how_wholedisk_encryption_works_WP_21158817.en-us.pdf > best, > Robert Dodier > > --
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2018-05-26 21:10 +0200 |
| Message-ID | <vTMJH-7ej-7@gated-at.bofh.it> |
| In reply to | #196096 |
On Sat 26 May 2018 at 16:51:56 (+0000), Curt wrote: > On 2018-05-26, Robert Dodier <robert.dodier@gmail.com> wrote: > > On Sat, May 26, 2018 at 1:16 AM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > > > >> I don't know how Symantec's "full" disk encryption works, but AFAIK a boot > >> disk cannot be fully encrypted, > > > > Yes, this is an important question -- what, exactly, is provided by > > Symantec here, so that I can look for something to do the same for > > Linux. But not surprisingly I haven't been able to find a careful > > description -- so far all I have found is some marketing material. I > > will keep looking. > > They seem to be saying the boot loader is decrypted prior to the point > at which it begins execution (a "pre-boot environment" is installed that > prompts the user for pass phrase, etc.) > > https://www.symantec.com/content/en/us/enterprise/white_papers/b-pgp_how_wholedisk_encryption_works_WP_21158817.en-us.pdf which says: "A boot sequence executes during the startup process of Microsoft® Windows, Apple Mac OS X, or Linux® operating systems. The boot system is the initial set of operations that the computer performs when it is switched on. A boot loader (or a bootstrap loader) is a short computer program that loads the main operating system for the computer. The boot loader first looks at a boot record or partition table, which is the logical area “zero” (or starting point) of the disk drive. Whole disk encryption modifies the zero point area of the drive. A computer protected with Whole Disk Encryption presents a modified “pre-boot” environment (Figure 1) to the user." To me, that implies that what they call the "boot[strap] loader" is the unencrypted firmware, and that the "logical area “zero” (or starting point)" is the MBR. It says that the MBR has been "modified", but I don't see where it says that the boot loader has been, nor how any of the early code can have been *encrypted* until enough has been executed to read and act upon a passphrase. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Celejar <celejar@gmail.com> |
|---|---|
| Date | 2018-05-25 22:00 +0200 |
| Message-ID | <vTr2y-24A-13@gated-at.bofh.it> |
| In reply to | #196072 |
On Fri, 25 May 2018 11:55:34 -0700 Robert Dodier <robert.dodier@gmail.com> wrote: > Hello, > > I'm working with Debian 9. I gather that there is a full-disk > encryption option for the standard Debian installer, which, as I > understand it, does not include encrypting /boot. (The system I'm > working on wasn't encrypted when it was installed, so the system would > have to be reinstalled, that's OK.) > > The only description of encrypting /boot that I was able to find is: > https://gist.github.com/ppmathis/ccfbfce86484dc61834c1f17568d7b80 > I wonder if there is any simpler approach. > > Is it possible that, perhaps, other Linux distributions have an option > for encrypting /boot? I wasn't able to find any information about > that. https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29 Celejar
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2018-05-27 02:30 +0200 |
| Message-ID | <vTRJn-1KU-1@gated-at.bofh.it> |
| In reply to | #196072 |
On 05/25/18 11:55, Robert Dodier wrote: > I'm working with Debian 9. I gather that there is a full-disk > encryption option for the standard Debian installer, which, as I > understand it, does not include encrypting /boot. ... On 05/25/18 17:33, Robert Dodier wrote: > I am working for an organization which requires > computers to be full disk encrypted. Have you considered a self-encrypting drive (self-encrypting drive)? https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption This approach protects everything on the drive, including /boot. Understand that your computer must have compatible firmware. David
[toc] | [prev] | [next] | [standalone]
| From | Paul Johnson <baloo@ursamundi.org> |
|---|---|
| Date | 2018-05-27 06:20 +0200 |
| Message-ID | <vTVjX-43X-1@gated-at.bofh.it> |
| In reply to | #196116 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, May 26, 2018 at 7:21 PM, David Christensen < dpchrist@holgerdanske.com> wrote: > On 05/25/18 11:55, Robert Dodier wrote: > >> I'm working with Debian 9. I gather that there is a full-disk >> encryption option for the standard Debian installer, which, as I >> understand it, does not include encrypting /boot. ... >> > > On 05/25/18 17:33, Robert Dodier wrote: > > I am working for an organization which requires > > computers to be full disk encrypted. > > Have you considered a self-encrypting drive (self-encrypting drive)? > > https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption > > > This approach protects everything on the drive, including /boot. > > > Understand that your computer must have compatible firmware. I'm 99.99% sure (like Dove soap sure) that Symantec full disk encryption doesn't work this way because I'm just as sure that none of the Dell models I've ever worked with have this hardware capability.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2018-05-27 07:50 +0200 |
| Message-ID | <vTWJ3-4YR-1@gated-at.bofh.it> |
| In reply to | #196120 |
On 05/26/18 21:16, Paul Johnson wrote: > On Sat, May 26, 2018 at 7:21 PM, David Christensen >> Have you considered a self-encrypting drive ... > > I'm 99.99% sure (like Dove soap sure) that Symantec full disk > encryption doesn't work this way because I'm just as sure that none > of the Dell models I've ever worked with have this hardware > capability. I have tested Intel 520 Series SSD's with self-encryption in two Dell laptop models: - They do not work in Dell Inspiron E1505's (~2007, Core Duo). - They do work in Dell Latitude E6520's (2011~2012, Sandy Bridge). David
[toc] | [prev] | [next] | [standalone]
| From | Paul Johnson <baloo@ursamundi.org> |
|---|---|
| Date | 2018-05-27 08:50 +0200 |
| Message-ID | <vTXF8-5z6-1@gated-at.bofh.it> |
| In reply to | #196121 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, May 27, 2018 at 12:43 AM, David Christensen < dpchrist@holgerdanske.com> wrote: > On 05/26/18 21:16, Paul Johnson wrote: > >> On Sat, May 26, 2018 at 7:21 PM, David Christensen >> >>> Have you considered a self-encrypting drive ... >>> >> >> I'm 99.99% sure (like Dove soap sure) that Symantec full disk >> encryption doesn't work this way because I'm just as sure that none >> of the Dell models I've ever worked with have this hardware >> capability. >> > > I have tested Intel 520 Series SSD's with self-encryption in two Dell > laptop models: > > - They do not work in Dell Inspiron E1505's (~2007, Core Duo). > > - They do work in Dell Latitude E6520's (2011~2012, Sandy Bridge). Right, but is the basic system unencrypted or not? I very, very, very highly suspect not, since it seems fairly obviously to me (given that all the Dell hardware stuff has finished and it's handed off to whatever is on the boot device) it's handing off to encrypted software off the hard drive to bootstrap the rest by the time anything Symantec gets involved with.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2018-05-27 19:40 +0200 |
| Message-ID | <vU7Oa-3vV-11@gated-at.bofh.it> |
| In reply to | #196122 |
On 05/26/18 23:40, Paul Johnson wrote: > On Sun, May 27, 2018 at 12:43 AM, David Christensen < > dpchrist@holgerdanske.com> wrote: > >> On 05/26/18 21:16, Paul Johnson wrote: >> >>> On Sat, May 26, 2018 at 7:21 PM, David Christensen >>> >>>> Have you considered a self-encrypting drive ... >>>> >>> >>> I'm 99.99% sure (like Dove soap sure) that Symantec full disk >>> encryption doesn't work this way because I'm just as sure that none >>> of the Dell models I've ever worked with have this hardware >>> capability. >>> >> >> I have tested Intel 520 Series SSD's with self-encryption in two Dell >> laptop models: >> >> - They do not work in Dell Inspiron E1505's (~2007, Core Duo). >> >> - They do work in Dell Latitude E6520's (2011~2012, Sandy Bridge). > > > Right, but is the basic system unencrypted or not? I very, very, very > highly suspect not, since it seems fairly obviously to me (given that all > the Dell hardware stuff has finished and it's handed off to whatever is on > the boot device) it's handing off to encrypted software off the hard drive > to bootstrap the rest by the time anything Symantec gets involved with. > AFAIK self-encrypting drives (SED) have hardware encryption/ decryption engines (ASIC's) built into the on-board microcontroller. When the system boots, there is a protocol for the motherboard firmware to display a prompt on the console for the SED passphrase, which is then passed to the SED. If the passphrase is correct, the SED then encrypts/ decrypts data writes/ reads transparently (e.g. the SED acts like an unencrypted drive). If the passphrase is wrong, the SED will refuse to write/ read data, because it cannot encrypt/ decrypt without the passphrase. If someone pulls the platters or memory chips out of the SED, puts them into a test jig, and reads the magnetic bubbles/ transistors, they will obtain ciphertext. They must know the encryption algorithm, passphrase, and other pieces of information (nonces, etc.) to decrypt the ciphertext and obtain the plaintext. Once the SED has been unlocked, the administrator can build additional layers of hardware and/or software encryption on top. FreeOTFE and dm-crypt/LUKS are examples of software encryption. I believe BitLocker is also software encryption, but allows keys to be stored in a Trusted Platform Module (TPM). I am not familiar with Symantec encryption products. David
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.user
csiph-web