On Thu, Sep 01, 2011 at 10:58:17AM -0500, Shardis wrote: > Personally, I tend to find that the only sane technical reason not to > encrypt anything considered sensitive these days is CPU cycle cost. I am not arguing that. I am aguing that "sensitive" data has no place in a non-private cloud in the first place, and hence the discussion whether to encrypt sensitive data in a non-private cloud or not does not apply. I am also aguing that for non-sensitive data, encryption may cause more problems than it solves, see below. > For the vast, VAST majority of use cases the cost of CPU cycles is almost > inconsequential when compared to the cost of any other knowledge, > hardware, software, management and support that would be needed in any > case. > > While I'm not intimately familiar with broadcast media uses - I would > strongly suspect that this would be the case even there. > > Or maybe I just don't have a lively enough imagination. I do work > operations in a data center with at least a few petabytes on hand though. > > Why would you ever NOT want to encrypt in house? Keeping in mind that the topic is block-layer encryption, you have added cost for: - CPU and power - key management - risk of key loss (and data loss as a consequence) - encryption software management - increased complexity - more difficult data recovery and problem detection - analysis of on-disk data requires keys and working decryption - problems when law enforcement comes with a warrant I am sure there are a few others. Arno > Yaron Sheffer <yaronf@xxxxxxx> wrote: > > >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 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt