14 ms·
I did some research work last semester on crypto inside VMs. One of our initial readings was Yilek's work on attacking VM crypto through VM snapshots http://cse
by stipes 15y ago
I did some research work last semester on crypto inside VMs. One of our initial readings was Yilek's work on attacking VM crypto through VM snapshots http://cseweb.ucsd.edu/~syilek/ndss2010.html http://cseweb.ucsd.edu/~syilek/ndss2010.html
- tptacek 15y agoThat's an interesting trick but not really representative of the problem. Reusing an RNG's entropy pool wholesale after restarting a snapshot is a mistake, not a design flaw.
- stipes 15y agoPart of the problem is the conflict of transparency and security here. Fixing the wholesale reuse of RNG state would most likely require modifying the guest so that it is aware of being restarted from a snapshot so it can react appropriately. However, that might have consequences on what restoring from a snapshot means conceptually.
- yuhong 15y agoHow about having a command to manually reseed the PRNG?
- tptacek 15y agoYou mean like write(2)? :)
- stipes 15y agoYes, in general write to /dev/random with the write permissions is how entropy gathering daemons and the like work. It gets added the input and mixed in. However, that doesn't fix the issue of how a snapshot restore works on most hypervisors. Adding an RNG refresh as part of the restore process could be possible, but definitely not trivial, and it could have other consequences if not carefully implemented.
- yuhong 15y agoNot to mention that if you let untrusted people control VMs on the host side, you have bigger problems than this attack.