Silk Road forums
Discussion => Security => Topic started by: marsvolta12 on January 02, 2012, 09:05 am
-
Silk Road Forums > OVDB > Isolatiing a Linux VM to route through Tor on the host
Or
http://dkn255hz262ypmii.onion/index.php?topic=7833.0
Ok Is anyone doing this? I really trust in the people over at OVDB. However, I have read this is actually counterproductive to anonymity. I still feel like its safer. Will someone familiar with the matter shed some light on this.
Discuses
-
As I just said on the OVDB forum, I found this tutorial that was posted on OVDB to be way more secure:
http://xqz3u5drneuzhaeo.onion/users/secureconfig/tutorial.html
-
Of course you should isolate firefox and other network facing applications using virtualization technology. You can even isolate Tor to a VM that runs a secure OS. Anyone who says this is counter productive to anonymity has no idea what the fuck they are talking about. Don't be confused by police PSYOP agents and the countless people who speak their (incorrect) opinions as if they are certainly factual. It really boils down to this:
If you do not isolate network facing applications, if they have critical remote code execution vulnerabilities (they do, although none may be publicly known at any given time), an attacker can take over the permissions of the application. After doing this, the attacker can deanonymize you without breaking Tor by by passing it on the application layer, for example instructing firefox to send data around Tor to a malicious server. This is only one of many ways the attacker could get your IP address after identifying a vulnerability in one of your network facing applications.
If you do isolate your network facing applications using virtualization software, even if an attacker exploits a vulnerability in one of them and roots your VM, they will not be able to get your external IP address. The VM itself is unaware of your external IP address, only knowing an internal IP address assigned to it. Now the attacker needs to find an additional vulnerability in Tor, or a vulnerability that allows them to break out of the virtualization solution, before they can get your external IP address with a proxy by pass attack. It is worth noting that if an attacker roots your VM they will be able to reduce the anonymity Tor provides you from traffic analysis attacks to roughly the same as Tor provides to hidden services, which is substantially less than Tor provides to non-hidden service clients. This is because an attacker can force a hidden service to open an arbitrary number of new circuits, but can not force a normal client to open an arbitrary number of new circuits. However, if the attacker has rooted the VM of a network facing application that routes its traffic through Tor, they can force Tor to open an arbitrary number of circuits.
Follow the tutorial linked above that OVDB admin made, but do not use polipo. Polipo is insecure and has anonymity degrading bugs in it, and should not be used. Modern versions of firefox allow for socks proxy routing without the need for an additional http proxy, you probably need to allow proxified DNS in your about:config though. Nobody should be using polipo anymore. But do follow the linked tutorial just skip the polipo portions.
OpenBSD provides a wide range of automatic security features which further increases your security from application layer exploits. For example, if you have a 64 bit CPU and or CPU with nx bit capabilities , OpenBSD will prevent an attacker from exploiting entire classes of potential vulnerabilities that may be (read: are) present in your network facing applications.
You may also be interested in reading about mandatory access control systems, like the previously mentioned virtualization technique mandatory access controls offer security via isolation. However, it is harder to use mandatory access control systems to isolate applications from Tor / external IP address.
Law enforcement are going to start doing all of their wiretap and tracing operations on the application layer, because they can't break GPG or reliably break Tor (although they probably can break it for small random selections of users, they can't break it for a given selected target in the majority of cases), but they can exploit one of the endless streams of vulnerabilities in applications like Firefox. They are starting to work with corporations that sell them prepackaged exploit kits for such attacks.
It is worth noting that law enforcement will have a much easier time to trace SR users with such attacks after they have taken over the SR server, although it is not impossible for them to 'leap frog' the server (for one example, GPG has had remote code execution vulnerabilities that allow an attacker to launch arbitrary code merely by having the target decrypt exploit ciphertexts...such a ciphertext could be sent through a secure non-compromised SR server).
It is also worth noting that the NSA stockpiles as mny remote code execution vulnerability intelligence / exploits as possible, and can trace through Tor on the application layer / steal plaintexts / keys on the application layer, with ease.
-
Of course you should isolate firefox and other network facing applications using virtualization technology. You can even isolate Tor to a VM that runs a secure OS.
...
If you do isolate your network facing applications using virtualization software, even if an attacker exploits a vulnerability in one of them and roots your VM, they will not be able to get your external IP address. The VM itself is unaware of your external IP address, only knowing an internal IP address assigned to it. Now the attacker needs to find an additional vulnerability in Tor, or a vulnerability that allows them to break out of the virtualization solution, ...
- not sure what the above segment is trying to say
- the ability of the guest OS working out its external ipaddress or public ipaddress depends on the client and whether it has been forced to use a proxy/socks or not..the
Tor bundle includes aurora (firefox) = "the client", is configured for Tor and probably wouldnt easily be able to determine this external ip bound to the physical router.
- its the OS that is being virtualised, "virtualised apps" is like citrix xen or Novell ZenWorks or where you are running a virtual desktop, a virtual desktop means the
"virtual" instance is running elsewhere and your screen just displays the screen refreshes.
1. guest NAT mode virtual machine
internet---|router----------------host-lan-if
{192.168.0.1} {192.168.0.2}
|
|----vmguest {172.16.1.10}
2. bridged mode virtual guest
internet---|router----------------host-lan-if
{192.168.0.1} {192.168.0.2}
|
|----vmguest
{192.168.0.5}
3. a third mode is private / "guest only" does not give the guest access beyond the host ie internet.
-
- not sure what the above segment is trying to say
Which part in specific did you have trouble to understand? If you isolate firefox from Tor with virtualization, even if the firefox VM is rooted the attacker can not determine your external IP address. Instead they will only be able to determine the internal IP address assigned to the VM, something like 10.0.0.1. The only way an attacker can go from being root of the VM to getting the external IP address is if they find a vulnerability in the virtualbox hypervisor and break out of it or if they find a vulnerability in the code of Tor or anything else that is bound to the virtual network adapter.
Tor bundle includes aurora (firefox) = "the client", is configured for Tor and probably wouldnt easily be able to determine this external ip bound to the physical router.
Tor browser bundle provides zero isolation and if aurora is pwnt the attacker can trivially get IP address. Tor browser bundle includes a security hardened browser that should be used, but it isn't isolated.
- its the OS that is being virtualised, "virtualised apps" is like citrix xen or Novell ZenWorks or where you are running a virtual desktop, a virtual desktop means the
"virtual" instance is running elsewhere and your screen just displays the screen refreshes.
No shit it is the OS being virtualized with virtualbox? I had no idea. Guess what operating systems contain within them. Applications! Some of them need to communicate with the internet to, and those are network facing applications! I am well aware of the different types of virtualization, but right now I am talking about full hardware virtualization systems like virtualbox with host only routing (although there are other networking methods that can get the same result).
Yeah I know about networking too we are so leet
the ability of the guest OS working out its external ipaddress or public ipaddress depends on the client and whether it has been forced to use a proxy/socks or not
Why do you talk in an authorative fashin, like I am wrong, when I know what I am talking about and it is you who is failing to understand the technique? The ability of the guest OS to determine your external broadcast IP address has nothing to do with the browser or tor client or proxy settings , and this is a technique that forces every application to use tor or have no internet access also, in addition to making it so if the vm is rooted the attacker can not use their root position to immediately deanonymize you on the application layer
-
In an ideal world you would be using multiple layers of isolation as well. Virtualbox being used in this way is merely one layer of isolation. Mandatory access controls are another sort of isolation that can be used for similar goals. jails style virtualization can also be used,application virtualization essentially. chroot also offers isolation. systrace is another isolation tool. You want the attacker who pwns your browser to have to go through as many additional isolation layers as possible before they can get your external IP address. Unfortunately isolation isn't perfect, I have heard of security critical chips that use 8 isolation layers being penetrated by skilled hackers.
-
In an ideal world you would be using multiple layers of isolation as well. Virtualbox being used in this way is merely one layer of isolation. Mandatory access controls are another sort of isolation that can be used for similar goals. jails style virtualization can also be used,application virtualization essentially. chroot also offers isolation. systrace is another isolation tool. You want the attacker who pwns your browser to have to go through as many additional isolation layers as possible before they can get your external IP address. Unfortunately isolation isn't perfect, I have heard of security critical chips that use 8 isolation layers being penetrated by skilled hackers.
So what can we do to protect ourselves? If you have time I would love to hear in a PM. You are very intelligent on these subjects and I am eager to learn.
-
kmfkewm just told you what you'd need to do. If you're looking for an out-of-the-box solution, I'm not aware of any.
-
In an ideal world you would be using multiple layers of isolation as well. Virtualbox being used in this way is merely one layer of isolation. Mandatory access controls are another sort of isolation that can be used for similar goals. jails style virtualization can also be used,application virtualization essentially. chroot also offers isolation. systrace is another isolation tool. You want the attacker who pwns your browser to have to go through as many additional isolation layers as possible before they can get your external IP address. Unfortunately isolation isn't perfect, I have heard of security critical chips that use 8 isolation layers being penetrated by skilled hackers.
So what can we do to protect ourselves? If you have time I would love to hear in a PM. You are very intelligent on these subjects and I am eager to learn.
There is no known method of fully protecting yourself from application layer attacks other than having 100% unexploitable code, layering isolation techniques can slow down some attackers (to be fair, most attackers) from getting IOIs (items of interest, in this case your external IP address). Phyiscal isolation (airgaps) can protect you from having your encryption system bypassed on the application layer, but nothing can prevent you from theoretically being traced on the application layer other than correct code. I am not quite educated on the matter enough to say if it is literally impossible to protect from such attacks, but I have heard as much from one extremely skilled hacker friend. I have also heard some whispers about various experimental operating systems and kernels that attempt to make hacking at least a lot harder, and I believe there is some sort of 'provably correct' system formally verified code correctness or something. I wish I knew more about this matter to share knowledge on it, I will look into the formal code correctness methods thingie some more and report back. Oh yeah systems like ASLR can also make it harder to be attacked in this way, but a skilled hacker can by pass ASLR and break through as many layers of isolation as you throw at them, code correctness is the only way to be secure from such attacks but code correctness may very well be more of a perfect ideal than something that can be fully formally verified (this is what im going to follow up on).
As far as secure operating systems go, I would def keep your eyes on some of the research projects of various universities / research groups...qubes is the first that comes to mind but it isn't the most interesting (although it does automatically put every application you launch into its own virtual machine and other cool things)
https://secure.wikimedia.org/wikipedia/en/wiki/Formal_verification
sel4 is a formally verified kernel
In general, security professionals tend to fall into a few sorts of group in regards to what they think the best overall strategy / technique is. I prefer defense in depth and am a fan of isolation, although some hackers I talk with think isolation like this is over rated enormously. Others think isolation like this is essentially a requirement for security. The general strategy with isolation is to add as many layers as possible for the attacker to defeat before they can root the host or gain access to IOIs, and use intrusion detection and prevention systems like snort to try and detect and remove the attacker before they breach the final layer of isolation keeping the host or IOI secure.
-
I never knew about even half the stuff kmfkewm posted here. Good go, mate! Thanks for sharing all this knowledge with us.
I feel a bit stupid that I never knew about the possibility of using chroot like this, since I use it daily for other purposes.
-
While the value of making sure your Vm is secure can't be understated, I'd like to call your attention to another aspect some people might wish to look into. The cost is a bit steep at first but keep in mind it would be less than the retainer for a lawyer should you be prosecuted.
Even with disk encryption, if they want to crack it they will. Most of the time frame quotes you here about encryption like "it would take them over a thousand years to brute force that" are bullshit. Those time scales estimations are routinely based on trying to crack the encryption using cpu power. While this does get the job done eventually, the future is in using GPU computing(using your video card's processing power). It's the same hashing method used in the bitcoin protocol itself. When people solve a block, all they have done is generate hashes until one of them matched the transactions that were being verified. Anyone who has ever mined bitcoins can tell you how much faster a GPU can do this when compared to a CPU. Depending on the encryption scheme and the efficiency of the hashing code, it can cut the time needed to crack an encrypted volume by several orders of magnatude. This makes encryption just one part of a layered defense scheme. To rely on it alone is foolish.
This brings me to my original point. VMs have their image files running off of the hard drive most times, so once the volume is decrypted, they can just load the VM up in its normal software and have access to everything in it. Even worse is that you can manipulate the data in a VM's image file without loading it up and completely bypass all access controls and system permissions. So knowing this, what I did was invest in a device called a ramdisk. How does this help? Well RAM don't hold data after the power cuts out. If you VM is stored and run from a ramdisk, when the police show up, you just pull the plug and no more data for them to screw you with. I have my rig interfaced with a garage door remote on my keyring. One button push and my rig cuts off and all the data in the ram disk goes bye bye.
There are software ramdisks available but they are often limited to a size that's not really useful for holding what I would need unless you buy the professional versions of them. I personally went another route and actually bought a hardware ramdisk card that accepts regular computer ram and resides inside my case.
With as cheap as Ram is these days, i threw 16GB of ram in the card for less than 60 bucks. The card itself set me back about 300 when I bought it. This might seem expensive until you realize that most lawyers are going to ask for a few thousand dollars as a retainer to even take your case.
-
That's a great tip! But it might be impractical for many people. In my neighborhood, it's not that uncommon to have power outages during particularly strong rainstorms. It'd be a lot of work to set everything up again every time that happened.
-
While the value of making sure your Vm is secure can't be understated, I'd like to call your attention to another aspect some people might wish to look into. The cost is a bit steep at first but keep in mind it would be less than the retainer for a lawyer should you be prosecuted.
Even with disk encryption, if they want to crack it they will. Most of the time frame quotes you here about encryption like "it would take them over a thousand years to brute force that" are bullshit. Those time scales estimations are routinely based on trying to crack the encryption using cpu power. While this does get the job done eventually, the future is in using GPU computing(using your video card's processing power). It's the same hashing method used in the bitcoin protocol itself. When people solve a block, all they have done is generate hashes until one of them matched the transactions that were being verified. Anyone who has ever mined bitcoins can tell you how much faster a GPU can do this when compared to a CPU. Depending on the encryption scheme and the efficiency of the hashing code, it can cut the time needed to crack an encrypted volume by several orders of magnatude. This makes encryption just one part of a layered defense scheme. To rely on it alone is foolish.
This brings me to my original point. VMs have their image files running off of the hard drive most times, so once the volume is decrypted, they can just load the VM up in its normal software and have access to everything in it. Even worse is that you can manipulate the data in a VM's image file without loading it up and completely bypass all access controls and system permissions. So knowing this, what I did was invest in a device called a ramdisk. How does this help? Well RAM don't hold data after the power cuts out. If you VM is stored and run from a ramdisk, when the police show up, you just pull the plug and no more data for them to screw you with. I have my rig interfaced with a garage door remote on my keyring. One button push and my rig cuts off and all the data in the ram disk goes bye bye.
There are software ramdisks available but they are often limited to a size that's not really useful for holding what I would need unless you buy the professional versions of them. I personally went another route and actually bought a hardware ramdisk card that accepts regular computer ram and resides inside my case.
With as cheap as Ram is these days, i threw 16GB of ram in the card for less than 60 bucks. The card itself set me back about 300 when I bought it. This might seem expensive until you realize that most lawyers are going to ask for a few thousand dollars as a retainer to even take your case.
Sorry but you are wrong. RAM does store data after it is powered off for a period of time depending on the type of RAM. It has been demonstrated in PoC's years ago.
See: http://en.wikipedia.org/wiki/Cold_boot_attack
Basically LE could simply swipe your ramdisk and drop it in a bucket of nitrogen and preserve the data on it for hours and extract your keys when they are ready.
No LEO is gonna spend the time to bruteforce crack an encrypted hard drive unless maybe you are a terrorist. They will simply bug your computer at the bootloader level and keylog all your passwords and bypass the encryption entirely.
There is also new kernel patches that allow for storing the encryption keys within the CPU registers itself, therefore when it is powered off the key is wiped immediately as the CPU does not hold data for near as long as RAM after a power off, therefore mitigating a cold boot attack. Still won't matter if you are bugged.
-
While the value of making sure your Vm is secure can't be understated, I'd like to call your attention to another aspect some people might wish to look into. The cost is a bit steep at first but keep in mind it would be less than the retainer for a lawyer should you be prosecuted.
Even with disk encryption, if they want to crack it they will. Most of the time frame quotes you here about encryption like "it would take them over a thousand years to brute force that" are bullshit. Those time scales estimations are routinely based on trying to crack the encryption using cpu power. While this does get the job done eventually, the future is in using GPU computing(using your video card's processing power). It's the same hashing method used in the bitcoin protocol itself. When people solve a block, all they have done is generate hashes until one of them matched the transactions that were being verified. Anyone who has ever mined bitcoins can tell you how much faster a GPU can do this when compared to a CPU. Depending on the encryption scheme and the efficiency of the hashing code, it can cut the time needed to crack an encrypted volume by several orders of magnatude. This makes encryption just one part of a layered defense scheme. To rely on it alone is foolish.
This brings me to my original point. VMs have their image files running off of the hard drive most times, so once the volume is decrypted, they can just load the VM up in its normal software and have access to everything in it. Even worse is that you can manipulate the data in a VM's image file without loading it up and completely bypass all access controls and system permissions. So knowing this, what I did was invest in a device called a ramdisk. How does this help? Well RAM don't hold data after the power cuts out. If you VM is stored and run from a ramdisk, when the police show up, you just pull the plug and no more data for them to screw you with. I have my rig interfaced with a garage door remote on my keyring. One button push and my rig cuts off and all the data in the ram disk goes bye bye.
There are software ramdisks available but they are often limited to a size that's not really useful for holding what I would need unless you buy the professional versions of them. I personally went another route and actually bought a hardware ramdisk card that accepts regular computer ram and resides inside my case.
With as cheap as Ram is these days, i threw 16GB of ram in the card for less than 60 bucks. The card itself set me back about 300 when I bought it. This might seem expensive until you realize that most lawyers are going to ask for a few thousand dollars as a retainer to even take your case.
Sorry but you are wrong. RAM does store data after it is powered off for a period of time depending on the type of RAM. It has been demonstrated in PoC's years ago.
See: http://en.wikipedia.org/wiki/Cold_boot_attack
Basically LE could simply swipe your ramdisk and drop it in a bucket of nitrogen and preserve the data on it for hours and extract your keys when they are ready.
No LEO is gonna spend the time to bruteforce crack an encrypted hard drive unless maybe you are a terrorist. They will simply bug your computer at the bootloader level and keylog all your passwords and bypass the encryption entirely.
There is also new kernel patches that allow for storing the encryption keys within the CPU registers itself, therefore when it is powered off the key is wiped immediately as the CPU does not hold data for near as long as RAM after a power off, therefore mitigating a cold boot attack. Still won't matter if you are bugged.
Sorry but it you who is wrong. There's only one type of DRAM chip used for actual computer RAM and it is stateless without power being supplied to it. The actual "memory" in your computer is not like NAND memory used in usb sticks and flash drives. Data stored in NAND is in a persistent state until until altered and requires no power to hold data once it is written. Actual RAM holds nothing persistently. This is why RAM constantly has to have the data refreshed every few nanoseconds. Freezing the ram with liquid nitrogen would do absolutely nothing as the only thing moving in the ram is electrons. It takes quite a bit of time to reach absolute zero (the point at which atoms stop moving as well as their components such as electrons) even using liquid Helium. So lets see here. Power goes off and data is GONE in lets say 25 milliseconds. If the feds have people who can somehow alter the laws of physics and timespace I'm sure we would have heard about it by now so it's not even logical to expect human or machine to be able to remove a physical ramdisk device in that timeframe. On top of that, even liquid hellium could not cool it down fast enough to stop the electrons from dissipating before that data was gone forever. And let's not forget that you'd be shorting out the device by submerging it into Liquid Helium(i keep using helium because liquid nitrogen can't freeze electrons in place so is useless for the scenario you mentioned). So whoever told you that line of bullshit needs to go back to school and get their MS in Comp science as I did and would know what they were speaking about.
Let's also point out the fact that all modern operating systems use memory address randomization to help counter buffer overflow attacks in poorly written software. Even if by some miracle the data got preserved in ram, once the OS is off there is no way to tell what bits were places where in RAM. All that would be left is jumbled masses of binary values with no real way to correlate them to what they belong to. 16 gigabytes = 17 179 869 184 bytes so if you think anyone could solve that jigsaw puzzle then I've got a really nice bridge in SF I'd love to part with very cheaply.
Also, to the guy that mentioned frequent power outages, that's what a UPS system is for. It provides a battery backup if the power cuts out. I use one to keep the power from going out unexpectedly. That's also why I have my system set up to interface with my garage remote. I'm able to turn off the pc on command and still have the battery backup for when the power goes out. And before someone tries to claim the UPS would keep the ram disk alive, not gonna happen. When your computer is turned off power remains flowing to your cmos battery, to preserve your bios settings, and to the circuts used to detect when the power button is pushed. Anything residing in a slot such as PCI, PCIE, or even ISA has no power flowing to it in this state.
-
Can you please cite your sources...
Because Wikipedia has several papers cited that says you are wrong. I am not looking for a pissing match here only the correct answer.
http://citp.princeton.edu/research/memory/
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-536.html
http://www.freeotfe.org/docs/Main/FAQ.htm#de
http://blogs.msdn.com/si_team/archive/2008/02/25/protecting-bitLocker-from-cold-attacks-and-other-threats.aspx
Please don't ignore irrefutable evidence published by academics. I suppose Princeton and Cambridge could be full of shit though.
Obviously it would short it out and they would place it in a water proof bag first to prevent this. They are simply using it to cool it down as fast as possible to preserve memory state.
Yes most operating systems use partial ASLR but it will still not deter a skilled forensic team or hacker. Even full ASLR is not a 100% guarantee.
-
"There is also new kernel patches that allow for storing the encryption keys within the CPU registers itself, therefore when it is powered off the key is wiped immediately as the CPU does not hold data for near as long as RAM after a power off, therefore mitigating a cold boot attack. Still won't matter if you are bugged."
Also forgot to respond to this. The registers in your cpu hold data exactly as long as RAM cells do man. They also have to be refreshed like RAM or they also lose their data. Seriously, pick up a book and actually read up on this. Also, registers are not meant for storing your keys. CPU registers serve two purposes. 1) to hold short term data used in the cpu processing pipeline and to hold long term cpu microcode that affects the operation of the cpu itself. Where exactly do you expect to pull these magical non existent "spare" cpu registers from exactly? Microprocessor fabrication is a business built on economies of scale. They don't design extra transistors and registers into them if they will not be used. Every extra transistor you fab into the chip adds yet another potential failure point and increased chance of a bad yield on the product.
Also you're arguing with someone with a masters in computer science based on shit you read on fucking wikipedia? You just served yourself son. I can cite thousands of goverment papers and studies claiming weed is as addictive as heroin and causes everything from crime sprees to phsycosis. Does that make them true? Hell no because even idiots get bullshit papers published. The things I've stated here come from actual learning, hands on experience working in this field, and basic damn common sense when it comes to the laws of physics.
-
- the lessons here about trying to make a secure workstation host and virtual machine for the purpose of being anonymous, are quite involved and you would have
to know what you're doing.
- you either listen to what the experts say about java, virtualisation or whatever the technology and take their word for it since they probably coded it {not me..} and
choose whether to install or not.
- unfortunately these technical discussions don't belong in a storybook, hence why they are so difficult to follow..
- start with a secure foundation and work your way up layer by layer, you can't always cover everything 100% of the time, but making the mistake of installing a plugin could cost you your anonymity especially if you don't know how it works.
- bugs and security issues come and go, can minimise the risks by making the right decisions on the Operating System (OS) and which vendors you stick with.
- if you're unsure start with a secure setup provided by someone who can be trusted.
:)
-
I never knew about even half the stuff kmfkewm posted here. Good go, mate! Thanks for sharing all this knowledge with us.
I feel a bit stupid that I never knew about the possibility of using chroot like this, since I use it daily for other purposes.
I know OpenbSD has a modified version of chroot that offers decent isolation, but many distros are probably still using versions with chroots that can be broken out of fairly easily. Look into the security of chroot on your distro.
Even with disk encryption, if they want to crack it they will.
Welcome to the 'says a bunch of bullshit' club, if you are using a strong encryption algorithm like AES or Serpent with a 128 or 256 bit key, nobody is going to be cracking it. These symmetric encryption algorithms are even highly resistant to quantum computing attacks that are able to break asymmetric algorithms like RSA (which is often used for session key exchange with GPG). An attacker with a quantum computer with enough stabilized qubits can use Shors algorithm to quickly break this sort of asymmetric encryption, but the best known quantum computer attack against symmetric algorithms is grovers algorithm and it only reduces key size by 1/2 (giving a 256 bit symmetric algorithm the still unbreakable key space of 2^128). Even 128 bit symmetric keys are going to be unbreakable by such quantum computers. And anyway it is likely that nobody currently has any quantum computer with such capability, and if anyone does it is the NSA and they are sure as fuck not going to reveal that they have such abilities by using them against you.
Most of the time frame quotes you here about encryption like "it would take them over a thousand years to brute force that" are bullshit. Those time scales estimations are routinely based on trying to crack the encryption using cpu power. While this does get the job done eventually, the future is in using GPU computing(using your video card's processing power).
GPU does have more processing power for cracking things like encryption than the average CPU does but you still are not going to brute force shit when it comes to strong encryption, even with a large cluster of GPU power.
It's the same hashing method used in the bitcoin protocol itself. When people solve a block, all they have done is generate hashes until one of them matched the transactions that were being verified. Anyone who has ever mined bitcoins can tell you how much faster a GPU can do this when compared to a CPU. Depending on the encryption scheme and the efficiency of the hashing code, it can cut the time needed to crack an encrypted volume by several orders of magnatude. This makes encryption just one part of a layered defense scheme. To rely on it alone is foolish.
If GPU is so powerful then bitcoin is fucked because it relies on algorithms that could then be brute forced, or even the keyspace of the hashing algorithm it uses would be exhausted. You are right that it is foolish to rely on encryption alone, but your reasons for why it is foolish are even more foolish.
This brings me to my original point. VMs have their image files running off of the hard drive most times, so once the volume is decrypted, they can just load the VM up in its normal software and have access to everything in it.
You are entirely missing the point of using a virtual machine for isolation. What you are doing is protecting from an attacker who remotely hacks / roots your VM using whatever network facing applications run in it as the vector. If an attacker does this and you use a virtual machine to isolate the exploited applications, the attacker can not trivially get to the host system from their position in the virtual machine.
Even worse is that you can manipulate the data in a VM's image file without loading it up and completely bypass all access controls and system permissions.
Sure, if you have access to the host OS. Again, you are entirely misunderstanding the benefits of using virtual machines.
So knowing this, what I did was invest in a device called a ramdisk. How does this help? Well RAM don't hold data after the power cuts out. If you VM is stored and run from a ramdisk, when the police show up, you just pull the plug and no more data for them to screw you with. I have my rig interfaced with a garage door remote on my keyring. One button push and my rig cuts off and all the data in the ram disk goes bye bye.
The RAM can be flash frozen for a significant period of time after power is cut, although the exact time frame depends on the specific sort of RAM.
Sorry but it you who is wrong.
I do not know if all RAM can be flash frozen, but I know a lot of it can. I also know different sorts have different data decay rates. However, considering the fact that you have already demonstrated willingness to talk out of your asshole instead of your mouth, I am inclined to think you have no idea what you are talking about. Please show me a citation.
There's only one type of DRAM chip used for actual computer RAM and it is stateless without power being supplied to it.
This I know is not correct, cold boot attacks have been demonstrated against several different sorts of RAM. It is a fairly common misconception that RAM is stateless without power being supplied to it, but it has been demonstrated with several sorts of RAM (all tested afaik) that state decay is not instant upon power being cut, taking as long as ten plus minutes in some cases. I believe this sort of attack was first shown by Jacob Appelbaum.
The actual "memory" in your computer is not like NAND memory used in usb sticks and flash drives. Data stored in NAND is in a persistent state until until altered and requires no power to hold data once it is written. Actual RAM holds nothing persistently.
You obviously have some understanding of computers, but your understanding is that of a 'computer guy' not a 'security expert'. It is a common misconception that RAM instantly loses its state upon power loss, but security professionals have demonstrated and proven that this is not true several years ago now.
This is why RAM constantly has to have the data refreshed every few nanoseconds. Freezing the ram with liquid nitrogen would do absolutely nothing as the only thing moving in the ram is electrons.
Please stop saying as fact things that you have no real idea about. Yes, you are technically correct that the only thing moving in RAM is electrons, however freezing the RAM with liquid nitrogen (or other things, some of which are far easier to work with) will indeed make the state of the electrons persist in RAM for an extended period of time. It also takes a substantial period of time, usually a few minutes, before the state of the RAM decays after power is cut.
It takes quite a bit of time to reach absolute zero (the point at which atoms stop moving as well as their components such as electrons) even using liquid Helium. So lets see here. Power goes off and data is GONE in lets say 25 milliseconds.
Why are you wasting your time making shit up and talking about things you don't know about? Let's try to keep the information here high quality and accurate instead of pulled out of our assholes please.
If the feds have people who can somehow alter the laws of physics and timespace I'm sure we would have heard about it by now so it's not even logical to expect human or machine to be able to remove a physical ramdisk device in that timeframe.
Your entire hypothesis is incorrect so you should stop basing your argument off of it.
On top of that, even liquid hellium could not cool it down fast enough to stop the electrons from dissipating before that data was gone forever. And let's not forget that you'd be shorting out the device by submerging it into Liquid Helium(i keep using helium because liquid nitrogen can't freeze electrons in place so is useless for the scenario you mentioned). So whoever told you that line of bullshit needs to go back to school and get their MS in Comp science as I did and would know what they were speaking about.
Blah blah blah more wrong information. This attack has been demonstrated, you can see the entire thing carried out on youtube for fucks sake not to mention the attack has been in published papers for a few years now. Any computer security should know about this attack by now, so maybe it is you who should go back to school in computer security instead of unrelated computer science fields.
Let's also point out the fact that all modern operating systems use memory address randomization to help counter buffer overflow attacks in poorly written software. Even if by some miracle the data got preserved in ram, once the OS is off there is no way to tell what bits were places where in RAM. All that would be left is jumbled masses of binary values with no real way to correlate them to what they belong to. 16 gigabytes = 17 179 869 184 bytes so if you think anyone could solve that jigsaw puzzle then I've got a really nice bridge in SF I'd love to part with very cheaply.
Not all modern operating systems use ASLR (freebsd comes to mind) and many of the operating systems that use any ASLR do so to a limited extent (thus not having full ASLR). Well, you know the key size of encryption is 128 bits of randomness or 256 bits of randomness, so I guess you could just filter out everything that isn't random and then make a dictionary of all 128 and 256 bit strings of randomness that are left. ASLR doesn't randomize the content of ram it randomizes where data is stored in RAM. Stop talking out your asshole.
Also forgot to respond to this. The registers in your cpu hold data exactly as long as RAM cells do man. They also have to be refreshed like RAM or they also lose their data.
This is true. The only way I have heard of protecting from a cold boot attack when the attacker actually has physical access to the machine is to use encapsulation material to slow their ability to access the RAM, and intrusion detection systems to begin a wipe process in RAM as soon as physical penetration of the case is detected. Even systems that use encapsulation material and similar systems for protecting RAM have been defeated by military hackers, I read about one hacker who worked for the united states government using a combination of I believe liquid helium and an acid wash to remove the encapsulation material from flash frozen RAM, and then he used a highly precise tool with a tip on it about the width of a human hair to obtain the state of the memory. Sorry I can't explain this attack in more technical detail, it is beyond my level of expertise, but I will try to find the article.
Seriously, pick up a book and actually read up on this.
Given the large amount of bullshit that you have said I think you have no place in lecturing other people on reading up on anything.
Also you're arguing with someone with a masters in computer science based on shit you read on fucking wikipedia? You just served yourself son. I can cite thousands of goverment papers and studies claiming weed is as addictive as heroin and causes everything from crime sprees to phsycosis. Does that make them true? Hell no because even idiots get bullshit papers published. The things I've stated here come from actual learning, hands on experience working in this field, and basic damn common sense when it comes to the laws of physics.
If you have a masters in computer science I really am impressed with myself that I have managed to become self educated past the point of a masters degree so quickly! It really is hard to determine my skill level considering that fact, but I routinely do find myself pwning the shit out of anyone who has recieved their computer/security training from a school or corporation. He is basing his argument about RAM on a paper / attack discovered by Jacob Appelbaum, a well known security professional and one of the Tor developers. You really have pwnt yourself very hard if you are not trolling.
-
Hi there chaps, I am also self taught when it comes to IT and there have been a couple of items on here that I didn't know (thank you to those who know their stuff - you know who you are), but I have to agree with kmfkewm, a lot of what xx138xx says is baseless and inaccurate. Sure there are some fancy sounding terms but a lot of it smells like BS.
My coffee nearly spurted out of my nose in mirth when I read about quantum processing. Ah, this has really cheered me up! I'll be keeping my eye on this thread for both sensible security suggestions and complete rubbish that makes me smile.
Thanks guys!!
-
Cheers to kmfkewm, for being even more informative and a lot less of an asshole this time around.
Be honest, doesn't it feel nicer to act nicer?
-
Keep up the good work, guys. This is good google juice...
I have to admit, after reading up on Qubes and Joanna Rutkowska (and her partner) it seems like an amazing system. kmfkewm, what are the issues you see with it? Do you think hosted virtualisation, like the method discussed in this thread though not necessarily used the same way, could provide a better security solution?
-
I have no issues with it really, its a really cool system and she is a smart security researcher. Qubes focuses on isolation, one of the three main strategies used by security professionals. The other strategies are correctness and randomization. Many people prefer defense in depth and like to layer the techniques as much as possible. I talk with some very very good hackers, and it is a bit surprising how much their opinions differ. Some are huge fans of using virtual machines for isolation, others think that it isn't going to stop a determined attacker (after all hackers are apparently penetrating through 8 layers of isolation in some cases). People who are big on correctness tend to use two main strategies, intensive code audits by experts looking for bugs (OpenBSD) and mathematical proofs of correctness (formal verification, like the sel4 micro kernel). The first technique allows for larger code bases to be audited, and is quite good at removing potential security vulnerabilities before they are exploited (and all together after a while). Formal verification apparently allows for a mathematic proof of correctness, but is extremely time consuming to do even for experts, and this has so far limited the ability to verify much more than micro kernels. In either case, only the audited or formally verified components can be expected to have a very high or perfect degree of correctness, and in most cases users are adding applications that have not been held to such high standards. There have not been extremely large code bases with such intensive auditing and very very little has been formally verified. Randomization attempts to protect from attacks like buffer overflows even if there are vulnerabilities in code, unlike isolation it attempts to prevent an attacker from gaining any access to the system (isolation attempts to contain malicious access).
Most operating systems come with a variety of tools for getting security in a few different ways, but some are better for other types. For example OpenBSD has very highly audited code in its base install, and default full address space layout randomization, but it doesn't have much support at all for virtualization solutions and it has no mandatory access control system. The OpenBSD devs are security experts who seem to think pretty lowly of most types of isolation, although they do have two tools for isolation with OpenBSD, systrace and a hardened chroot.
Likewise, Qubes has a minimized code base and probably a significant degree of correctness but they really focus more on the security benefits of isolation than on having intensive code audits. I am not sure if Qubes supports ASLR or mandatory access control systems, I will need to look into it more.
Anyway I think Qubes is great but it really is better as a framework to build something else on top of , or to copy the concepts from. I would prefer to configure things with multiple layers of isolation used.