Re: dm-crypt Digest, Vol 27, Issue 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arno,

Encryption of data-at-rest in the public cloud is not "pointless", it is yet another layer of security. Just as people encrypt their laptops even though they are password protected.

The cloud provider does not have access to "everything", certainly not when we're talking about data at rest, where the keys may have come and gone months ago but the data is still there. Moreover, the cloud provider is not the only or the most important threat. By the way, I am not claiming that the permission system is broken.

Attacks on encrypted data are no harder or more expensive in the cloud than on physical disks. If you parallelize things, your throughput is limited by the disks physical access, just as for "real" disks.

This is a solution for a very real problem. But I don't want to go commercial again...

Thanks,
    Yaron

On 09/01/2011 02:38 PM, dm-crypt-request@xxxxxxxx wrote:


Message: 2
Date: Thu, 1 Sep 2011 13:27:24 +0200
From: Arno Wagner<arno@xxxxxxxxxxx>
To: dm-crypt@xxxxxxxx
Subject: Re:  Blog post on FDE and integrity protection
Message-ID:<20110901112724.GB4617@xxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

Disk encryption in a non-private cloud is pretty pointless.
The cloud provider can access everything. An attacker should
reliably be kept from accessing your storage, otherwise you are
screwed anyways. I know, people are doing this, but they are
kidding themselves.

For your EBS scenario, true, block-level encryption
can be done, but it is irrelevant. Encryption is not the
right way to fix a broken cloud permission system. Critical
encrypted data should never be decrypted in the cloud. It
is just not secure. On the other hand, attacks that
manipulate encrypted images are not relevant for lower
security requirements, as they are very hard (expensive)
to do.

This makes integtity protection of encrypted data in the cloud
a complete non-issue. This is a solution without a problem.

Arno




On Thu, Sep 01, 2011 at 01:51:38PM +0300, Yaron Sheffer wrote:

Hi Arno,

Thank you for reviewing my post. Please see my comments below.

Thanks,
     Yaron

Message: 3
Date: Wed, 31 Aug 2011 23:29:40 +0200
From: Arno Wagner<arno@xxxxxxxxxxx>
To: dm-crypt@xxxxxxxx
Subject: Re:  Blog post on FDE and integrity protection
Message-ID:<20110831212940.GB25013@xxxxxxxxx>
Content-Type: text/plain; charset=us-ascii


Commercial, for sure. It combines fragments from well-known
facts and marketing speech. And it has not understood the
problem, advertizing for SAN/cloud services, where storage is
not block-based but file-based.
The most commonly used public cloud is Amazon WS. This cloud offers
two storage possibilities, S3 which is object ("file") storage, and
EBS which is block storage, and is exposed to the application as a
disk volume. The post is about EBS, sorry if that wasn't clear.
I should also note to anyone contemplating "solution" 3
that RAID1 does not read both devices on read access,
and inconsistencies will only show up if you or your
distro does RAID consistency checks.
This is correct, thanks.
And of course the whole article does not apply to the
SAN/cloud setting in the first place, as the attack
scenario is for an unmapped encrypted filesystem and
an attacker getting write access to that, i.e. the
encrypted raw (block) view needs to be exported to
the attacker. I do not see how that would be done in the
SAN/Cloud setting. These do their own filesystem
and block encryption must be done below the FS layer,
there is no way around that.
The attack scenario is for someone who has access (possibly limited
access) to your cloud account to detach your EBS volume from its
current virtual server, attach it to a different server, and then
modify the (encrypted) storage. This is all completely doable and
actually standard procedure on AWS.
Arno



On Wed, Aug 31, 2011 at 04:25:51PM +0200, Heinz Diehl wrote:
On 31.08.2011, Yaron Sheffer wrote:

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux