Re: [tor-talk] [tor-dev] resistance to rubberhose and UDP questions

[grarpamp <grarpamp@xxxxxxxxx>]

Import from rubberhose dirauth on other list...

> *Anyone* with *any* access to the data centers that host the directory
> authorities is potentially subject to either a coercive or subversive
>
> As you know, I've been digging down the rabbit hole of how to ensure the
> integrity of a remote machine, and it seems impossible to do this
> without both secure boot *and* a way to verify the current runtime
> integrity.

You can cold boot for OS fs crypto keys, then swap mobo make new
secure boot keys, root shell, etc. Only can do is to have a secure online
OS, and then detect reboot. A consesused matrix of long term ssh connections
can do this... they can't be mitm, so your "while, sleep 1, date" through
them would detect pause long before the required art of [cold]probe and save
their ssh/tcp state through rebout would be accomplish. Use epoxy too.
Some places use this monitor protection and have many year runtime so
swap on reboot is cheap policy.

> verification. For example, random people could publish signed statements
> of the latest SHA512 hash of the current consensus for the hour to a git
> repository or other append-only data structure. This repository could be
> easily mirrored widely, and it would be trivial for mirrors to ensure
> the integrity of their copies...

Now if we could get supposedly 'secure' operating systems like FreeBSD
and OpenBSD to use such a repository, such that the source that
appears on their release CD's, FTP sites and replicate checkouts has
strong trace back to the repo. But they refuse to go to git from SVN and
CVS. It likely take a commiter/account breach before proactive happens :(
Until then we'll be running good consensus on bad softwares!
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk