encrypted filesystems - Linux

This is a discussion on encrypted filesystems - Linux ; I'm searching for information on encrypted filesystems for Linux. I have a new 500GB external hard drive and want to secure the data in case the hard drive gets up and walks away. All I could find was a HOWTO ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 30

Thread: encrypted filesystems

  1. encrypted filesystems

    I'm searching for information on encrypted filesystems for Linux. I have a
    new 500GB external hard drive and want to secure the data in case the hard
    drive gets up and walks away.
    All I could find was a HOWTO for an old 2.2 kernel. I expect major changes
    have occurred to this part of the kernel, given how most of us are buying
    small laptops and external drives which are much more easily stolen than
    the big desktop boxes.
    I'm looking for some way to encrypt block devices from kernel-space. Block
    devices are much more secure than just encrypting the files. Also,
    kernel-space encryption will help me avoid the 2-4x performance hit
    encrypting in user-space would cause. Does anyone know of a more recent
    method for encrypting filesystems within the kernel than the 2.2 kernel
    HOWTO describes?


  2. Re: encrypted filesystems

    Duane Evenson wrote:
    > I'm searching for information on encrypted filesystems for Linux. I have a
    > new 500GB external hard drive and want to secure the data in case the hard
    > drive gets up and walks away.
    > All I could find was a HOWTO for an old 2.2 kernel. I expect major changes
    > have occurred to this part of the kernel, given how most of us are buying
    > small laptops and external drives which are much more easily stolen than
    > the big desktop boxes.
    > I'm looking for some way to encrypt block devices from kernel-space. Block
    > devices are much more secure than just encrypting the files. Also,
    > kernel-space encryption will help me avoid the 2-4x performance hit
    > encrypting in user-space would cause. Does anyone know of a more recent
    > method for encrypting filesystems within the kernel than the 2.2 kernel
    > HOWTO describes?
    >


    The device mapper might be the answer.

    Google for dm-crypt.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  3. Re: encrypted filesystems

    Duane Evenson burped up warm pablum in
    newsan.2008.08.14.18.59.49.830137@invalid.address:

    > I'm searching for information on encrypted filesystems for Linux. I
    > have a new 500GB external hard drive and want to secure the data in
    > case the hard drive gets up and walks away.
    > All I could find was a HOWTO for an old 2.2 kernel. I expect major
    > changes have occurred to this part of the kernel, given how most of us
    > are buying small laptops and external drives which are much more
    > easily stolen than the big desktop boxes.
    > I'm looking for some way to encrypt block devices from kernel-space.
    > Block devices are much more secure than just encrypting the files.
    > Also, kernel-space encryption will help me avoid the 2-4x performance
    > hit encrypting in user-space would cause. Does anyone know of a more
    > recent method for encrypting filesystems within the kernel than the
    > 2.2 kernel HOWTO describes?


    I think that truecrypt 6 with Plausible Deniability and Hidden Volumes is your best bet.

    --
    Tris Orendorff
    [ Anyone naming their child should spend a few minutes checking rhyming slang and dodgy sounding names. Brad and Angelina failed to do this when naming their kid Shiloh Pitt. At some point, someone at school is going to spoonerise her name.
    Craig Stark ]


  4. Re: encrypted filesystems

    On Aug 14, 12:00*pm, Duane Evenson wrote:

    > I'm looking for some way to encrypt block devices from kernel-space.


    That would be an encrypted block device, not really an encrypted file
    system.

    > Block
    > devices are much more secure than just encrypting the files.


    Quite the reverse, encrypting the files is, at least in most cases,
    much more secure. There are a large variety of encrypted block device
    attacks that are impossible to launch against an encrypted file
    system.

    For example, most encrypted block device implementations suffer from
    the following vulnerability:

    1) A company gets 100 identical laptops.
    2) Block device encryption is installed on each laptop in place.
    3) I get a laptop and determine which block contains the data for a
    critical security configuration file that affects its secure network.
    Maybe it's the equivalent of a 'hosts.deny' file.
    4) I get your laptop, corrupt that block randomly, and then leave the
    laptop where you found it.
    5) You turn the laptop on and log into it, leaving it running without
    the correct security configuration.

    DS

  5. Re: encrypted filesystems

    In article
    ,
    David Schwartz wrote:
    > Quite the reverse, encrypting the files is, at least in most cases,
    > much more secure. There are a large variety of encrypted block device
    > attacks that are impossible to launch against an encrypted file
    > system.
    >
    > For example, most encrypted block device implementations suffer from
    > the following vulnerability:
    >
    > 1) A company gets 100 identical laptops.
    > 2) Block device encryption is installed on each laptop in place.
    > 3) I get a laptop and determine which block contains the data for a
    > critical security configuration file that affects its secure network.
    > Maybe it's the equivalent of a 'hosts.deny' file.
    > 4) I get your laptop, corrupt that block randomly, and then leave the
    > laptop where you found it.
    > 5) You turn the laptop on and log into it, leaving it running without
    > the correct security configuration.


    You could do the same thing if the file was encrypted rather than the
    block device being encrypted, so I don't see how that example supports
    your point.

    --
    --Tim Smith

  6. Re: encrypted filesystems

    Tim Smith wrote:
    > In article
    > ,
    > David Schwartz wrote:
    >
    >>Quite the reverse, encrypting the files is, at least in most cases,
    >>much more secure. There are a large variety of encrypted block device
    >>attacks that are impossible to launch against an encrypted file
    >>system.
    >>
    >>For example, most encrypted block device implementations suffer from
    >>the following vulnerability:
    >>
    >>1) A company gets 100 identical laptops.
    >>2) Block device encryption is installed on each laptop in place.
    >>3) I get a laptop and determine which block contains the data for a
    >>critical security configuration file that affects its secure network.
    >>Maybe it's the equivalent of a 'hosts.deny' file.
    >>4) I get your laptop, corrupt that block randomly, and then leave the
    >>laptop where you found it.
    >>5) You turn the laptop on and log into it, leaving it running without
    >>the correct security configuration.

    >
    >
    > You could do the same thing if the file was encrypted rather than the
    > block device being encrypted, so I don't see how that example supports
    > your point.



    An encrypted file system has some structure known to all,
    so it may be an easier target for a knonw-plaintext decryption
    attack.

    --

    Tauno Voipio
    tauno voipio (at) iki fi


  7. Re: encrypted filesystems

    On Fri, 15 Aug 2008 19:40:30 -0700 (PDT) David Schwartz wrote:
    | On Aug 14, 12:00?pm, Duane Evenson wrote:
    |
    |> I'm looking for some way to encrypt block devices from kernel-space.
    |
    | That would be an encrypted block device, not really an encrypted file
    | system.
    |
    |> Block
    |> devices are much more secure than just encrypting the files.
    |
    | Quite the reverse, encrypting the files is, at least in most cases,
    | much more secure. There are a large variety of encrypted block device
    | attacks that are impossible to launch against an encrypted file
    | system.
    |
    | For example, most encrypted block device implementations suffer from
    | the following vulnerability:
    |
    | 1) A company gets 100 identical laptops.
    | 2) Block device encryption is installed on each laptop in place.
    | 3) I get a laptop and determine which block contains the data for a
    | critical security configuration file that affects its secure network.
    | Maybe it's the equivalent of a 'hosts.deny' file.
    | 4) I get your laptop, corrupt that block randomly, and then leave the
    | laptop where you found it.
    | 5) You turn the laptop on and log into it, leaving it running without
    | the correct security configuration.

    That's not a failure of encryption. If you corrupt that block even on a
    non-encrypted filesystem, you can get the same effect. It's a failure of
    programming and configuration. It should check that the configuration is
    valid and complete, or refuse to enable access at all if not.

    So I assume your point is that this is a vulnerability that encryption is
    not able to prevent. It is, of course, wrong thinking when someone believes
    that adding encryption somehow protects against all attacks. Even SSH cannot
    protect against a DoS attack. I once had an attack against port 22 that caused
    my log space to fill up and I lost some other logs as a result. And I probably
    incurred some bandwidth loses as well.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  8. Re: encrypted filesystems

    On Aug 17, 9:42*am, Tauno Voipio wrote:

    > An encrypted file system has some structure known to all,
    > so it may be an easier target for a knonw-plaintext decryption
    > attack.


    So you're saying that if I used an encrypted block device, part of my
    protection is that nobody knows what file system I'm using? And that I
    had better keep secret the fact that I'm using, say, ext2 or ntfs,
    lest I compromise my security?

    DS

  9. Re: encrypted filesystems

    On Aug 16, 11:25*pm, Tim Smith
    wrote:

    > You could do the same thing if the file was encrypted rather than the
    > block device being encrypted, so I don't see how that example supports
    > your point.


    No, you can't, for two reasons:

    1) Encrypted filesystems don't encrypt in-place. So you can't have two
    file systems encrypted with a different key that keep their metadata
    in the same place.

    2) Encrypted filesystems include checksums so that modified data can
    be detected. Because encrypted block devices must make the encrypted
    data fit in the same space as the plaintext, there is no extra room
    for a checksum, so they cannot do this.

    So, no, you can't find the metadata in a encrypted file system, and
    even if you could, tampering with it would cause a detectable fatal
    error. Encrypted block devices, on the other hand, do store metadata
    in known places and cannot detect malicious data corruption.

    DS

  10. Re: encrypted filesystems

    On Aug 17, 12:58*pm, phil-news-nos...@ipal.net wrote:

    > That's not a failure of encryption.


    Yes, it is.

    > If you corrupt that block even on a
    > non-encrypted filesystem, you can get the same effect.


    Sure, but the reason you encrypt is to protect against just those
    things.

    >*It's a failure of
    > programming and configuration. *It should check that the configuration is
    > valid and complete, or refuse to enable access at all if not.


    It's the encryption scheme that should make sure the decrypted data
    matches the original encrypted data. If it can't do that, and cannot
    detect a failure, then it failed.

    > So I assume your point is that this is a vulnerability that encryption is
    > not able to prevent.


    This is precisely what encryption is supposed to prevent -- getting
    back data that is different from what you gave it.

    >*It is, of course, wrong thinking when someone believes
    > that adding encryption somehow protects against all attacks. *Even SSH cannot
    > protect against a DoS attack. *I once had an attack against port 22 that caused
    > my log space to fill up and I lost some other logs as a result. *And I probably
    > incurred some bandwidth loses as well.


    Yes, encryption should not prevent against all attacks, but it should
    protect against attacks where an attacker can modify my decrypted data
    so I think I encrypted something other than what I did in fact
    encrypt.

    DS

  11. Re: encrypted filesystems

    David Schwartz writes:

    > On Aug 16, 11:25*pm, Tim Smith
    > wrote:
    >
    >> You could do the same thing if the file was encrypted rather than the
    >> block device being encrypted, so I don't see how that example supports
    >> your point.

    >
    > No, you can't, for two reasons:
    >
    > 1) Encrypted filesystems don't encrypt in-place. So you can't have two
    > file systems encrypted with a different key that keep their metadata
    > in the same place.
    >
    > 2) Encrypted filesystems include checksums so that modified data can
    > be detected. Because encrypted block devices must make the encrypted
    > data fit in the same space as the plaintext, there is no extra room
    > for a checksum, so they cannot do this.


    Using a non-encrypted filesystem with checksums on an encrypted block
    device would achieve the same protection. ZFS... no, I won't start
    that discussion.

    --
    Måns Rullgård
    mans@mansr.com

  12. Re: encrypted filesystems

    David Schwartz wrote:
    > So, no, you can't find the metadata in a encrypted file system, and
    > even if you could, tampering with it would cause a detectable fatal
    > error. Encrypted block devices, on the other hand, do store metadata
    > in known places and cannot detect malicious data corruption.


    You should read the following paper:
    http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
    which shows that your assertions are not necessarily true, and the
    same for the conclusions you draw.

    >
    > DS


    --

    Michel TALON


  13. Re: encrypted filesystems

    David Schwartz writes:

    > On Aug 17, 12:58*pm, phil-news-nos...@ipal.net wrote:
    >
    >> That's not a failure of encryption.

    >
    > Yes, it is.
    >
    >> If you corrupt that block even on a
    >> non-encrypted filesystem, you can get the same effect.

    >
    > Sure, but the reason you encrypt is to protect against just those
    > things.
    >
    >>*It's a failure of
    >> programming and configuration. *It should check that the configuration is
    >> valid and complete, or refuse to enable access at all if not.

    >
    > It's the encryption scheme that should make sure the decrypted data
    > matches the original encrypted data. If it can't do that, and cannot
    > detect a failure, then it failed.
    >
    >> So I assume your point is that this is a vulnerability that encryption is
    >> not able to prevent.

    >
    > This is precisely what encryption is supposed to prevent -- getting
    > back data that is different from what you gave it.


    Encryption is for keeping data secret. Checksums are for verifying
    data integrity. They can each be used alone or combined, and cases
    can be imagined where any of the four possible combinations is
    preferred.

    --
    Måns Rullgård
    mans@mansr.com

  14. Re: encrypted filesystems

    On Aug 17, 2:11*pm, Måns Rullgård wrote:

    > Using a non-encrypted filesystem with checksums on an encrypted block
    > device would achieve the same protection.


    Against this specific vulnerability, but it's not the only one. It's
    just the one I picked as an example because it's the simplest to
    understand.

    DS

  15. Re: encrypted filesystems

    On Aug 17, 2:16*pm, Måns Rullgård wrote:

    > > This is precisely what encryption is supposed to prevent -- getting
    > > back data that is different from what you gave it.


    > Encryption is for keeping data secret.


    Right, and in this example, the encryption failed to keep the data
    secret by failing to protect the integrity of an access control
    mechanism.

    >*Checksums are for verifying
    > data integrity. *They can each be used alone or combined, and cases
    > can be imagined where any of the four possible combinations is
    > preferred.


    Right, but there is a huge risk when you don't combine them. Failure
    to ensure the integrity of access control information can result in
    failure to keep other information secret. An encryption solution that
    doesn't protect the integrity of data may wind up not keeping its
    contents secret either.

    Certainly it's a fair question whether or not the encryption is to
    blame or not. I would argue that if it doesn't at least mention this
    possible system vulnerability, then the encryption is at least
    partially to blame.

    DS

  16. Re: encrypted filesystems

    David Schwartz wrote:
    > On Aug 17, 9:42 am, Tauno Voipio wrote:
    >
    >
    >>An encrypted file system has some structure known to all,
    >>so it may be an easier target for a knonw-plaintext decryption
    >>attack.

    >
    >
    > So you're saying that if I used an encrypted block device, part of my
    > protection is that nobody knows what file system I'm using? And that I
    > had better keep secret the fact that I'm using, say, ext2 or ntfs,
    > lest I compromise my security?



    No - There are not too many supported filesystems
    on Linux. Each has an easily detectable pattern of
    administrative data which can be used as known
    plaintext.

    --

    Tauno Voipio
    tauno voipio (at) iki fi


  17. Re: encrypted filesystems

    On Aug 17, 11:13*pm, Tauno Voipio wrote:

    > No - There are not too many supported filesystems
    > on Linux. Each has an easily detectable pattern of
    > administrative data which can be used as known
    > plaintext.


    So this doesn't make any difference. If you use an encrypted volume,
    your file system still has an easily detectable pattern of
    administrative data. If you use an encrypted file system, your file
    system has an easily detectable pattern of administrative data.

    In fact, this weighs slightly in favor of encrypted file systems. If
    you use an encrypted block device with a regular file system, there
    will be no effort at securing the file system at all. All the security
    will come on top of a pattern of known administrative data. With an
    encrypted file system, there's at least a chance that the design of
    the file system itself and its meta data storage will have some
    leaning towards unpredictability and resistance against attacks based
    on knowledge of how metadata is stored.

    Filesystems like NTFS and ext2 do not make any attempt to provide this
    kind of security, nor should they. Laying a filesystem with no
    security design on top of an encypted volume means the two are not
    designed as a unit and basically slapped together. The interface may
    present vulnerabilities.

    The OP said, "Block devices are much more secure than just encrypting
    the files." Perhaps, but using an encrypted file system is better than
    attaching an insecure file system to an encrypted block device.

    DS

  18. Re: encrypted filesystems

    Hi,

    actually it was in the kernel 2.4-days when I tried, but I guess, it
    mostly works along the same lines.

    What I did then was an encrypted file which I mounted (with -o loop) as
    partition. Your hard drive should behave the same, but I would suggest
    you to check whether you want to encrypt the whole drive or rather just
    a part of it (say 2 GB) which you use for the sensitive data.

    Check back on the discussion about security versus safety ;-) My
    suggestion is to keep the amount of encrypted data low so at least some
    attacks on the key (the ones which need a lot of data to work) are harder.

    The howto was something like this:
    1. check if your kernel has the modules for encryption.
    2. create a file (dd if=/dev/null of=mycrptfs.file bs=1024)
    3. create an encrypted fs in it
    4. mount manually each time you want to use it, giving the password

    Though I cannot tell you the exact commands from memory, you should be
    able to find all the information you need. Especially as you said you
    found an old howto, check back if it lists the same procedure and give
    it a try! The stuff inside the kernel did change since 2.2, but the user
    interface did stay mostly the same ;-)

    Have fun!

    PS: I will not give you any warranty ;-)


  19. Re: encrypted filesystems

    On Mon, 18 Aug 2008 00:48:24 -0700 (PDT) David Schwartz wrote:

    | In fact, this weighs slightly in favor of encrypted file systems. If
    | you use an encrypted block device with a regular file system, there
    | will be no effort at securing the file system at all. All the security
    | will come on top of a pattern of known administrative data. With an
    | encrypted file system, there's at least a chance that the design of
    | the file system itself and its meta data storage will have some
    | leaning towards unpredictability and resistance against attacks based
    | on knowledge of how metadata is stored.

    Yes, to the extent that the file data itself does not have known patterns,
    you would be better off with an encrypted filesystem. OTOH, if you can
    handle the extra overhead, why not do both?

    Or maybe an encryption algorithm designed to address these vulnerabilities.


    | Filesystems like NTFS and ext2 do not make any attempt to provide this
    | kind of security, nor should they. Laying a filesystem with no
    | security design on top of an encypted volume means the two are not
    | designed as a unit and basically slapped together. The interface may
    | present vulnerabilities.

    That's the pluggability concept. Plug any filesystem onto any device.
    You could even do tape if you had a block driver that would work on tapes.
    So for encryption at the block device level, it's simply a plug-in wedge.
    That doesn't make it the best; just make it a simple way. And that might
    be the reason more people want it.


    | The OP said, "Block devices are much more secure than just encrypting
    | the files." Perhaps, but using an encrypted file system is better than
    | attaching an insecure file system to an encrypted block device.

    Maybe he was thinking in terms of the application doing the reading would
    do the decryption, and so on. Or at least do this in the stdio library.
    OTOH, encryption integrated into the filesystem implementation so that it
    encrypts only data blocks, but not meta blocks (or uses a different key for
    the meta block encryption) would seem to be a good approach.

    But in any case, once you computer has been out of your physical control
    for too long, it could already be compromised in whatever code has to be
    there in non-encrypted form to start it up. You enter your passphrase and
    the substituted code eventually sends it over the net to the perp, or such.

    I'm trying to think of some kind of public key authentication that could be
    used to verify there has been no compromise. I come up empty on that quest.

    Security is a matter of degree. But maybe the greatest degree of security
    is not what everyone needs.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  20. Re: encrypted filesystems

    On Sun, 17 Aug 2008 13:36:42 -0700 (PDT) David Schwartz wrote:

    | 2) Encrypted filesystems include checksums so that modified data can
    | be detected. Because encrypted block devices must make the encrypted
    | data fit in the same space as the plaintext, there is no extra room
    | for a checksum, so they cannot do this.

    Actually, they can. Some already do some kind of random hashing which is
    stored even N blocks to serve those N blocks. No reason the same cannot
    be done for a checksum.


    | So, no, you can't find the metadata in a encrypted file system, and
    | even if you could, tampering with it would cause a detectable fatal
    | error. Encrypted block devices, on the other hand, do store metadata
    | in known places and cannot detect malicious data corruption.

    This seems backwards.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

+ Reply to Thread
Page 1 of 2 1 2 LastLast