* Re: [dm-crypt] Blog post on FDE and integrity protection
[not found] <mailman.1.1314871201.12413.dm-crypt@saout.de>
@ 2011-09-01 10:51 ` Yaron Sheffer
2011-09-01 11:27 ` Arno Wagner
0 siblings, 1 reply; 8+ messages in thread
From: Yaron Sheffer @ 2011-09-01 10:51 UTC (permalink / raw)
To: dm-crypt
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
>>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Blog post on FDE and integrity protection
2011-09-01 10:51 ` [dm-crypt] Blog post on FDE and integrity protection Yaron Sheffer
@ 2011-09-01 11:27 ` Arno Wagner
2011-09-01 12:34 ` Robert.Heinzmann
0 siblings, 1 reply; 8+ messages in thread
From: Arno Wagner @ 2011-09-01 11:27 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Blog post on FDE and integrity protection
2011-09-01 11:27 ` Arno Wagner
@ 2011-09-01 12:34 ` Robert.Heinzmann
2011-09-01 16:45 ` Arno Wagner
0 siblings, 1 reply; 8+ messages in thread
From: Robert.Heinzmann @ 2011-09-01 12:34 UTC (permalink / raw)
To: dm-crypt; +Cc: arno
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Blog post on FDE and integrity protection
2011-09-01 12:34 ` Robert.Heinzmann
@ 2011-09-01 16:45 ` Arno Wagner
2011-09-01 17:37 ` Robert.Heinzmann
0 siblings, 1 reply; 8+ messages in thread
From: Arno Wagner @ 2011-09-01 16:45 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Blog post on FDE and integrity protection
2011-09-01 16:45 ` Arno Wagner
@ 2011-09-01 17:37 ` Robert.Heinzmann
0 siblings, 0 replies; 8+ messages in thread
From: Robert.Heinzmann @ 2011-09-01 17:37 UTC (permalink / raw)
To: dm-crypt; +Cc: arno
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Blog post on FDE and integrity protection
2011-08-31 14:25 ` Heinz Diehl
@ 2011-08-31 21:29 ` Arno Wagner
0 siblings, 0 replies; 8+ messages in thread
From: Arno Wagner @ 2011-08-31 21:29 UTC (permalink / raw)
To: dm-crypt
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] Blog post on FDE and integrity protection
2011-08-31 13:02 Yaron Sheffer
@ 2011-08-31 14:25 ` Heinz Diehl
2011-08-31 21:29 ` Arno Wagner
0 siblings, 1 reply; 8+ messages in thread
From: Heinz Diehl @ 2011-08-31 14:25 UTC (permalink / raw)
To: dm-crypt
On 31.08.2011, Yaron Sheffer wrote:
[....]
In what way is this related to LUKS / dmcrypt?
It's plain advertising, isn't it? Gaah!
^ permalink raw reply [flat|nested] 8+ messages in thread
* [dm-crypt] Blog post on FDE and integrity protection
@ 2011-08-31 13:02 Yaron Sheffer
2011-08-31 14:25 ` Heinz Diehl
0 siblings, 1 reply; 8+ messages in thread
From: Yaron Sheffer @ 2011-08-31 13:02 UTC (permalink / raw)
To: dm-crypt
[-- Attachment #1: Type: text/html, Size: 859 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-09-01 17:37 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.1.1314871201.12413.dm-crypt@saout.de>
2011-09-01 10:51 ` [dm-crypt] Blog post on FDE and integrity protection Yaron Sheffer
2011-09-01 11:27 ` Arno Wagner
2011-09-01 12:34 ` Robert.Heinzmann
2011-09-01 16:45 ` Arno Wagner
2011-09-01 17:37 ` Robert.Heinzmann
2011-08-31 13:02 Yaron Sheffer
2011-08-31 14:25 ` Heinz Diehl
2011-08-31 21:29 ` Arno Wagner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.