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
