Re: [dm-crypt] Blog post on FDE and integrity protection

Re: [dm-crypt] Blog post on FDE and integrity protection

[Yaron Sheffer]

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:
>>
>> [....]
>>
>> In what way is this related to LUKS / dmcrypt?
>> It's plain advertising, isn't it? Gaah!
>>
>>
>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>

Re: [dm-crypt] Blog post on FDE and integrity protection

[Arno Wagner]

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:
> >>
> >>[....]
> >>
> >>In what way is this related to LUKS / dmcrypt?
> >>It's plain advertising, isn't it? Gaah!
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>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] Blog post on FDE and integrity protection

[Robert.Heinzmann]

Hello,

I read this discussion and I find this very interesting, especially the cloud discussion.

The point here is that I don't think that it is a useless approach to encrypt disks in the cloud. 

The question is what do you want to protect from ? In the cloud there are several risks due to the multi tenancy and shared approach. 

Of course there is the "The cloud provider is bad and want's my data". However - as you say - you can only protect from this by chosing the right cloud provider (e.g. within your legal system, trustworthy etc). Also certifications of the cloud provider ensuring operational safety help here. In this regards cloud computing is "just outsourcing". 

If you want to use the benefits of IaaS cloud computing, this is the risk you have to live with finally - as with traditional hosting and outsourcing. For PaaS and SaaS there are solutions where only encrypted data is leaving the company (e.g. CipherCloud).

On the other hand there are much more real problems caused by the shared tenancy and high automation in the cloud.

- What if the automation system of the cloud provider fails and mapps volumes to wrong hosts ? 
- What if the secure deletetion / disk wipe procedure fails for volumes on the cloud provider ? 
- What if your snapshots of your EBS volumes leak somewhere due to improper security ? 

For all of this encryption is a good idea. It helps - it is not 100% but it helps. Basically it solves the secure delete problem for the "curious professional" - it does not help against motivated hackers.

If you combine encryption this with a proper security policy (patching, firewalling, access control, VPN access) you can do quite a lot in the cloud - quite secure.

Regards, 
Robert 

-----Ursprüngliche Nachricht-----
Von: dm-crypt-bounces@saout.de [mailto:dm-crypt-bounces@saout.de] Im Auftrag von Arno Wagner
Gesendet: Donnerstag, 1. September 2011 13:27
An: dm-crypt@saout.de
Betreff: Re: [dm-crypt] Blog post on FDE and integrity protection

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

Re: [dm-crypt] Blog post on FDE and integrity protection

[Arno Wagner]

I do not dispute your statements. Encryption can indeed help to 
deal with some problems causes by defective cloud access rights 
management. However this fix is in the wrong place and only 
partial at best. If it is a realistic assumption that somebody 
can access your private storage in the cloud, you should not 
put anything of value in there anyways. If the data has no 
value, then encrypting it just cause cost and effort and very 
little securit gain. This makes encryption not "completely" 
pointless, but "pretty" pointless. (Sorry for nit-picking...)

Encryption does cause new problems: For one, you cannot start 
your cloud instances manually anymore, as the attacker may well 
get access to the wrong image in addition. And if that decrypts 
the block storage automatically, then you are screwed, 
encryption or no. 
 
But the thing is this: If you start encrypting in the cloud,
you have no clear protection or attacker model. This makes
encryption worthless from a risk management perspective, as
you cannot quantify what you gain at all and cannot trust 
the encrypted variant more than the plain one. You may even 
lose some degree of protection, as you are potentially drawing 
attention to your data. Sure,encryption can still make you
feel better. But that is not risk management.

Now the thing that is really pointless is integrity protection
for encrypted data in the cloud, as you do not get a security
level high enough for it to make a difference.

And the Blog posts fails to discuss these aspects.

Arno

On Thu, Sep 01, 2011 at 02:34:21PM +0200, Robert.Heinzmann@deutschepost.de wrote:
> Hello,
> 
> I read this discussion and I find this very interesting, especially the
> cloud discussion.
> 
> The point here is that I don't think that it is a useless approach to
> encrypt disks in the cloud.
> 
> The question is what do you want to protect from ? In the cloud there are
> several risks due to the multi tenancy and shared approach.
> 
> Of course there is the "The cloud provider is bad and want's my data".
> However - as you say - you can only protect from this by chosing the right
> cloud provider (e.g.  within your legal system, trustworthy etc).  Also
> certifications of the cloud provider ensuring operational safety help
> here.  In this regards cloud computing is "just outsourcing".
> 
> If you want to use the benefits of IaaS cloud computing, this is the risk
> you have to live with finally - as with traditional hosting and
> outsourcing.  For PaaS and SaaS there are solutions where only encrypted
> data is leaving the company (e.g.  CipherCloud).
> 
> On the other hand there are much more real problems caused by the shared
> tenancy and high automation in the cloud.
> 
> - What if the automation system of the cloud provider fails and mapps
>   volumes to wrong hosts ?
>
> - What if the secure deletetion / disk wipe procedure fails for volumes on
>   the cloud provider ?
>
> - What if your snapshots of your EBS volumes leak somewhere due to
>   improper security ?
> 
> For all of this encryption is a good idea. It helps - it is not 100% but
> it helps.  Basically it solves the secure delete problem for the "curious
> professional" - it does not help against motivated hackers.
> 
> If you combine encryption this with a proper security policy (patching,
> firewalling, access control, VPN access) you can do quite a lot in the
> cloud - quite secure.
> 
> Regards, 
> Robert 
> 
> -----Urspr?ngliche Nachricht-----
> Von: dm-crypt-bounces@saout.de [mailto:dm-crypt-bounces@saout.de] Im Auftrag von Arno Wagner
> Gesendet: Donnerstag, 1. September 2011 13:27
> An: dm-crypt@saout.de
> Betreff: Re: [dm-crypt] Blog post on FDE and integrity protection
> 
> 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
> 
> 

-- 
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] Blog post on FDE and integrity protection

[Robert.Heinzmann]

But this actually means: 

 "Multi Tenant Cloud Environments and Security are mutual exclusive"

I kind of disagree. 

I look at cloud security and encryption like this: 

 - You can not protect against attacks if a major instituation with unlimited power is behind an attack (e.g. a government - as seen with Iran and the tuxnet attack). The only defense against this kind of attacks is don't store the data it in the first place and address the issue with or have a good insurance plan. 

 ... another more idealistic alternative is to try not to have too many enemies :)

 - Make sure you can trust your cloud provider. Does the cloud provider use it's own product ? If so - there is motivation to make this thing secure. Does the provider have the experience in an internetworked world ? Does he have the resources to address global DDoS etc. - practially speaking: does he have the biggest pipes ? - There are some.

 - Use encryption all the time for everything. Encryption adds new limitations to the operations you perform in cloud environments. There is a operational impact on availability, DR, backup & recovery and provisioning (loosing the salt, loosing the key, or silent block error escalation due to the chaining mode etc.). Solve it for all your machines and you gain routine for the operating guys. If you only encrypt sensitive data, as you say, you draw attention and reduce the attack effort, because you practially label your honeyspot. Also routine tasks become risky, if you do not train them all the time.

 - For practiall security - other factors are much more important. Establishing a real security policy on the logical level helps much more then encryption. Once a attacker is in the machine, encryption is useless. Here a good isolation policy is required (no cross machine passwords, strong firewalling, unique encryption keys etc.) Encryption can really only protect data at rest at 100% once the encryption key is out of memory. Make sure no-one can read this memory.

 - Make sure that you understand your encryption technology in the cloud. Understand the difference between an encryption key and a wrapping key. Understand that the key is ALWAYS readable by someone with physical access to the computer - deal with it (e.g. Split sensitive across cloud providers data to make it useless - aka PCI standard). Understand the difference between pre provisioning encryption and post provisioning encryption and the operational impact of the two. Make sure you establish security escalation zones - think about the worst case and assume that a machine will highjacked. Make sure you notice this (Intrustion Detection) and have a pre-prepared plan on how to deal with this issue then. 

.. Those are just some thoughts. 

I agree that cloud is a challenge for security - just as accidents are a challenge for traffic. As car's had to learn how to protect the owner once the streets got fuller and fuller, IT has to learn how to address security in a inter networked world. There is no way back - I guess ...

(... This seems to have gotten a little off the track in regards to disk encryption and even more in regards to the blog - so sorry for this :)

Regards, 
Robert 



-----Ursprüngliche Nachricht-----
Von: dm-crypt-bounces@saout.de [mailto:dm-crypt-bounces@saout.de] Im Auftrag von Arno Wagner
Gesendet: Donnerstag, 1. September 2011 18:46
An: dm-crypt@saout.de
Betreff: Re: [dm-crypt] Blog post on FDE and integrity protection

I do not dispute your statements. Encryption can indeed help to 
deal with some problems causes by defective cloud access rights 
management. However this fix is in the wrong place and only 
partial at best. If it is a realistic assumption that somebody 
can access your private storage in the cloud, you should not 
put anything of value in there anyways. If the data has no 
value, then encrypting it just cause cost and effort and very 
little securit gain. This makes encryption not "completely" 
pointless, but "pretty" pointless. (Sorry for nit-picking...)

Encryption does cause new problems: For one, you cannot start 
your cloud instances manually anymore, as the attacker may well 
get access to the wrong image in addition. And if that decrypts 
the block storage automatically, then you are screwed, 
encryption or no. 
 
But the thing is this: If you start encrypting in the cloud,
you have no clear protection or attacker model. This makes
encryption worthless from a risk management perspective, as
you cannot quantify what you gain at all and cannot trust 
the encrypted variant more than the plain one. You may even 
lose some degree of protection, as you are potentially drawing 
attention to your data. Sure,encryption can still make you
feel better. But that is not risk management.

Now the thing that is really pointless is integrity protection
for encrypted data in the cloud, as you do not get a security
level high enough for it to make a difference.

And the Blog posts fails to discuss these aspects.

Arno

[dm-crypt] Blog post on FDE and integrity protection

[Yaron Sheffer]

[-- Attachment #1: Type: text/html, Size: 859 bytes --]

Re: [dm-crypt] Blog post on FDE and integrity protection

[Heinz Diehl]

On 31.08.2011, Yaron Sheffer wrote: 

[....]

In what way is this related to LUKS / dmcrypt?
It's plain advertising, isn't it? Gaah!

Re: [dm-crypt] Blog post on FDE and integrity protection

[Arno Wagner]

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. 

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. 

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.

Arno



On Wed, Aug 31, 2011 at 04:25:51PM +0200, Heinz Diehl wrote:
> On 31.08.2011, Yaron Sheffer wrote: 
> 
> [....]
> 
> In what way is this related to LUKS / dmcrypt?
> It's plain advertising, isn't it? Gaah!
> 
> 
> 
> 
> _______________________________________________
> 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