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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
