On Wed, Jan 15, 2014 at 01:34:01AM -0800, coderman wrote:
> On Tue, Jan 14, 2014 at 6:44 PM, Uncle Zzzen <unclezz...@gmail.com> wrote:
> >
> >>         3. "Passive" global adversary attack:
> >>
> > As long as the JS is what the owner claims it is (assuming it's code that
> > has been peer reviewed enough according to your standards), it doesn't
> > matter whether they confiscate the hard drive or just listen.

as coderman said, uncle zzzen, you are wrong. but for other reasons
than the three he mentions. it doesn't matter if the JS safely makes
it to both users' browsers if the adversary can access both the
encrypted message and the private key to decrypt it.

also you're living in the past if you think a server hard drive
needs to be confiscated to be examined. in the case of a VPS it's
enough to have a root shell on the physical host. in the case of
either a VPS or a dedicated server it's enough to p0wn the SMM.
see the recent spiegel publications that came out at 30c3.
backdoors against DELL server products are specifically described
in detail, but it is appropriate to presume that there are more
of the kind.

these days, server owners have no chance to know whether their
servers are under surveillance or not. the amount of effort
however can vary. if servers require targeted attacks then we
must avoid creating honeypots like 0bin that are worthwhile
to target... if.

if large scale server surveillance is already in place, then it
doesn't really matter where we try to entrust servers. it will
always fail. unfortunately it's not easy to tell how bad the
situation is. when was the last time you dumped and examined the
contents of your server's SMM?

> i hate the term "passive global adversary".  the adversary active
> across the global theater is able and active.

i find it relevant that the adversary doesn't need to become
detectable to apply this attack. not even the admin of such a
pastebin service can tell when the day strikes that it is being
surveilled.

> also, you're wrong three ways:
> 
> 1) if entropy is compromised (see history of RNG tampering) this
> assumption is actionable-ly false.  don't get me started on the
> OpenSSL/* RDRAND fiasco...

i think discussing the capability of the end-user devices to
provide reasonable cryptographic service is outside the scope
of my attack description. i presume this is fixable if anyone
has an interest in fixing it.

> 2) "JS is what the owner claims it is" is suspect in BULLRUN situation
> where private keys pilfered. (not to mention all the other subversive
> techniques applied)

yes, as i described in scenario (2)

> 3) the attack surface of the browser.  nuff said!   (or said again,
> "just listen" is only harmless if no prior active intervention has
> occurred)

it is reasonable to argue that the web browser is such a complex
monster it is impossible to secure. i presumed that to be obvious
but maybe it should be mentioned for completeness.


-- 
            http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Reply via email to