TorVM structuring question - looking for advice

Discussion in 'privacy technology' started by n33m3rz, Mar 6, 2009.

Thread Status:
Not open for further replies.
  1. n33m3rz

    n33m3rz Registered Member

    Joined:
    Jan 10, 2009
    Posts:
    114
    So some associates and I are working on a project that will be making use of Tor and we have run into quite a predicament in the design stage, a sort of ultimatum between anonymity, encryption and efficiency.

    Here is the general problem:

    We want to integrate Tor into the project, but it has come to our attention (Thanks to steve) that if we use an approach similar to Operator or Tor-portable that we will put the entire systems security at jeopardy because an exploit in Tor could some day surface that would allow an attacker to gain access via the tor client to the main system. This is an unacceptable risk, but it is also unacceptable for us to not use an anonymity network (unfortunately we need to use a free network, although we will likely include support for pay networks such as Xerobank, this is not in this case the answer to our problems as we must include support for a free network as well).

    We decided to mitigate the security anonymity trade off in this instance by using TorVM in place of a Tor portable type implementation. By using TorVM, if such an explot as previously mentioned ever arises it will not be as critical to our system as only anonymity will be compromised rather than possibly secret keys for the other components of our system. This compartmentalizes Tor, so to speak, and makes it fail safe (If Tor fails, the features of Tor [anonymity] fail, but the rest of the system can not be exploited)

    This solution works well but it has a few issues with it. If TorVM is used with the program we are designing being run on the Host OS, it will be very inefficient for the user base, as TorVM forces ALL traffic over the Tor network and as far as we can tell there is no way to tell it to specifically ONLY force the traffic from our program over the network.

    Easy enough solution to this is to run TorVM inside another VM with bridged networking. This way only traffic from the Host VM is forced over the Tor network, and we can make the program we are designing be integrated heavily into a stripped down version of linux, have Tor VM in it, launch with Qemu, ETC... solves that problem.

    This brings up a host of other problems. First of all, using bridged networking to get the host VM to communicate to the internet is at best mildly intrusive to the user, and we are not sure if this is an acceptable inconvenience but if this was the only issue we would be willing to take it. Another issue is that the host VM will be of a substantial size, even if we use a stripped to the core distro of linux. I estimate it will be around fifty megabytes, which isn't horribly bad, but throw in the program itself, TorVM, etc and I imagine the ultimate size of the virtual hard drive would be at approximately one hundred or so megabytes. This is also not horribly bad although it is a bit big and the majority of this size is simply so we can conveniently let the user use TorVM in place of Tor Portable.

    Now the main problem is encryption speeds and plausible deniability. We want the entire program and all of its components to be encrypted with plausible deniability at the lowest level (in this case it would be the virtual hard drive). With OTFE such as truecrypt this wouldn't be a major deal, but we have decided we wish to avoid such systems both for portability reasons and also because they are very complex and difficult to program. We could use truecrypts source code, but we would much rather avoid this. The problem is, benchmarking for non-OTFE of a 100 megabye virtual hard drive shows that encryption and decryption will take a substantial amount of time. If it was JUST the program itself being encrypted and decrypted in this manner it would be a non issue as the program will be very small, but throw in a one hundred megabyte virtual hard drive, plus make it more like a two hundred megabyte file to take plausible deniability into consideration, and we have horrible encryption and decryption speeds.

    A good solution to this problem would be to find a way to get the benefits of TorVM with out forcing all traffic from the host to go over TorVM. I am thinking maybe we can have a Qemu VM with TorVM running inside of it, and the actual program running on the host OS, and configure the program to somehow communicate with the Qemu VM which in turn communicates with TorVM running inside of it? That way we could have TorVM and the host VM not make use of encryption, and could have the actual program itself be encrypted on the host OS and it won't be too slow to be convenient? This though brings up issues of plausible deniability because there will be a pattern of files that can be associated with the program.

    The best option would undoubtedly be to use OTFE and encrypt a shell file that holds a virtual drive inside of it that has a host OS that has the program and TorVM running inside of it (cascading virtualization?), but we are doubtful of our abilities to program something that uses OTFE like truecrypt, we are not entirely trustful of truecrypt with recent events involving them and their forums so we are hesitant to use their source code, and we are not happy with the limitations to portability that comes with using otfe that requires kernel level drivers.

    Another option is to say screw TorVM and go with a Tor portable style system, but we are not willing to accept what we not perceive as a possible security risk that is not made fail safe with compartmentalization.

    So we are really stuck here and really would appreciate advice on the best way to solve this problem, it is really holding up our project. We have pretty much everything else designed and have already got parts of the programming finished, but this part we are really stuck on what to do here and really would appreciate advice.
     
    Last edited: Mar 6, 2009
  2. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    hello n33m3rz, the option of whitelisting or blacklisting traffic that is transparently sent through Tor versus forwarded locally to the gateway could be configurable (and will be at some point).

    you can also use loop-aes or dmcrypt/luks inside of the linux vm's if you are concerned about true crypt integrity. it is also possible to use some hardware crypto accelerators inside a VM, like padlock engine from VIA. (but not the XSTORE hwrandom instruction).

    the hard part of directing traffic in this manner is presenting the user with an interface that is simple and intuitive enough to let them direct applications to Tor or not, yet still be secure enough to prevent side channels or users shooting themselves in the foot. if you're dealing with a known set of applications to proxy through Tor VM then the task is easier.

    best regards,
     
  3. n33m3rz

    n33m3rz Registered Member

    Joined:
    Jan 10, 2009
    Posts:
    114
    Ok I have one more question. How much protection comes by running TorVM versus just Tor? Is it very realistic that a flaw in Tor security could allow a full compromise of all people running Tor / Vidallia, whatever?

    Would it be a major no no to run Tor on a host OS used for highly sensitive information (such as generating and storing encryption keys that decrypt sensitive information?)

    I already understand most of the risks of Tor. For example, lack of encryption, international traffic analysis, etc...

    As far as lack of encryption goes this is pretty irrelevant to our project as encryption takes place client side and then the encrypted data is sent over the Tor network for sorting and storage on a server, a malicious exit node will get a block of serpent-256 ciphertext and we are not especially worried about this. Also since we plan to utilize mostly hidden services which are end to end encrypted anyways, it won't be as big of a deal.

    As far as a massive global passive adversary, we understand that Tor does not offer perfect anonymity and are not necessarily relying on it for anonymity in the standard sense, we see that as more of an additional feature. Sure, a global passive adversary could probably eventually trace down the physical location of a hidden server (in our case this would result in them tracing down a ton of serpent-256 cipher text with random tags applied to them, again not a big deal really). They could also eventually trace down a person using the Tor network (this would be much more risky in our model, but if we use plausible deniability to encrypt everything client side it will protect a great deal from this as well). These things do not worry us much. One of the main reasons we require anonymity is to protect against MIM attacks by a malicious entity with access to the server. We use Tor to anonymously check integrity of server stored public keys (a malicious server wont know who to spoof keys to and who not to, so there is a decent chance if it is malicious it will spoof your own key to you and be detected as compromised in a relatively short period of time)

    What I find worrying is the possibility that an exploit in Tor (either intentional or unintentional) could lead to a malicious entity both tracing the user client down via the tor network (this is bad, but by itself is not catastrophic) AND also remotely gain access to privileged information on said users machine (This would be catastrophically bad as encryption keys, and plain text, could be eavesdropped on and no one would be able to tell).

    So pretty much what I am asking is, compared to TorVM, how well does "vanilla" Tor stand up against such an attack? If you were designing a highly secured communications system that needs anonymity AND security, would you view using Vanilla Tor as being the weak link in the security system?

    Also, you mention that if a specific application needs to use TorVM it would be easier to configure. Can you give me any hints or pointers on where I can go to research how to do this? It is vital for our system to have anonymity, but it is far more important for there to be security, so we can't really go with using Vanilla Tor over TorVM if it will have a potentially devastating effect on security for a moderate increase in convenience.

    Our biggest issue is that TorVM is turning out to be difficult to work with on an application specific level (another issue is it seems to have trouble with some of the WiFi cards we have tested with it). If we can't find a way to easily use TorVM for a specific application and have all other applications access the internet through the normal connection, we might not be able to use TorVM unless it will (and vanilla tor will not) provide protection from the catastrophic security exploit I mentioned earlier.

    We would like to use TorVM, but the amount of virtualization and the major increase in complexity that comes from using it is starting to look like it might not be advantageous over all. In the end of course this depends on just how much more secure a person is to run TorVM versus vanilla Tor.

    Thanks for the feedback!
     
    Last edited: Mar 7, 2009
  4. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    it has happened before; however, the more significant risk that Tor VM mitigates are all the side channel attacks available through OS services, application plugins, and other sources. this is particularly critical on Windows based systems.

    if you get defense in depth, why not take advantage? this goes for applications that can be "virtualized" too. consider a compromised Tor on the host: it could map local services bound to localhost to an .onion hidden service for surreptitious access into your network. a compromised Tor on VM does not have the same access to the host IP stack. there are other examples.

    both good reasons for Tor in a VM. also good reasons to implement other defensive strategies; the fewer paths to critical failure the better :)

    if you are using anything other than the locked down Firefox with TorButton and no plugins on Windows, you should be using Tor VM. otherwise the risks are significant/certain that you are exposed to some types of side channel attacks that will directly reveal client origin IP address and probably other information.

    standard iptables masquerading / redirection is used. you can patch the Tor init script used in the VM to alter firewall rules from the default all TCP to TransPort, DNS to DNSPort. you can mail me privately if you need further assistence, see the code repo at https://svn.torproject.org/svn/torvm/trunk/

    to test on demand, try the alpha archive at:
    https://data.peertech.org/files/demo/testinfo.html
    and run:
    torvm.exe debug
    this will drop you at a prompt in the VM and you can manually tweak the iptables rules to see if the match targets and rules you want are going to work.

    the support for some WiFi cards, Dial-up adapters, and other non-ethernet devices will be implemented in the future; this requires an intermediate level driver for active management of TCP sockets and other network services. there are some tweaks that can be made for other WiFi devices, but wireless bridging is definitely problematic with the win32 pcap device.

    best regards,
     
    Last edited: Mar 7, 2009
  5. n33m3rz

    n33m3rz Registered Member

    Joined:
    Jan 10, 2009
    Posts:
    114
    Ok this might be a stupid question(tm) but is it easy/possible to configure a hidden service on a machine using TorVM?

    After discussing the advantages or TorVM (Reduced risk of Critical Failure, Lower OSI level anonymity, Eliminates risk of leaks) with the disadvantages (No GUI, Moderately intrusive, Doesn't support WiFi, Forces ALL user traffic over Tor) we have decided it is probably best to allow clients the option to pick between TorVM and a Tor Portable style implementation. We are going to be making suggestions of what people use (Tor Portable for users who use WiFi for anonymity, TorVM for users who would otherwise use their own internet connection, TorVM to host the hidden service unless the Hidden service is being hosted on WiFi for anonymity).

    And then it dawned on us that TorVM might not work to run a hidden service. Any advice on the possibility or impossibility of this would be appreciated. Sorry if the answer is right in front of my face!
     
  6. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    yes; but you'd have to do it by hand. you can save changes to the /home/tor directory which is persisted with a 64M XFS IDE virtual disk. other options...

    the forth coming 0.0.1 release includes a bundle mode of operation with Polipo for request pipe-lining and memory caching and Vidalia with (or without) the new 3D Marble widget interface, see https://svn.torproject.org/svn/torvm/trunk/doc/info/marblemap.html

    you don't have to force all traffic over Tor, but you would need to classify what you do and do not want routed over the Tor network correctly and securely...

    i like that option, as it would provide the best flexibility to clients without sacrificing one type of setup or another. also the new MSI based packaging (yet to be adapted into portable Tor VM bundle) share all the same components, so you can swap in torvm for tor and the vidalia, polipo, thandy, license, torbutton, and other software is all shared.

    a hidden service or dedicated relay would probably be best run as its own dedicated Qemu VM instance with its own virtual disk and config. this is trivial to support along side a client VM that is toggle'd on or off. thanks for your feedback; i'd suggest taking a look at the 0.0.1 bundle when released (soon!) and then a second review once the Vidalia control of Tor inside the VM is fully supported. (right now saving config changes from Vidalia doesn't work right, nor do some of the other setup options).

    best regards,
     
  7. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    0.0.1 has been tagged, details slowly percolating to https://www.torproject.org/torvm/ , i expect this to be complete in the next day or so. the Thandy updater repository has the new packages in place too.

    the existing 2D Vidalia is used by default given the size and resource overhead associated with the 3D Marble rendering. if you'd like to try the Marble version grab one of the Marble bundle packages here:
    https://data.peertech.org/files/allpkgs/torvm/index.html

    or simply uninstall vidalia-0.2.1 and re-install vidalia-marble-0.2.1.

    best regards,

    EDIT: here's a view of the widget on win32: http://peertech.org/files/marble-w32.png
     
    Last edited: Mar 17, 2009
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.