Slashdot Mirror
Physical-layer Ethernet Encryption
Tekmage writes "Intel has just announced that they'll be shipping their ethernet encryption co-processor in their fourth quarter. Definitely a must (IMHO) for anyone considering wireless networking. "
← Back to Stories (view on slashdot.org)
great, don't forget that Intel's Nightshade mboard, with the integrated NIC that does Wake on LAN, can also be put to sleep with an IP packet. these will most likely suffer the same problem. now all of your trusted IPsec Intel NICs are asleep. where did your network logging and IDS's go? oh yeah... nowhere. :) have a nice day, folks.
jose nazario jose@biocserver.cwru.edu
The same reason that your driver's license number is also encoded on that little magnetic strip. The same reason that certain radiolocation tags *broadcast* their ID's. The same reason your cable TV box announces its ID number to your cable company.
Convenience in retrieval. Period.
There are dozens of perfectly valid reasons a CPU ID could and *is* being used that have absolutely nothing to do with invading your privacy or destroying your life.
Why do we have serial numbers in the first place? Vehicle Identification Numbers? Think about it from a Real World perspective and these things are hardly as evil as you seem to think they are.
Cryptology 101: you only need a cipher strong enough to last as long as you use it.
IIRC, IPsec negotiates a session key for each connection. It definitely uses a different session key for each remote host - that's a simple 'pigeon-hole' proof, and it's easier to use per-session keys than to try to force the same key on all connections to each remote host.
This means that your keys only have to be remain secret for the duration of your TCP/IP connections. After you've closed the connection, an attacker knowing your session key will not be able to impersonate you, and that's one of the primary concerns with network encryption. There is still the risk that someone could scan your datastream for sensitive information, but nothing prevents you from using additional levels of encyption for passwords, sensitive files, etc.
Even if you do slip up and copy an unencrypted sensitive file, IPsec algorithms are not lightweight. A couple spooks might be able to read your list of porn site passwords, but not the script kiddies (and not-so-kiddies) working for your competition and/or wife's divorce lawyer.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Several major universities are working on "Internet II". To techies this has been portrayed as a faster technology proving ground for the Internet, with limited access to the chosen developers at universities. However, I've heard it marketed as the future "secure commerce internet" by someone from a certain big blue American corporation. This person specifically claimed that host traffic would be verifiable, and thereby secure, and ISPs would be approved. Of couse big brother is going to have a backdoor, and your chip ID is going to uniquely identify you on the internet.
There is *some* reason for government to worry; If Internet technologies are going to be used for commerce of course people should worry that a cyber-terrorist could bring the banking system to its knees. But is that really what is happening? Transaction processing at that level has been taking place on private networks for years, and on that scale private networks are not nearly so cost prohibitive. In the decades long electronic banking era, have we had any national security level incidents? Not that I know of. So what if we now use TCP instead of SNA.
In my opinion, big brother is looking to gain more control of the every-day Internet -- it's a reflex action -- and big business is looking to create barriers to entry for the new economy -- another reflex action -- and they are willing to sacrifice a lot of economic growth in order to get it. Just an opinion.
No Encryption works forever, so what's the point for a encryption in the physical-layer?
The Open Source community (and the whole Internet, frankly), shouldn't put up with this kind of blantant "you only get this if you use all of our software and pay us extra money" kind of mentality.
Encryption is all about trusting nobody. Once you trust someone, you've lost your security. It's an easy matter (for someone who can write a device driver!) to make a module that will encrypt and decrypt packets as they go in and out of the ethernet interface. Why would you want to build something like this into hardware, particularly when the user requirements aren't known ahead of time?
Some users might just be surfing, and they might decide that 64 bit encryption is good enough for them. They never buy anything on the web, but they might want to safeguard passwords and e-mail addresses against spammers or whatever. On the other hand, the U.S. Army might have a need for 1024 bit encryption because they don't want to take the slightest chance that their battle management network will be compromised. Would any hardware level encryption meet the needs of these different users?
And then, what if there's a bug in the encryption. That bug might affect the actual security of the protocol making the device completely worthless. Or it might just affect what devices you could connect to, making the product useful in a very limited way. AHA! you say the solution is to make the hardware upgradable by burning a new program into a flash RAM. Well, why can't a virus do the same thing, except strip out all encryption totally?
Finally, any algorithm implemented in silicon is unlikely to be peer-reviewed. If I will have security, I want it to be built into a software package distributed under a licence which requires source code to be available. I want everyone to check the code out, find the bugs, try to crack it. Once it stands up to all that, I'll use it. I can't just trust Intel to do my homework for me.
If tits were wings it'd be flying around.
Not to split hairs, but the Intel description seems to indicate that the encryption is actually a chipset taking the IPSec encrypt/decrypt load off the OS and CPU, but that would be more network-layer stuff, not physical. Perhaps the title should be "Firmware-based encryption"?
Everyone will start to cheer when you put on your sailin' shoes.
I have to add my skepticism to this discussion as well. Despite the fact that most of the critical comments already posted have been moderated down, I think some good points have been raised.
While I think Intel is taking a step in the right direction by offloading the burden of network encryption onto hardware, the fact that the first rev only runs under Win2k and they're using export restricted crypto bothers me. I suppose this does have it's applications inside corporatations (otherwise they wouldn't have brought the product to market). Obviously this product is not targetted at the Open Source community.
The question on everyone's mind is, where's the Linux support. I don't know, but all I can say is that I hope it's coming. I would like to think that Intel's investment in RedHat was more than to just turn a profit and generate some good PR. Only time will tell on that one.
Here's my biggest concern: Did they kowtow to the FBI and install some key escrow into this product? Corporations might like that sort of thing anyway... keeps the feds happy and potentially off their back. However, if they did, then I don't think I'll ever be buying this little gadget. I'll just continue sacrificing a tiny bit of CPU performance to use the crypto I like.
You make several good points, I'm going to use one of them to deal with the other.
>This is particularly important when the users are neanderthals like corporate lawyers and merger & acquisition types who think PGP is one of those new US television ratings.
>Will the FBI/CIA/NSA have a back door into this? What if they do? As I have already stated, this product is clearly aimed at the corporate market (who may want some sort of key escrow anyway). If you're worried about it, software encrypt whatever you're going to send first.
You yourself have admitted that the target market for these devices isn't very techno savvy. Yet those people have a cery real need for privacy. Sometimes it is vital to have SECURE communications between people in the company. Imagine chipmaker XYZ decides that they're going to announce a 5% drop in prices tomorrow at noon. Company ZYX finds out and decides to steal their thunder. They announce a 10% reduction at 10am.
XYZ has two choices, take one in the eye and let ZYX make the best of the situation. Or two tighten up the belt and make price reduction of twice what they anticipated having to.
IMPORTANT shit is what gets encrypted. Nobody cares what the company cafeteria is serving for lunch today.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
If this is like most other IPsec accelerator chips I've seen, the chip just does the encryption and MAC, and doesn't make any suppositions about what the format of the packet is (which means that IPv6 support should be easy).
-lee
I was all set to blast this as a silly thing to implement, until I read that they're implementing IP security. If it were just link-layer encryption, it would be a waste of time.
Unfortunately, I don't see any mention of IP security in the chip for IP version 6 (and yes, IPsec is required in IPv6).
A number of people have commented that this is no better than using software based encryption and is possible worse because of the relatively short key length.
This really is not true. Every software based encryption technology of which I am aware still allows the hypothetical spies to see WHERE you go. Since, they can see where you go, they can theoretically narrow down the amount of traffic the want to try to crack.
It's like this: if you were using https, and they wanted to know what the content of your corporate intranet was, they wouldn't have to waste their time trying to crack all the times you pulled down pages from slashdot.
On the other hand, if the encryption is done at layer 2... They have to decrpyt every single packet you send looking for gold, including all those pesky netbios broadcasts. It would take subnstantially longer and they would not be able to ascertain any information from _who_ you were talking to.
Oh yeah -- this scenario really only applies if you're concerned about hacks into your local ethernet.
-- Slashdot sucks.
I wonder if you look at the silicon of that chip you see NSA Key written in the circuitry? :-)
This looks more like a request from Microsoft for security rather than a feature for Win2K OS.
Remember the news about Microsoft's wireless campus LAN? Programmers at MS will be broadcasting huge amounts of private information into the atmosphere, including Windows 2000 source code. What is stopping someone from opening up shop near by with a couple recievers? And Windows 2000 is slow enough as it is, without on the fly driver based encryption. Microsoft needs this card.
Personally I would prefer hardware acceleration rather than the card doing everything.
Ozwald
This could be good news, if Intel werent an US company. But since it is forbidden in the US to export strong cryptography, this system will either not be exported (which I cant believe) or it wont be really secure. I hope that the US government will someday realize that their strict crypto policy helps European and Asian companies to get advantages in the fast growing security market.
It all depends on how they are used.
But are they being misused? Call me uninformed, but I can't think of a single instance where a device's serial number or a car's VIN has been used in a privacy-compromising or otherwise "bad" way against its owner.
Also, what makes you think web sites *can*, much less will, collect this CPU ID for every visit you make? The only way this is possible is if the web site codes up an ActiveX or Java applet that you run with "full permissions". (A normal Java/ActiveX object would not work without making changes to the underlying engine.)
If someone writes such an applet, and you agree to start it with full permissions, then I suppose your CPU ID could be recovered that once. Similarly, you could easily download a program that could pull this CPU ID and start secretly tracking you based on this number. Let's face it, though, if I were going to write such a trojan, there are probably a few better ways I could think to get sensitive information from your PC and track you than a CPU serial number.
Additionally I suppose it's possible for all of the JVM vendors to add in "hooks" in their implementations to allow applets in the "sandbox" to recover something as sensitive as the CPU ID, but why in God's name would they choose to do that? There's a reason the Java/ActiveX sandbox exists. It wouldn't make any sense for those same people to start putting in all sorts of back doors.
Anyways, this whole CPU ID thing has been argued over and over already, and since you still seem to think they're inherently evil, I doubt that my comments here will make a dent, so you won't hear from me any more on this thread.
The flipant version of this question is "why should I trust Intell?" The real question is how do I verify that the chip only dose the algorithms it's supposed to and nothing else?
Is there a way to plot out the chip by inspecing the silicon? Is there room for the card to transmit information to be sniffed (like hiding things in bad packets)? Can we show that the algorithm which the chip implements dose not leave loose information floating arround (perhaps even in the initial choice of random numbers) which would allow additional information to be encoded ontop of a good packet? Who is going to audit the hardware? How scalable are the keysizes?
We probable can make good hardware encryption, but I would like to know that it is not an NSA trojan horse like clipper was.
Jeff
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Please return to your regularly scheduled rants about FBI/NSA/CIA conspiracies.
Performance offload support for IETF IPSec standard mandated cryptographic algorithms
Support for SHA1-HMAC, MD5-HMACs, DES, and 3DES
If it's used for IPSec, its output can be compared to that of another IPSec implementation. If it's at a lower level, there's nothing preventing someone from hooking up a packet analyzer to their LAN (which, if you're paranoid at this level, you should be doing anyway - do you trust your crypto supplier more than Intel?).
3DES is considered a safe conservative choice for strong encryption. IPSec is a reviewed protocol. MD5 and SHA-1 are also safe choices.
Why couldn't the same attacks could be launched against your existing system? It'd probably be easier to trojan your encryption system's libraries than get write-access to an EPROM's memory address. Besides, this is easily solved by using virus scanners, unusual operating systems (how many OpenBSD viruses are there?) and not running untrusted binaries.
Of course, it would have been better to put some public-key system on the chip and require updates to be signed with an Intel secret key. Still, if you're worried about attacks at that level you'd be insane to use regular hardware in any case.
Don't read too much into that sentence. It probably parses as
Losers running Windows 9x and NT4 are out of luck - this product will *not* run on these platforms unless marketing runs amok
instead of
We spit in the face of Linux users everywhere! Ha ha ha!
A second concern might be US export restrictions. Windows allows you to write drivers that verify they're running on a US distribution, but that's impossible with Linux.
(For security reasons, it's possible that someday each kernel will validate the modules it loads with cryptographic signatures, so Red Hat (to pick a name at random) could implement zoned distributions, but there's nothing to prevent Blue Jacket from rebuilding the same modules with its own keys. Encryption keys are private, source code is public.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken