[148792] in cryptography@c2.net mail archive
Re: [Cryptography] On Security Architecture, The Panopticon,
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Sat Dec 28 10:47:01 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <CAAt2M1-8yk0+0Ovi+LGjXSQ_smgvKQFLV0UxoiEh9VVn-+3gRA@mail.gmail.com>
Date: Sat, 28 Dec 2013 09:44:00 -0500
To: Natanael <natanael.l@gmail.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>, ianG <iang@iang.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============2543609521625711591==
Content-Type: multipart/alternative; boundary="Apple-Mail=_CBED3DE3-5C00-4CEE-8535-61CF26064528"
--Apple-Mail=_CBED3DE3-5C00-4CEE-8535-61CF26064528
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Dec 28, 2013, at 8:32 AM, Natanael wrote:
> My point is simply that nearly undetectable exfiltration is possible. =
Thus it's only more important that we can keep the attackers out.
>=20
But this is really not news. We've known about timing channels for =
decades. We've also known that they are almost impossible to close, and =
sometimes even to detect. The only practical strategy is to limit their =
bandwidth, which can be done. The old work had to do with leakage =
channels within a single host, but we really shouldn't be surprised that =
it applies across hosts on a network as well.
What *is* new is along an entirely different dimension. It used to be =
that you could say "OK, I've gotten the maximum timing channel to one =
bit/second, getting even a small document out will take forever." Well, =
that same channel leaks an AES key in a bit over two minutes - even as =
you yourself send all your data, encrypted with that key, to an on-line =
backup site at speeds that are many, many orders of magnitude higher.
This wasn't considered in the old analyses, and unfortunately it really =
shreds them. And it's not just on networks: Even the old same-host =
attacks are more interesting again out on shared-tenant cloud hosts.
Attack and defense - the eternal battle.
-- Jerry
--Apple-Mail=_CBED3DE3-5C00-4CEE-8535-61CF26064528
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Dec 28, 2013, at 8:32 AM, Natanael =
wrote:</div><blockquote type=3D"cite"><p dir=3D"ltr">My point is simply =
that nearly undetectable exfiltration is possible. Thus it's only more =
important that we can keep the attackers out. </p></blockquote>But this =
is really not news. We've known about timing channels for decades. =
We've also known that they are almost impossible to close, and =
sometimes even to detect. The only practical strategy is to limit =
their bandwidth, which can be done. The old work had to do with =
leakage channels within a single host, but we really shouldn't be =
surprised that it applies across hosts on a network as =
well.</div><div><br></div><div>What *is* new is along an entirely =
different dimension. It used to be that you could say "OK, I've =
gotten the maximum timing channel to one bit/second, getting even a =
small document out will take forever." Well, that same channel =
leaks an AES key in a bit over two minutes - even as you yourself send =
all your data, encrypted with that key, to an on-line backup site at =
speeds that are many, many orders of magnitude =
higher.</div><div><br></div><div>This wasn't considered in the old =
analyses, and unfortunately it really shreds them. And it's not =
just on networks: Even the old same-host attacks are more =
interesting again out on shared-tenant cloud =
hosts.</div><div><br></div><div>Attack and defense - the eternal =
battle.</div><div> =
=
=
-- Jerry</div><div><br></div></body></html>=
--Apple-Mail=_CBED3DE3-5C00-4CEE-8535-61CF26064528--
--===============2543609521625711591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2543609521625711591==--
