encrypted filesystems - Linux

This is a discussion on encrypted filesystems - Linux ; On Sun, 17 Aug 2008 13:38:43 -0700 (PDT) David Schwartz wrote: | On Aug 17, 12:58?pm, phil-news-nos...@ipal.net wrote: | |> That's not a failure of encryption. | | Yes, it is. No, it isn't. Encryption certainly helps a lot to ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: encrypted filesystems

  1. Re: encrypted filesystems

    On Sun, 17 Aug 2008 13:38:43 -0700 (PDT) David Schwartz wrote:
    | On Aug 17, 12:58?pm, phil-news-nos...@ipal.net wrote:
    |
    |> That's not a failure of encryption.
    |
    | Yes, it is.

    No, it isn't.

    Encryption certainly helps a lot to make sure that a means to check integrity
    and detect tampering is not spoofable. But you have to actually do the test.
    Too many applications don't do that.

    One way is to keep an SHA1 checksum of the file, either in the file in a place
    the application can handle, or as a separate file. The application needs to
    check that the configuration file's checksum matches. If it fails to, then it
    needs to carry out the intended policy for cases where a compromise is possible,
    such as leaving the network shut down.

    If the application does not do this test, do not blame the encryption.

    If you are paranoid enough, implement a block level ECC correction for the
    block device. If one block is corrupted, it can be corrected from redundant
    data. Certain RAID levels can already do this at device levels, so the
    knowledge is out there. Just tweak it a bit.

    But ECC correction is not part of encryption (and may even weaken it some).


    |> 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.

    No.

    If you want to protect against those things, you add a means to detect and
    possibly correct errors. And you MUST deploy the logic that carries out
    these tests. If you fail to deploy that logic somewhere (in the application
    or the filesystem or the block device driver, or a wedge somewhere between)
    then that's a management issue. Encryption just makes it harder for the
    perp to completely spoof your detection/correction system.


    |>?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.

    That's not what encryption is about. Implement error detection or maybe even
    correction if that's what you want it to do. While they can be implemented
    together at the same level, encryption is not error detection.


    |> 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.

    No.

    That is the job of error detection or correction.

    Encryption makes it very hard for the perp to understand your data, including
    the the error detection/correction if you happen to include that.


    |>?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.

    Add error detection/correction.

    --
    |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) |

  2. Re: encrypted filesystems

    On Sun, 17 Aug 2008 15:20:50 -0700 (PDT) David Schwartz wrote:
    | 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.

    The original descryption was a network security configuration being tampered
    with, resulting in network security exposures due to some or all of the
    security policy being unreadable. If you wanted to trust the filesystem
    layer or the block device layer to ensure data integrity, then you should
    have implemented/deployed that capability. Maybe one "file security"
    package could do both encryption AND error detection/correction. But
    that would be error detection/correction doing the integrity checking, not
    the encryption doing the integrity checking.

    Be sure the program(s) initializing the network security correctly handle
    the I/O error statuses they would get if data is corrupted and detected as
    such.


    |>?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.

    But it's not encryption that does the data integrity check. It's the data
    integrity check that does the data integrity check.


    | 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.

    A security package that lets modified data give garbled data to applications
    trying to read that data is certainly a weak one. There are ways to make
    sure even in such cases that certain critical programs like network security
    initialization don't get fooled by it (application level integrity check).
    Otherwise, be sure your filesystem/device security includes both encryption
    and integrity checking.

    --
    |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) |

  3. Re: encrypted filesystems

    On Aug 18, 11:10*pm, phil-news-nos...@ipal.net wrote:

    > On Sun, 17 Aug 2008 13:38:43 -0700 (PDT) David Schwartz wrote:


    > | On Aug 17, 12:58?pm, phil-news-nos...@ipal.net wrote:
    > |
    > |> That's not a failure of encryption.
    > |
    > | Yes, it is.
    >
    > No, it isn't.


    Okay, fine. If it's more important that we know who to blame than that
    we are secure, then use an encrypted block device. Rest safe knowing
    that when your data is not kept secret, it is not your encryption
    scheme that is to blame, even though it could have prevented the
    compromise and failed to do so.

    You can know with certainty that it was the system as a whole that
    failed to keep your data safe, not the encryption.

    However, my main point was that this type of encryption is much less
    secure than types that prevent attacks like these.

    DS

  4. Re: encrypted filesystems

    David Schwartz writes:
    > On Aug 18, 11:10*pm, phil-news-nos...@ipal.net wrote:
    >> On Sun, 17 Aug 2008 13:38:43 -0700 (PDT) David Schwartz wrote:

    >
    >> | On Aug 17, 12:58?pm, phil-news-nos...@ipal.net wrote:
    >> |
    >> |> That's not a failure of encryption.
    >> |
    >> | Yes, it is.
    >>
    >> No, it isn't.

    >
    > Okay, fine. If it's more important that we know who to blame than that
    > we are secure,


    These are simply two different types of 'cryptographic services':
    'Integrity protection' and 'protection of confidentiality' and they
    are provided by different mechanisms: The former by so-called
    'message authentication codes' and the latter by 'encryption'. While
    it usually doesn't make sense to use the second without the first, the
    opposite is not true.

  5. Re: encrypted filesystems

    On Aug 19, 5:14*am, Rainer Weikusat wrote:

    > > Okay, fine. If it's more important that we know who to blame than that
    > > we are secure,


    > These are simply two different types of 'cryptographic services':
    > 'Integrity protection' and 'protection of confidentiality' and they
    > are provided by different mechanisms: The former by so-called
    > 'message authentication codes' and the latter by 'encryption'. While
    > it usually doesn't make sense to use the second without the first, the
    > opposite is not true.


    The point is that there are a large number of real-world situations in
    which the failure to provide message authenticity will result in the
    failure to provide confidentiality. If I can get you to encrypt a
    confidential email *to* *me* by corrupting the authenticity of your
    store of keys, that the encryption is unbreakable won't do you any
    good.

    Are you going to hire a team of competent crypto experts to ensure
    that your lack of authentication won't breach your requirement for
    confidentiality? Or would you prefer a crypto solution that can
    actually reasonably assure you that your data is in fact kept secret?

    I am arguing that the opposite is not true. Message authentication is
    so easy to provide along with encryption and necessary to protect
    against all kinds of attacks where corrupt authentication information
    results in privacy compromises. Not using it is possibly reasonable
    when you can demonstrate that it creates no additional risks. It's
    ludicrous otherwise.

    For a general-purpose OS, there are simply too many cases where a
    corrupt file could result in a privacy compromise. Any encryption
    'solution' that permits an attacker to corrupt a file can result in
    such a compromise.

    DS

  6. Re: encrypted filesystems

    On Tue, 19 Aug 2008 02:43:56 -0700 (PDT) David Schwartz wrote:
    | On Aug 18, 11:10?pm, phil-news-nos...@ipal.net wrote:
    |
    |> On Sun, 17 Aug 2008 13:38:43 -0700 (PDT) David Schwartz wrote:
    |
    |> | On Aug 17, 12:58?pm, phil-news-nos...@ipal.net wrote:
    |> |
    |> |> That's not a failure of encryption.
    |> |
    |> | Yes, it is.
    |>
    |> No, it isn't.
    |
    | Okay, fine. If it's more important that we know who to blame than that
    | we are secure, then use an encrypted block device. Rest safe knowing
    | that when your data is not kept secret, it is not your encryption
    | scheme that is to blame, even though it could have prevented the
    | compromise and failed to do so.

    The whole idea of the distinction to know "who to blame" will help people make
    better decisions about encrypted and data integrity. People do want the latter
    so it needs to be included. But of that to happen they need to express the
    desire to have. Those who assume mere encryption does that are effectively
    not asking for integrity.


    | You can know with certainty that it was the system as a whole that
    | failed to keep your data safe, not the encryption.

    It was the of integrity, or a failure in the design, deployment, or the
    configuration, of the integrity, of something fails.


    | However, my main point was that this type of encryption is much less
    | secure than types that prevent attacks like these.

    It is desireable to have a tool or facility that does both encryption and
    integrity, or at least have both tools in the correct arrangement.

    --
    |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) |

  7. Re: encrypted filesystems

    On Tue, 19 Aug 2008 05:25:56 -0700 (PDT) David Schwartz wrote:

    | The point is that there are a large number of real-world situations in
    | which the failure to provide message authenticity will result in the
    | failure to provide confidentiality. If I can get you to encrypt a
    | confidential email *to* *me* by corrupting the authenticity of your
    | store of keys, that the encryption is unbreakable won't do you any
    | good.

    And so people need both. But it also needs to be understood that there is a
    need for both. Otherwise we might get one and not the other.


    | I am arguing that the opposite is not true. Message authentication is
    | so easy to provide along with encryption and necessary to protect
    | against all kinds of attacks where corrupt authentication information
    | results in privacy compromises. Not using it is possibly reasonable
    | when you can demonstrate that it creates no additional risks. It's
    | ludicrous otherwise.

    True.


    | For a general-purpose OS, there are simply too many cases where a
    | corrupt file could result in a privacy compromise. Any encryption
    | 'solution' that permits an attacker to corrupt a file can result in
    | such a compromise.

    So we need integrity checking. Would SHA512 be strong enough?

    --
    |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 20, 9:33*pm, phil-news-nos...@ipal.net wrote:

    > | For a general-purpose OS, there are simply too many cases where a
    > | corrupt file could result in a privacy compromise. Any encryption
    > | 'solution' that permits an attacker to corrupt a file can result in
    > | such a compromise.


    > So we need integrity checking. *Would SHA512 be strong enough?


    More than strong enough if it's built into the encryption. In fact,
    even MD5 would be strong enough, though it would probably be unwise to
    choose it. If you combine integrity checking and encryption, then an
    attacker must substitute an alternate *encrypted* hash and plaintext
    such that the decrypted hash matches the decrypted payload.

    For example, a typical encryption/authentication scheme works as
    follows:

    The authorized recipient knows some kind of key and a short identifier
    representing the object he wishes to retrieve from storage. We presume
    an attacker knows the short identifier but not the key and substitute
    his own encrypted block.

    The recipient gets the encrypted block (either the real one or a fake)
    and decrypts it with the key (using, say AES128 or a similar
    algorithm). The recipient parses the decrypted block into its
    components, identifier, salt, data, and checksum.

    The recipient confirms that the identifier is the identifier of the
    block he requested. If not, the block is discarded. The recipient
    hashes that identifier, salt, and data, and makes sure it matches the
    checksum. If not, the block is discarded. The block is now accepted.

    To encrypt, an identifier is selected (it can be random), a salt is
    selected (it can be random). The identifier plus data plus salt is
    checksummed, and the identifier, salt, data, and checksum are
    encrypted. The client stores the identifier in plaintext or in some
    other out-of-band way.

    An attacker who wishes to compromise this system must somehow
    construct an alternate encrypted block such that the identifier is
    correct and the hash is correct after the block is decrypted.

    DS

  9. Re: encrypted filesystems

    David Schwartz writes:

    > On Aug 20, 9:33*pm, phil-news-nos...@ipal.net wrote:
    >
    >> | For a general-purpose OS, there are simply too many cases where a
    >> | corrupt file could result in a privacy compromise. Any encryption
    >> | 'solution' that permits an attacker to corrupt a file can result in
    >> | such a compromise.

    >
    >> So we need integrity checking. *Would SHA512 be strong enough?

    >
    > More than strong enough if it's built into the encryption. In fact,
    > even MD5 would be strong enough, though it would probably be unwise to
    > choose it. If you combine integrity checking and encryption, then an
    > attacker must substitute an alternate *encrypted* hash and plaintext
    > such that the decrypted hash matches the decrypted payload.


    The same is true if integrity checking (by the filesystem or
    otherwise) is done on top of an encrypted block device. Reversing the
    order would obviously not achieve this protection, but nobody
    suggested doing that.

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

  10. Re: encrypted filesystems

    On Aug 21, 11:00*am, Måns Rullgård wrote:

    > The same is true if integrity checking (by the filesystem or
    > otherwise) is done on top of an encrypted block device.


    This was just the example I picked to refute the argument that
    encrypted block devices are superior to encrypted file systems. In
    general, encrypted block devices are aimed at defending against only a
    single attack. They are aimed at protecting against a lost hard drive
    or laptop (while the drive is locked, of course). There are, however,
    a huge number of other potential vulnerabilities, and most encrypted
    block devices are fundamentally not designed to deal with those.
    Encrypted systems that understand the data they are encrypting are
    generally designed to deal with those vulnerabilities.

    DS

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2