Slashdot Mirror
Security in Wireless Networks
Asmodeus writes "Those boys at Cambridge have done it again. The Resurrecting Duckling (where do they get these names ?) is a description of the security problems in ad-hoc
wireless networks with some nifty solutions to the problems." Its a really interesting techie bit actually. Talks about problems with low power, wireless boxes. Its strange to think that in wireless world, for example a denial of service attack could be anything designed to drain your battery.
However, 100% is still only a x2, not a x100. The x100 is often quoted as the degree of idleness of a machine used for desktop WPing, but it's certainly not a typical figure.
Poor coding exists, but it's certainly not THAT bad. Linux utilizes the CPU better than Windows, true, but it's code still is a long way from optimal. The TCP stack needs work, for example - the BSD stack is certainly faster, and that's still by no means perfect.
But poor coding isn't the only factor. Linux is designed to be multi-platform, and generic code will ALWAYS be slower than tightly-written, heavily optimisd routines. That's the nature of the beast. You can't be both generic AND take advantage of every little trick a specific CPU or device may have.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Maybe I'm missing something, but the idea of imprinting sounds a lot like what my garage door opener does now.
I've got one of those rolling code models from Sears where you have to hold the opener to the remote while pushing a button on each. The door can then be opened by the remote which itself can be programmed to handle three different openers. (Maybe you have more garages than I do. *shrug*). Seems to me that it fits the model discussed here a bit.
Can someone let me know if I've got this or not?
Uhm... no. I mean, in -principle- you're right, because of equivalence... any CPU powerful enough to be a Turing Machine can do anything any other CPU can. In theory.
... the security issues between 8088 and PentiumIII aren't the level of utilization, but the lack/existence of a protected mode, DMA transfers, bus protocols, etc. I'm not an expert, so I couldn't even start to tell you how we can be sure an OS is or is not secure against software taking advantage of hardware architecture.
In practice... well, unlike the imaginary Turing machine, CPU's do not have an infinite amount of memory. If you take an ordinary 8088 and its motherboard, you just can't -have- more than 720K of memory. It's not possible.
Now you -could- put some memory sockets on an ISA card and write a protocol to utilize that memory, etc, but a complete 8088 machine is limited by memory.
With those memory limitations, it is not possible to perform calculations that take up more memory than that!
Unless, of course, we use virtual memory... so... now, with disk-access speed memory, we write a Win95 Emulator (never mind the difficulties in context switching and utter lack of runtime security caused by the lack of a protected mode) and now we're off! We download and install Quake V (it's been a few years since we started this project, you see, a couple more versions came out) and run at... 1 frame per week.
Maybe we try something less ambitious... printing out a pdf document... at one page every six hours.
No, I'm sorry, we utilize -much- more than 1% of our computing power in -many- everyday tasks, and what is theoretically 'possible' with older CPUs is -not- the same as what is feasible.
Besides which,
Obviously, -NO- OS is secure against actual tampering with the hardware directly. After all, the tamperer could always replace the OS with his own boot disk. But that, too, has little to do with the difference between 8088 and Pentium III...
--Parity
'Card carrying' member of the EFF.
The first constrain on the system is that of a "peanut CPU". "The consequences of [this contraint] is that, while strong symmetric cryptography is feasible, modular arithmetic is difficule and so is strong asymmetric cryptography." Because of this, these devices cannot use IPv6. In general, the specification clearly shows why conventional solutions to these problems do not apply to these classes of devices.
-no broken link
Bear with me if you will while I make this association.
I'm very interested in wireless and like the authors of this paper, I think it will be very important in the coming years. But I've never thought about things like this 'sleep deprivation attack' they were talking about. To me, this demonstrates one of the most powerful things about the open source/free software community, the fact that there are smart people thinking in ways others wouldn't. When big companies put a group of smart people together, they may very well come up with a great product but they probably won't be able to think of every attack/feature/etc that a larger interested group could think of.
Another example of this is the development of so-called "side channel attacks" in cryptography. People have used things like battery drain, EMF radiation signatures, and others, to attack smart cards and their ilk. Certainly the designers of the smart cards were assured their crypto was up to snuff but they hadn't counted on these side-channel attacks. If this hadn't been discovered until everybody had a smart card in their wallet, it would be a huge catastrophe.
Open thinking is a bit difficult for most big corporations to do, but I think things like this paper will help bring them around. The time of believing that a small group can design important projects in a closed manor is almost finished, there are too many smart people around thinking in new ways.
I know this is a little offtopic but that sleep deprevation attack got me thinking. Which, I guess, is the point.
To do quantum computing and quantum communication you have to have perfect control of the system, and prevent absolutely any interactions between it and its environment.
As a theoretical excercise quantum algorithms are certainly fascinating; but I suspect that in reality a quantum computer with enough completely isolated and non-interacting 'gates' to run the factorisation algorithm is unlikely ever to be achieved.
Similarly, quantum communication might work along optical fibres or tightly focussed laser beams, but I think you would have a lot of problems trying to detect the very subtle single-photon correlations using wireless against a noisy RF background.
But I'd be delighted to be proved wrong on either of the above!
Obviously, -NO- OS is secure against actual tampering with the hardware directly. After all, the tamperer could always replace the OS with his own boot disk
That's not obvious at all. For example, what do you (the invader) do if there's no floppy drive? Start pulling chips? What do you do if there's a floppy drive, and there's no password protection in the bios, you can boot from your floppy, but the file system is encrypted? Or any number of other simple obstacles that could be placed in your way.
The point is, it is possible to harden the OS (and by extension the network) against invasion, both by hardware and software means.
Life's a bitch but somebody's gotta do it.
And right now, there's a group of rednecks in Alabama with a dozen bearcat scanners trying to intercept wireless communications. They think the Miller Lite they're drinking is going to help them.
Brad Johnson
Advisory Editor
Brad Johnson
thanks to all involved
Bain
Sanity is a majority vote.
Since this is similar to a denial-of-service attack (continually requesting a service), the battery drain technique should work ok. Since you can keep the device broadcasting on a faster than normal basis, the battery will be drained faster.
However, most of these devices are rated on just this sort of continual broadcast. Take a look at the specs for recent cell phones. They list total broadcast time, as well as standby time. Bluetooth specs also detail power drain on a broadcast/standby basis.
End result? Manufacturers will get wise to these attacks, and figure out a way to ignore malicious devices. I seem to remember them talking about this, but I don't remember any documents regarding this.
However, this is just one of the issues being addressed in the Bluetooth (pico area nets) and 3GPP (next generation mobile phones) groups. The really big problem is how do you keep others from listening in on your conversation. In both groups, part of the answer is frequency hopping, plus a small amount of encryption (allowed by the Feds). Authentication is already in place to disallow most spoofing. It is always possible to spoof, just depends on how hard you have to work at it.
----------------------------- Work Sucks - Let's Go Flying!
-----------
"You can't shake the Devil's hand and say you're only kidding."
This was a very interesting article to read, the more exposure and testing and thought that is put into the nature of wireless networks the sooner we can get support in the mainstream. What i would have liked to have seen mentioned though is the relevance of proximity(and or distance), and also the idea of device detectors, ie if there is only meant to be a certain amount of devices in an area then another device can be a sentinel to determine if there is an imposter in the area.
/. keep more wireless stuff coming please.
And
I had often wondered about security issues with wireless devices. On one such instance a fight between my autoresponder and another left my blackberry dead in no time flat. I also wondered what kind of security wireless could provide considering todays and yesterdays "snooping" technology such as "TEMPEST". Kinda broadens the scope of the rumored ECHELON. Boy has the NSA got a lot to snoop now.
SL33ZE, MCSD
em: joedipshit@hotmail.com
SL33ZE - Artificial Intelligence is No Match For Natural Stupidity -
Work in quantum computing and quantum cryptography has shown that every cryptographic standard today can be broken in a no time at all, so how would wireless networks be able to take advantage of this? Since quantum computing only works because of entanglement, can wireless communications use this technology to provide any true security? Scientific study has shown that entangled particles can stay as such when separated by distances up to 10 kilometers, which is certainly far enough if your device is computing with another in your home or perhaps a receiver box connected to the internet at the end of your block. Anybody care to comment?
Once IPv6 goes into widespread production (we're now on IPv4, but it seems like everyone is skipping IPv5 - any info on that?), this problem will be licked because IPSEC will be integrated right into the IP stack. That means that any TCP/IP communications between IPv6 devices can and should be encrypted using IPSEC.
Neat, huh?
--
The real Paul Vallee is slashdot userid 2192, and, what do you mean it's not cool to point out your low userid?
I think the core assumption here is that we can trust some kernel code in the "peanut" device. I suspect that will prove to be a fairly difficult trust to establish.
The concept of resurected Ducklings however might have broader implications. Indeed, it might serve to solve some of the problems with trusted kernel code.
Suppose that we create "sickly ducklings" - processes that will die if interfered with. One way to look at hacking is that hacking is an attempt to obtain unexpected responses from a program based on unexpected inputs, and to take advantage of those responses. A fragile duckling, confronted with unexpected input would die - or perhaps enter a more sickly state.
[Reference to the "DOOM kill process article" elsewhere on slashdot is intentional.]
If the kernel code is fragile, then any attempt to interact with it by unauthorized entities will kill it. The program can then reinitialize itself, with a new identity. Any subsequent reference to this duckling by an authorized user will reveal the tamper.
Obviously the code must be small, and must interact in (formally) defined ways - much like a security kernel.
Combine this with Kerberos style tickets, or better yet Yaksha, and I think this might form the basis of software tamperproof.
[Yes, a well prepared adversary can kill a lot of ducklings to discover an "addicitve duckling medicine" that will enable him/her to cure the duckling, and manipulate the cured duckling. But I suspect the ease of discovering that medicine is related to key/secret size.
-----------
"You can't shake the Devil's hand and say you're only kidding."
There are two additional thoughts I would like to share. First - alot of this should be considered today. Examples include wake-on-LAN and power-management systems as well as laptops. For the first, assume a company has several hundred workstations that use wake-on-lan technology or other power management (maybe wake on modem activity?). Alot of power is consumed while those devices are "awake", so it would seem logical to put them to sleep when not in use (to save money on power). Somebody could simply walk up to a station and start sending out rogue "Wake p!" packets across the network, wasting large amounts of electricity and costing the company hundreds of dollars each day. This is, of course, theoretical.. but it underscores what these guys are talking about - conventional security wisdom isn't applicable in all situations.
I like the message. It's a wake up (pardon the pun) call for security analysts - consider your requirements! Locking everything down military-style does little good if an attacker can just start turning devices off at will by draining away all their power!
--
The trick is to use software paging. If you can spare enough memory to hold paging software and a software register, and your bus can transmit that data to a card, there is NOTHING to stop you having an unlimited amount of memory in your computer.
An 8088, expanded this way, could easily handle over one million pages, each 1 megabyte in size, totalling 1 terabyte of RAM.
An 8088 could program the 20-bit address bus, giving it a total of 1 megabyte of addressable RAM. However, the addressable space, internal to the processor, was the full 32-bits. If you had a TSR, which read this value and programmed a card with it, you could bypass the limitations of the rather idiotic address bus design.
CPU "Protected Mode"? Same rules apply. Write something in software to produce a similar effect. Yes, you add a layer, but it's not going to slow you -that- much, as it doesn't have to -do- much.
I agree that modern =LINUX= software utilises the processor a lot more than 1%. At least, when I use it, it does! I'm often getting between 98%-102%, as shown by 'top'. On the other hand, I do a lot of processor-intensive stuff. Wordprocessing leaves the machine unbelievably idle, and even regular stuff that floods the cache can end up injecting 4-5 wait-states for every machine-level instruction executed.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)