Indeed, good points. And thanks! ;-)
Arno
On Thu, Sep 01, 2011 at 01:22:02PM -0500, Shardis wrote:
> Agreed that sensitive data doesn't belong in the cloud. How could it when
> the cloud by definition has to have access to everything to
> decrypt/encrypt? That's just added exposure for no real gain other than
> saving some relatively cheap cycles.
>
> If you're having to manage crypto at all - I guess I wasn't saying that
> well, as I take the additional costs you mentioned as a given.
>
> I'd also add to that list the sheer amount of knowledge and education
> that's basically required and encompasses all of what you mentioned.
> Maybe a bit dodgy of me to just lump all of that together, but you either
> have to know it, have employees that know it, or hire it. All of those
> are expensive in both time and money.
>
> I'm sure there are others too. I'll go back to lurking, touch screen
> typing is getting too frustrating and you're articulating everything more
> clearly than I can anyway. :-)
>
> Arno Wagner <arno@xxxxxxxxxxx> wrote:
>
> >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
> _______________________________________________
> 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
