From: Tim Churches [mailto:[EMAIL PROTECTED] > Sent: Friday, 22 October 2004 1:09 AM > To: 'Horst Herb'; '[EMAIL PROTECTED]'; > '[EMAIL PROTECTED]' > Subject: RE: Virtual Privacy Machine > > > From: GPCG Talk List [mailto:[EMAIL PROTECTED] On > > Behalf Of Horst Herb > > Sent: Friday, 22 October 2004 9:53 AM > > To: [EMAIL PROTECTED] > > Subject: [GPCG_TALK] Virtual Privacy Machine > > > > The seems to resolve many of our security problems arising > > from inadequate choices of software and operating system: > > http://pvpm.metropipe.net/ > > > > I will review it and comment when I am finished, but this > > looks like something EXTREMELY promising, and might even be > > expanded to a complete electronic heath record system on a > > USB stick (not just the data, but the software to view and > > modify the health records as well) > > Yes, this is extremely clever and extremely interesting. The > innovative part is that it does not require you to reboot the > computer into which you plug the USB memory stick. Instead, > it loads a CPU emulator (they use QEMU) under the currently > running operating system - Windows or Linux - and then boots > a completely separate Linux operating system inside the > emulator. This emulated Linux environment is configured to > only store data on the USB memory stick, so there is no > danger of inadvertently leaving security-sensitive data on > the host machine which may be your computer, or it may be > someone else's computer.
Unfortunately the reality is not so great. The performance of the Linux session running in the emulator is pretty poor - for example, using Firefox in the emulated session to access and interact with some Web-based forms via HTTPS (SSL/TLS) was barely acceptable on a 2.4GHz Pentium 4 machine (running Windows XP as the host OS). Still pretty cute to have a Linux session running under emulation in a window under on a machine booted with Windows XP. > This has several implications: > > A) It provides an excellent environment for accessing > privacy-sensitive Web sites, such as one's bank accounts, or > one's Web-based EHR. It is a much under-appreciated fact that > the biggest security vulnerability with Web-based > applications is the client-side browser and all the > information it leaves behind, such as cache files, cookies, > stored passwords and other automatic form fill-ins. Things > like Google Desktop Search (see http://desktop.google.com/ ) > now make it incredibly easy to access all this > stored-or-captured but not-directly-visible information. > > If you always use the same computer, and you are the only > person to use that computer, none of this matters too much, > but that situation is quite rare. At the very least, every > computer is in some danger of being lost or stolen at some > stage. Yes, you can use an encrypting filesystem to protect > every file stored on a machine, but how many of us actually do that? > > Up until now, it has been possible to use a bootable Linux > distribution like Knoppix or one of its many derivatives to > overcome this problem, by storing all data on removal media > like a USB memory stick. Knoppix provides excellent > facilities for doing this, including encryption of the entire > data partition on the USB stick. However, the need to reboot > into the Knoppix or similar environment is often inconvenient > - you need to close what you are doing, and if it is not your > computer, the owners often get a worried look on their faces > when they see a strange version of Linux booting on their > machine. This Virtual Privacy Machine overcomes these objections. Despite the performance issues, I think there may still be some promise in this approach. However, I am beginning to think that specially customised versions of Firefox which leave no traces of a browsing session might be a better bet. Such browsers would have to be resistant to the techniques which allow things like Google Desktop Search to capture every page browsed via an encrypted (HTTPS, SSL/TLS) browsing session in Internet Explorer (discovering that Google Desktop Search could do that was a real eye-opener to me). > B) PKI key generation, storage and use. There have been two > broad choices for the generation, storage and handling of PKI > keys and certificates until now: > > i) generation, use and storage of the keys/certificates on a > general purpose computer - thus exposing the private keys to > possible compromise via all the security holes and flaws > present in general purpose computers used for everyday things. > > ii) Generate, store and process the private keys/certificates > on a device which has an embedded processor and > special-purpose operating system and software (typically a > dongle, memory card or stick) - all access is via an API, and > private keys are never transferred to the host computer. > Typically a password is also needed to unlock the private > keys on the cryptographic hardware module. Disadvantages of > this approach include the cost of the special-purpose > hardware device, and the fact that they are proprietary, > which means you must trust the manufacturer to have gotten > everything right - and there are several examples where this > has not be the case. > > However, this Virtual Privacy Machine seems to offers an > interesting middle path between the two: two-factor security > due to the physical device (the USB memory stick) which one > must possess, as well as a password to unlock it; and, as the > name implies, a virtual private environment in which to do > cryptographic and other processing - sure you are still using > the host computer's CPU - but nothing else - in particular > you are not using (and thus having to trust) the host > computer's operating system or other files, and you are not > using its hard disc. On further reflection, there is an obvious flaw with this scheme: the password used to unlock the certificates stored on the USB can still easily be captured via a keyboard logger or similar, PLUS the entire contents of the USB memory stick can, of course, be copied off the USB stick and onto the host computer's hard disc (or somewhere else) without the user being aware. If this happens, then even if you take your USB stick with you when you are finished, you are still hosed, because its entire contents may have been copied off it right under your nose, and can then be decrypted or unlocaked with your captured password. Oh well, it was superficially a nice idea... > The real advantage is that the hardware part is a commodity > item - any USB memory stick will do - and these are now very > cheap - as opposed to a proprietary cryptographic device > which tends to be expensive due to their low volume. Add to > that the open source nature of the software components, and > the fact that the system is far more general-purpose than a > cryptographic device, and it has to be a winner. Alas, the fact that the USB memory stick is mounted as part of the host computer's filesystem means that its entire contents are vulnerable to being copied - as noted above. A dedicated cryptographic device does not suffer from that defect as it can only be accessed via its special crypto API - which does not allow wholesale copying of its contents. > I think that government agencies and other organisations > which are promoting both Web-based access to > privacy-sensitive EHRs by health professionals and, most > importantly, by patients, should look into this project and > invest in its further development. Likewise, government > agencies and other organisations which are promoting PKI > regimes for use by health professional and agencies should > look into this project and invest in its further development > as a cheaper, more flexible alternative to proprietary > cryptographic devices, and as a more secure alternative to > "soft certificates" or keys store on PC hard disks. I still think various parties need to pay more attention to the issue of Web browser client-side security - because the use of HTTPS and SSL to secure transmission between browser and server does NOT magically make the session secure. The ready availability of Google Desktop Search is going to cause a lot of heartache, because everything which transpires in an Internet Explorer session, even one encrypted via SSL/TLS, is captured to the local Google index. It is then available for you or anyone else who has access to that computer to search and view at their leisure (because every page is cached in the local index). It represents a real challenge for anyone wishing to provide or collect privacy-sensitive data via Web browsers. Non-IE browsers are currently immune from Google Desktop Search, but not for long they plan to add capabilities to index sessions in Firefox, Mozilla very soon, apparently. Tim C
