Learning from dpr mistakes
A number of public reviews of DPR's infosec mistakes have been published. I think a strong solution to the 'tackled in library' defects would be to have: 1) program to notice his magic bracelet is not near 2) program to notice that vid cam is not a head but a chaotic scene #2 is particularly easy without extra hardware (ca. 2015) You'll have to switch it off when you visit the loo. And of course, things like 'back to wall facing forward' would have been helpful. Claustophilia is a useful trait. I wish to God these calculations could be done by a steam engine," Babbage complained
The feds probably had enough to convict even without his laptops' contents... But yeah, monitoring the environment is a solid idea, as is CPU <-> RAM encrypted pipeline. Internet access is usually the first thing that's cut. (Unless your attacker knows you use it as a trigger, or maybe possibly thought about using it as a trigger.) Travis On Feb 10, 2015 7:28 PM, "David Honig" <dahonig@cox.net> wrote:
A number of public reviews of DPR's infosec mistakes have been published.
I think a strong solution to the 'tackled in library' defects would be to have:
1) program to notice his magic bracelet is not near 2) program to notice that vid cam is not a head but a chaotic scene
#2 is particularly easy without extra hardware (ca. 2015) You'll have to switch it off when you visit the loo.
And of course, things like 'back to wall facing forward' would have been helpful. Claustophilia is a useful trait.
I wish to God these calculations could be done by a steam engine,” Babbage complained
But yeah, monitoring the environment is a solid idea, as is CPU <-> RAM encrypted pipeline.
Someone was talking about this before, maybe in context of VM's. Yet it really only works if after cold boot the key held in core for those address segments luckily happens to be among the nonrecoverable bits of ram. Who has researched those odds? Though defense in depth is always good. Another way is to introduce a simple XOR hardware mask between the cpu and ram, keyed via some external token, wrist fob, etc. Unlikely computer makers respond to little demand for that. And like AMT you certainly don't want it in your "Intel" chipset. Today you might be able to patch a kernel to switch over post bootloader and consider its address space to now be that provided by an external block device (sata/usb), which could then be such an encrypted mini pluggable in the open hardware spirit of the usb RNG devices. It is the ram, so you don't need a long term key there, random generated per boot use is fine. Then you have moved keying issues to a smaller, manageable, quickly blackenable device, like crushing its silicon with a thumbpress.
1) program to notice his magic bracelet is not near 2) program to notice that vid cam is not a head but a chaotic scene
Oh noes, my user's fitbit indicates ballistic heartrate / excess g forces... blacken keys!... :-) Support more drunken ideas, btc: 1k2VQNW47wJDmsLCd2xkSjY28twKRah63
participants (3)
-
David Honig -
grarpamp -
Travis Biehn