> On Sat, 10 Dec 2011 20:06:10 -0500, Chris wrote: >> > On Fri, 9 Dec 2011 17:29:33 -0500, Chris wrote: >> >> >> [...] >> >> >> Many users have a persistent local threat that they need to be >> >> >> aware of. Leaving a server running is not an option as it could >> >> >> be compromised by an adversary. >> >> >> >> >> >> Removable media can reduce that threat. >> >> >> [...] >> >> >> >> I was not referring to zero day exploits actually. The key word >> >> here was local real-world threats. Such as an adversary gaining >> >> physical access to the server/machine running freenode. >> > >> > If the bad guys have physical access, and care, it's game over. >> > >> > I suppose you can try setting secret tripwires that might notify you >> > if the machine was tampered with (both in software, and in >> > hardware.) Those might give you a fighting chance. Although you'll >> > also need to make sure your room wasn't bugged with pin-hole >> > cameras and other spy-ware. It's a lost battle, regardless. >> >> This is completely dependent on who the adversary is, the level of >> sophistication, mistakes they may make, the resources they may have, >> how badly they want you, what they know about you, and what other >> precautions have been taken. A pin-hole camera for instance should >> not be enough to compromise a good setup. > > How do you figure? (The camera can see everything you're typing and > your screen, right? If you have any additional biometric login > requirements, they can easily be gotten from you later.)
Where exactly is this camera placed? This is dependent on the user being position such that a camera can see the keyboard. > >> Nor should a MBR level key logger installation. These two things are >> easier to do than a BIOS level modification. A BIOS level >> modification gets a lot more complicated as each system uses a >> different BIOS. When there is no generic solution to a problem or >> that solution is more cumbersome it may not exist. If it does exist >> it may be used much more selectively and there will almost certainly >> be fewer adversaries who have access to it. You may not be a target >> of a significantly high level adversary (where such levels may exist). >> >> > >> >> Removable media may not eliminate the threat although there is less >> >> opertunity for a more sophisticated targeted attack. A software >> >> keylogger inserted into the MBR or similar would not be possible if >> >> the boot medium is never available to the attacker. >> > >> > But it will be available if you ever decide to boot, happily >> > recording everything. >> >> If the adversary does not have access to your boot medium how do you >> think they are going to install it? When you do boot it should not >> exist. There are few places that a keylogger or device can be >> installed. BIOS, optical drive, USB port, PC card slot, firewire, >> network etc. These are all things that can be checked. The only >> exception is the BIOS. The BIOS differs from machine to machine which >> should increase the cost of the adversary to produce a solution. I >> have never heard of a BIOS level bug. There have been conceptual >> modifications to suggest it may be possible although nothing in >> practice to show it could be done easily. >> >> >Again, if you think your machine was actually tampered >> > with, you should assume it's unusable. >> >> Nobody is arguing that a knowingly compromised machine or one that >> there is reason to suspect could have been compromised should be used. > > But any machine that the adversary has physical access to should be > suspected to have been compromised. A BIOS-level bug, as you explain, > is one great way. Personally, I would prefer lower-tech spy solutions. > Of course, you can assume your adversary is weak, but that's a risky > assumption. If I'm the adversary the question becomes how do I go about producing a bug for every machine that I might come across that I would like to bug? Porting BIOS modifications from one motherboard to another is a non-trivial task and would be prohibitively expensive. Probably even for the wealthiest nations on earth. There are easier ways to bug that .0001% of the population who might have a bug-resistant setup. Of that .0001% there are probably a handful currently whom a BIOS level bug would be needed. There are projects out there to port an open source BIOS and there are at best 100 boards which are supported. Of that there are just 5 laptops. If you think 5 models is a lot think again. Of any specific laptop it takes a specific revision of that laptop. This is a project which has bee around for many many many years with financial support from governments and corporations. Even if we assume the governments have access to the original source code to every BIOS (which you would have to have one for each model and revision of every laptop) it is still going to be expensive. Who are you that the government is going to have the technical persons on hand to arrange and have modified and then secretly install such a BIOS? I would put money on them taking advantage of zero day exploits and/or the courts to force the Tor project, the Freenet project, the i2p project, or any other similar project to modify the code and insert a back door. Germany did this many years ago with one project and successfully identified a user. It was none of the above projects although the ability to force upon developers code changes that go out to all users has occurred. They were targeting one individual too that appeared to be a fairly low-value target. The only thing that might stop this from happening to other projects is where the developers are operating in one country and the government attempting to force the change is in another. > > >> >> On the other hand a physical keylogger may still be possible and >> >> maybe even a software based keylogger although more difficult to >> >> disguise/install without being noticed. >> > >> > Of course. You should expect a variety of key loggers installed, in >> > code, under your keyboard keys, acoustic key loggers stuck somewhere >> > inside the machine (that can acoustically determine which key you're >> > pressing), and a bunch throughout your room in pin holes in your >> > walls and ceiling. >> >> None of which can't be avoided. As far as I know. > > Please explain. > Point me to an example of a specific situation. An acoustic keylogger requires keyboard clicks. If the user doesn't enter a password on the keyboard there won't be anything for the acoustic keylogger to record. There is potential interference too which can trouble such acoustic keyloggers. A pin hole camera requires installation somewhere. If it is too close to the laptop it will be apparent. Despite being small these camera do have to exist. To far away (ceiling) and you won't have a view of the key strokes. Take a pin some time an put it through the ceiling. I've done this for other reasons (running cabling) and you can clearly see a dark spot where the tiny pin made a whole. While you do have to look for such things it is apparent. You don't even need to do anything more than look up. The whole would probably be too small anyway. Plus A keyboard can be covered while typing a password. There is potential for monitoring electromagnetic emissions. It has been suggested there are some dictatorships using this method. It is a real and potential threat although not one which can't be reduced through various means. There are means of doing this in software and physical barriers which can seriously reduce this risk. Think about what happens when you want into some buildings with a cell phone. > >> >> I can think of at least a few different ways of getting a keylogger >> >> onto a system without having access to the boot drive or having to >> >> install a physical device. I would still need physical access to >> >> the computer. At least one method would not even require BIOS >> >> modification and would work on any x86 machine. >> > >> > So you're already aware that there is not much hope if the bad guys >> > get physical access? :p >> >> I disagree. Most "bad guys" aren't as sophisticated as one might >> think. Including the ones coding the bugs and exploits used. They >> will create a bug and assume it works. In reality it only works if x, >> y, and z are true. Provided you have taken sufficient precautions >> this rarely is the case. Most adversaries need not be sophisticated >> at all. They merely need to carry out a set of instructions found >> somewhere. Be it they ordered a physical keylogger online or followed >> an instruction set of procedures that works for 99.98% of targets. >> There will always be a small percentage who are less vulnerable. The >> steps needed to be less vulnerable should be reduced as it makes any >> given adversaries job that much harder. >> >> > >> >> [...] >> >> Lets give a scenario: >> >> >> >> We have to assume that a persons Internet connection is being >> >> monitored. This might be via a sophisticated non-governmental actor >> >> (such as by breaking WEP/WPA) or by a government act such as >> >> monitoring at the telco. The adversary should also be assumed to be >> >> "unethical" in that there are no rules >> > >> > In that case, if you're using only opennet-mode, you should assume >> > you're screwed :p. They can replace all your opennet peered nodes, >> >> I don't think you know what you are talking about. How do they replace >> your opennet peers WITHOUT physical access to the machine? > > The whole point of opennet is to be able to connect to anybody you > want :P. And if your ISP is compromised, this becomes even more trivial > -- they can block all but their own seednodes, so you're forced to only > connect to their bugged nodes as peers. This should become apparent to the user and if is not made apparent that is a problem with freenet (or whichever project you would be suggesting). > > >> There should be authentication which prevents this. I'm not sure what >> the difference between opennet and darknet modes are. If a few peers >> are compromised ideally you should not be compromised. This is at >> least until a sufficient number of peers are compromised. > > Here is a more comprehensive explanation of attacks: > http://freenetproject.org/faq.html#attack > > Apparently even if *one* of your peers is compromised, there's still a > possible attack: See "Correlation attack" in the above link. I'm familiar with this attack. I don't know how it impacts freenet specifically. It requires an all-knowing adversary usually and probably is not definite. There are also methods implemented or may be implemented to help thwart these attacks. > > In darknet, you *explicitly* specify who to connect to (hopefully a > trusted friend), and you don't connect to anybody else. So, to > infiltrate this setup, the bad guys would have to physically compromise > your friends' nodes, one by one. To infiltrate opennet, they just have > to type on a keyboard in the comfort of their homes. If you could trust your friends there wouldn't be any need for freenet. The problem is you can't trust anybody. > > >> > and >> > see exactly what you're doing, more or less. This is why >> > darknet-mode was created -- they would need to physically >> > infiltrate all your friend's computers, which isn't impossible, but >> > MUCH more difficult. >> > >> >> Ok >> >> >> and can physically modify or otherwise install a software based >> >> monitoring solution on any boot media they have access to. >> > >> > Then you're *definitely* screwed, regardless, as explained above. >> >> >> I don't think you followed. They would not have access to the boot >> media of the machine you are running. > > Didn't you just finish explaining how BIOS-bugs would work -- albeit > from a sophisticated adversary? I would assume my BIOS is bugged. (Not > to mention all those keyloggers and cameras! Did I mention the > x-ray cameras that can see through your walls at your finger bones? :p) > Assuming your BIOS is bugged is pretty big assumption. You might as well give up! As I've indicated here this is probably less of a threat. Other methods are probably easier. I'm doubtful any government would use x-ray specifically. There are means of monitoring through radiation leakage. The MBR trick on the other hand would be generic and easiest to develop. It is also easier to thwart. > >> I was referring to just the one freenode peer here that was setup for >> you to connect with that operates within the same LAN. Not the >> machine you use to browse freenet. >> >> > >> > >> >> The first question is how many peers need to be compromised to >> >> identify the content being transmitted? >> > >> > All of them, to be 100% sure. Compromising opennet peers is trivial >> > -- with a dedicated-enough adversary. Compromising darknet is a lot >> > harder. >> > >> > >> >> Ok- fair enough. >> >> >> If a few of your freenode peers can be compromised and the >> >> adversary can monitor your Internet connection and local area >> >> network can they identify the contents which are being >> >> requested/sent by you? This assumes that they can't bug the >> >> physical machine that you are using to run freenode. >> > >> > As long as you still have one uncompromised peer, I guess they >> > can't be sure what traffic you're generating locally, and what >> > you're simply relaying for that peer (or that peer's peers, etc). >> > But if they're able to compromise all-but-one of your peers, it's >> > pretty darn close to game-over :p. If I was an unethical bad guy, >> > I'd arrest you and that peer, separate you into isolation-cells, >> > and play psychological games until one of you confesses. Or perhaps >> > torture. (Although, if that other peer doesn't have anything to >> > hide, or isn't your friend, I'd easily jump to the conclusion that >> > you're the one I'm looking for :). >> >> There are different scenarios where the above may be true and not all >> have the ability to gain physical control of you even if they can >> gain physical access to the machines. I see you are assuming a law >> enforcement type organization of some type or maybe military. >> >> > >> > >> >> If you add a server with freenode (which can be bugged) to your >> >> local LAN that is then added as one of your peers does this >> >> compromise the security? The point of adding a server with >> >> freenode to peer with on the local LAN would be to speed up >> >> requests since the machine that is actually used for browsing >> >> freesites (such as a laptop) can't be left on all the time (as >> >> doing so gives an adversary opportunity to bug it). This means it >> >> has to run from a removable boot medium that can be accounted for >> >> at all times. >> > >> > Overlooking the above points about physically-tampered machines (we >> > *really* shouldn't overlook them), I think this setup essentially >> > means that you can expect one of your lan peers to be compromised. >> > But, as long as your router isn't bugged, and as long as that peer >> > isn't the only one you're connected to, you should be relatively >> > safe. (But if you suspect any of your peers are bugged, you should >> > *really* be considering other options.) >> >> If the server is compromised you have to assume the Internet >> connection is being monitored here too. >> >> I wouldn't think that monitoring the Internet connection would reveal >> the contents. Adding a local-LAN compromised peer shouldn't either (I >> would think). >> >> >> > _______________________________________________ > Support mailing list > Support@freenetproject.org > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:support-requ...@freenetproject.org?subject=unsubscribe > _______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
