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

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

[Yaron Sheffer]

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@saout.de wrote:


Message: 2
Date: Thu, 1 Sep 2011 13:27:24 +0200
From: Arno Wagner<arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
Message-ID:<20110901112724.GB4617@tansi.org>
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@wagner.name>
>>> To: dm-crypt@saout.de
>>> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
>>> Message-ID:<20110831212940.GB25013@tansi.org>
>>> 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:
>>>>

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

[Arno Wagner]

Hi Yaron,

all this is really just a side issue to disk encryption
as many of the base asumptions do not apply in a cloud 
setting. For example, disk encryption on a laptop does not 
really protect you from an attacker with repeated undetected 
access, but from the situation when you lose the machine,
know it and it stays lost. An attcker with repeated access 
can do a lot of things that completely negate all benefits
of disk encryption. In the cloud, repeated access is the 
the primary model.

Some more comments below.

On Thu, Sep 01, 2011 at 04:30:23PM +0300, Yaron Sheffer 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.

If we are talking secure cloud storage, then the encryption did
not happen in the cloud and the situation is different. As network
bandwiths are low in comparison with encryption speeds encrypting
the data before putting it in the cloud is easy. I do know that
there are cloud storage providers that encrypt in the cloud,
but these do not qualify as "secure" and the encryption is pure
parketing that does not add any quantifiable amount of security.

Als, this type of storage will typically be file-based.
 
> The cloud provider does not have access to "everything", certainly

He does.

> 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

What prevents the cloud provider from regularly pulling
keys from VMs and storing them? It may take a little effort,
but encrypted data is relatively easy to recognize, and pulling
encryption keys from, say, a Linux kernel, is easy if you have raw
memory access. For encrypted block devices you just need to find 
the key once.

I see no problem at all with scripting this with reasonable 
efffectiveness in, say, 4-8 developer weeks. And given that 
Amazon (and others) cooperate with TLAs at least in the US, I 
am sure they have been asked to put such "key grabbers" into 
place and have them ready. Now, I am not saying they run these 
routinely and on all instances, but I think that it would be 
entirely feasible and cause quite low overhead to do so.

Side note: If it is encrypted block storage "at rest", the
cloud provider can just wait until you access it again and
then grab your keys.

> cloud provider is not the only or the most important threat. By the
> way, I am not claiming that the permission system is broken.

If the permission system is unbroken, then encryption does
not add anything, see above.
 
> 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 staement does not make sense. Maybe you mean it the other 
way round? Still, if you can actually brute-force (or somthing
close to it) with reasonable cost, I would regard the crypto 
as broken. That would not be the fault of the cloud.

But you forget that access (physical, logical) in the cloud is not 
under your control and in fact you may not even be able to tell 
what access security measures are in place, and how good they 
are. Certification, SLAs and vendor promises have turned out
to be meaningless time and again. As this applies to your system 
image and even your system memory as well, encryption does not 
solve the problem. It does however increase complexity.
 
> This is a solution for a very real problem. But I don't want to go
> commercial again...

The problem is very real, I agree on that. However, block-device 
encryption is not the solution. The real danger is that people 
could think it was a solution, i.e. think their data was
secure in the cloud because "it is encrypted". But the cold fact 
is that you cannot trust a cloud not under your control with 
confidential data. That is why confidential data does not 
belong there. For a "private" cloud, things are different. 

Arno




> Thanks,
>     Yaron
> 
> On 09/01/2011 02:38 PM, dm-crypt-request@saout.de wrote:
> 
> 
> Message: 2
> Date: Thu, 1 Sep 2011 13:27:24 +0200
> From: Arno Wagner<arno@wagner.name>
> To: dm-crypt@saout.de
> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
> Message-ID:<20110901112724.GB4617@tansi.org>
> 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@wagner.name>
> >>>To: dm-crypt@saout.de
> >>>Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
> >>>Message-ID:<20110831212940.GB25013@tansi.org>
> >>>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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

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

[Arno Wagner]

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@wagner.name> 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@gmx.com> 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@saout.de wrote:
> >> >
> >> >
> >> >Message: 2
> >> >Date: Thu, 1 Sep 2011 13:27:24 +0200
> >> >From: Arno Wagner<arno@wagner.name>
> >> >To: dm-crypt@saout.de
> >> >Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
> >> >Message-ID:<20110901112724.GB4617@tansi.org>
> >> >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@wagner.name>
> >> >>>> To: dm-crypt@saout.de
> >> >>>> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
> >> >>>> Message-ID:<20110831212940.GB25013@tansi.org>
> >> >>>> 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@saout.de
> >> >http://www.saout.de/mailman/listinfo/dm-crypt
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >> 
> >
> >-- 
> >Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
> >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@saout.de
> >http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

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

[Shardis]

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@wagner.name> 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@gmx.com> 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@saout.de wrote:
>> >
>> >
>> >Message: 2
>> >Date: Thu, 1 Sep 2011 13:27:24 +0200
>> >From: Arno Wagner<arno@wagner.name>
>> >To: dm-crypt@saout.de
>> >Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
>> >Message-ID:<20110901112724.GB4617@tansi.org>
>> >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@wagner.name>
>> >>>> To: dm-crypt@saout.de
>> >>>> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
>> >>>> Message-ID:<20110831212940.GB25013@tansi.org>
>> >>>> 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@saout.de
>> >http://www.saout.de/mailman/listinfo/dm-crypt
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>> 
>
>-- 
>Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
>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@saout.de
>http://www.saout.de/mailman/listinfo/dm-crypt

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

[Arno Wagner]

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@gmx.com> 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@saout.de wrote:
> >
> >
> >Message: 2
> >Date: Thu, 1 Sep 2011 13:27:24 +0200
> >From: Arno Wagner<arno@wagner.name>
> >To: dm-crypt@saout.de
> >Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
> >Message-ID:<20110901112724.GB4617@tansi.org>
> >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@wagner.name>
> >>>> To: dm-crypt@saout.de
> >>>> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
> >>>> Message-ID:<20110831212940.GB25013@tansi.org>
> >>>> 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@saout.de
> >http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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 

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

[Heinz Diehl]

On 01.09.2011, 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.

"Security is essentially a trade-off" (B. Schneier). If the data is worth the encryption, you'll have to live with cpu overhead.
If it's not: why do you want to have it encrypted, then?

> Why would you ever NOT want to encrypt in house?

Because the data isn't worth it?

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

[Shardis]

Personally, I tend to find that the only sane technical reason not to encrypt anything considered sensitive these days is CPU cycle cost.

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?

Yaron Sheffer <yaronf@gmx.com> 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@saout.de wrote:
>
>
>Message: 2
>Date: Thu, 1 Sep 2011 13:27:24 +0200
>From: Arno Wagner<arno@wagner.name>
>To: dm-crypt@saout.de
>Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
>Message-ID:<20110901112724.GB4617@tansi.org>
>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@wagner.name>
>>>> To: dm-crypt@saout.de
>>>> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection
>>>> Message-ID:<20110831212940.GB25013@tansi.org>
>>>> 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@saout.de
>http://www.saout.de/mailman/listinfo/dm-crypt