From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2wP6OTANQZ4 for ; Wed, 31 Aug 2011 15:10:08 +0200 (CEST) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.43]) by mail.saout.de (Postfix) with SMTP for ; Wed, 31 Aug 2011 15:10:08 +0200 (CEST) Message-ID: <4E5E30F4.3010607@gmx.com> Date: Wed, 31 Aug 2011 16:02:44 +0300 From: Yaron Sheffer MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de
Hi,

this post is partly based on discussions on this list, and should be of interest to people around here.

http://www.porticor.com/2011/08/full-disk-encryption-and-integrity-protection/

Comments are most welcome.

Thanks,
Yaron
From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9CVUJ_Isdkp for ; Wed, 31 Aug 2011 16:25:36 +0200 (CEST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 31 Aug 2011 16:25:36 +0200 (CEST) Date: Wed, 31 Aug 2011 16:25:51 +0200 From: Heinz Diehl Message-ID: <20110831142551.GA1834@fancy-poultry.org> References: <4E5E30F4.3010607@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5E30F4.3010607@gmx.com> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 31.08.2011, Yaron Sheffer wrote: [....] In what way is this related to LUKS / dmcrypt? It's plain advertising, isn't it? Gaah! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw8_4vgNkPWO for ; Wed, 31 Aug 2011 23:29:41 +0200 (CEST) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 31 Aug 2011 23:29:41 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-162-232.dclient.hispeed.ch [84.74.162.232]) by v4.tansi.org (Postfix) with ESMTPA id 5FCF920620D for ; Wed, 31 Aug 2011 23:29:41 +0200 (CEST) Date: Wed, 31 Aug 2011 23:29:40 +0200 From: Arno Wagner Message-ID: <20110831212940.GB25013@tansi.org> References: <4E5E30F4.3010607@gmx.com> <20110831142551.GA1834@fancy-poultry.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110831142551.GA1834@fancy-poultry.org> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQUrawGr-xI4 for ; Thu, 1 Sep 2011 12:51:42 +0200 (CEST) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.43]) by mail.saout.de (Postfix) with SMTP for ; Thu, 1 Sep 2011 12:51:42 +0200 (CEST) Message-ID: <4E5F63BA.2070701@gmx.com> Date: Thu, 01 Sep 2011 13:51:38 +0300 From: Yaron Sheffer MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 > 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 >> From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORF6_N8bF5GL for ; Thu, 1 Sep 2011 13:33:46 +0200 (CEST) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 1 Sep 2011 13:33:46 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-162-232.dclient.hispeed.ch [84.74.162.232]) by v4.tansi.org (Postfix) with ESMTPA id 2ED1020622E for ; Thu, 1 Sep 2011 13:33:46 +0200 (CEST) Date: Thu, 1 Sep 2011 13:27:24 +0200 From: Arno Wagner Message-ID: <20110901112724.GB4617@tansi.org> References: <4E5F63BA.2070701@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5F63BA.2070701@gmx.com> Subject: Re: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 > >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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu_YkYywgg9a for ; Thu, 1 Sep 2011 14:56:51 +0200 (CEST) Received: from ppd07152.deutschepost.de (ppd07152.deutschepost.de [149.239.170.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 1 Sep 2011 14:56:51 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Sep 2011 14:34:21 +0200 Message-ID: In-Reply-To: <20110901112724.GB4617@tansi.org> References: <4E5F63BA.2070701@gmx.com> <20110901112724.GB4617@tansi.org> From: Subject: Re: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Cc: arno@wagner.name 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.=20 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.=20 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".=20 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 ?=20 - What if the secure deletetion / disk wipe procedure fails for volumes = on the cloud provider ?=20 - What if your snapshots of your EBS volumes leak somewhere due to = improper security ?=20 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,=20 Robert=20 -----Urspr=FCngliche 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.=20 The cloud provider can access everything. An attacker should=20 reliably be kept from accessing your storage, otherwise you are=20 screwed anyways. I know, people are doing this, but they are=20 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=20 encrypted data should never be decrypted in the cloud. It=20 is just not secure. On the other hand, attacks that manipulate encrypted images are not relevant for lower=20 security requirements, as they are very hard (expensive)=20 to do. This makes integtity protection of encrypted data in the cloud a complete non-issue. This is a solution without a problem. Arno From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMWI6BDiK-Sc for ; Thu, 1 Sep 2011 18:45:42 +0200 (CEST) Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 1 Sep 2011 18:45:41 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-162-232.dclient.hispeed.ch [84.74.162.232]) by v4.tansi.org (Postfix) with ESMTPA id 6A62F20622E for ; Thu, 1 Sep 2011 18:45:41 +0200 (CEST) Date: Thu, 1 Sep 2011 18:45:41 +0200 From: Arno Wagner Message-ID: <20110901164541.GA8594@tansi.org> References: <4E5F63BA.2070701@gmx.com> <20110901112724.GB4617@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxAI_cn4hoD6 for ; Thu, 1 Sep 2011 19:37:21 +0200 (CEST) Received: from ppd07153.deutschepost.de (ppd07153.deutschepost.de [149.239.170.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 1 Sep 2011 19:37:20 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Sep 2011 19:37:06 +0200 Message-ID: In-Reply-To: <20110901164541.GA8594@tansi.org> References: <4E5F63BA.2070701@gmx.com> <20110901112724.GB4617@tansi.org> <20110901164541.GA8594@tansi.org> From: Subject: Re: [dm-crypt] Blog post on FDE and integrity protection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Cc: arno@wagner.name But this actually means:=20 "Multi Tenant Cloud Environments and Security are mutual exclusive" I kind of disagree.=20 I look at cloud security and encryption like this:=20 - 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.=20 ... 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.=20 .. Those are just some thoughts.=20 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,=20 Robert=20 -----Urspr=FCngliche 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=20 deal with some problems causes by defective cloud access rights=20 management. However this fix is in the wrong place and only=20 partial at best. If it is a realistic assumption that somebody=20 can access your private storage in the cloud, you should not=20 put anything of value in there anyways. If the data has no=20 value, then encrypting it just cause cost and effort and very=20 little securit gain. This makes encryption not "completely"=20 pointless, but "pretty" pointless. (Sorry for nit-picking...) Encryption does cause new problems: For one, you cannot start=20 your cloud instances manually anymore, as the attacker may well=20 get access to the wrong image in addition. And if that decrypts=20 the block storage automatically, then you are screwed,=20 encryption or no.=20 =20 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=20 the encrypted variant more than the plain one. You may even=20 lose some degree of protection, as you are potentially drawing=20 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