Disk encryption in a non-private cloud is pretty pointless.
The cloud provider can access everything. An attacker should
reliably be kept from accessing your storage, otherwise you are
screwed anyways. I know, people are doing this, but they are
kidding themselves.
For your EBS scenario, true, block-level encryption
can be done, but it is irrelevant. Encryption is not the
right way to fix a broken cloud permission system. Critical
encrypted data should never be decrypted in the cloud. It
is just not secure. On the other hand, attacks that
manipulate encrypted images are not relevant for lower
security requirements, as they are very hard (expensive)
to do.
This makes integtity protection of encrypted data in the cloud
a complete non-issue. This is a solution without a problem.
Arno
On Thu, Sep 01, 2011 at 01:51:38PM +0300, Yaron Sheffer wrote:
> Hi Arno,
>
> Thank you for reviewing my post. Please see my comments below.
>
> Thanks,
> Yaron
>
> >Message: 3
> >Date: Wed, 31 Aug 2011 23:29:40 +0200
> >From: Arno Wagner<arno@xxxxxxxxxxx>
> >To: dm-crypt@xxxxxxxx
> >Subject: Re: Blog post on FDE and integrity protection
> >Message-ID:<20110831212940.GB25013@xxxxxxxxx>
> >Content-Type: text/plain; charset=us-ascii
> >
> >
> >Commercial, for sure. It combines fragments from well-known
> >facts and marketing speech. And it has not understood the
> >problem, advertizing for SAN/cloud services, where storage is
> >not block-based but file-based.
> The most commonly used public cloud is Amazon WS. This cloud offers
> two storage possibilities, S3 which is object ("file") storage, and
> EBS which is block storage, and is exposed to the application as a
> disk volume. The post is about EBS, sorry if that wasn't clear.
> >I should also note to anyone contemplating "solution" 3
> >that RAID1 does not read both devices on read access,
> >and inconsistencies will only show up if you or your
> >distro does RAID consistency checks.
> This is correct, thanks.
> >And of course the whole article does not apply to the
> >SAN/cloud setting in the first place, as the attack
> >scenario is for an unmapped encrypted filesystem and
> >an attacker getting write access to that, i.e. the
> >encrypted raw (block) view needs to be exported to
> >the attacker. I do not see how that would be done in the
> >SAN/Cloud setting. These do their own filesystem
> >and block encryption must be done below the FS layer,
> >there is no way around that.
> The attack scenario is for someone who has access (possibly limited
> access) to your cloud account to detach your EBS volume from its
> current virtual server, attach it to a different server, and then
> modify the (encrypted) storage. This is all completely doable and
> actually standard procedure on AWS.
> >
> >Arno
> >
> >
> >
> >On Wed, Aug 31, 2011 at 04:25:51PM +0200, Heinz Diehl wrote:
> >>On 31.08.2011, Yaron Sheffer wrote:
> >>
> >>[....]
> >>
> >>In what way is this related to LUKS / dmcrypt?
> >>It's plain advertising, isn't it? Gaah!
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>dm-crypt mailing list
> >>dm-crypt@xxxxxxxx
> >>http://www.saout.de/mailman/listinfo/dm-crypt
> >>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
>
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
