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)
First, I'd like to disagree that the key lengths are short. Triple-DES has a 168-bit key, which should be long enough.
Triple-DES was designed very carefully to avoid problems with multiple encryptions. Crypt-analysts found that encrypting something twice with DES and 2 different keys made it not significantly more difficult to decrypt than a single encryption (Schneier; Applied Cryptography; Section 15.1). Triple-DES does encrypt-decrypt-encrypt, defeating the meet-in-the-middle-attack.
But, if you use SSL with DES encryption (or even Triple-DES), over a physical layer that uses DES or Triple-DES, would this have an adverse affect? I'm asking, not telling, as I don't know. Does the meet-in-the-middle attack work when encrypting different data (it would seem not, but IANACryptanalyst)?
Any thought from someone who knows more than I?
-Dave
Citizens Against Plate Tectonics
And "peer" review is exactly what you'll probably get. If Intel has any hopes of selling some of these things to the US Dept. of Defense, certain other US gov't agencies, and some European gov't agencies, then they will submit it to a testing lab to get certified against the "Common Criteria" for information security. If you're not familiar with it, the "Common Criteria" (aka ISO IS 15408-1, -2, and -3) is the replacement for the old DoD "orange" book.
All Ethernet adapters have an ID.
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
This post is proof that 'the real world' is filled with idiots. Stay in school for as long as possible to avoid having to work with the brain-dead.
And who says they WON'T release any source for this adaptor in the near future? A lot of things that were "for use with Windows" have come up with Linux drivers. Why should this be different?
"Cryptology 101: you only need a cipher strong enough to last as long as you use it."
IMHO its so that a cipher can be considered "safe enough" as soon as other ways of obtaining the encrypted information (breaking into your house and taking your PC/forcing you to tell your passwords/you name it) become easier than breaking the encryption. Breaking the SSL key that you entrust your credit card info to is technically possible. But it still requires significantly more effort than just stealing your wallet or even writing down the numbers while you use your card in a shop, so thats safe as far as I am concerned.
Yes, you might have incredibly valuable information that you want absolutely no one to get... But if you pick an encryption strong enough that whoever wants that information is easier off doing something like getting you drugged and making you just tell your password than brute-forcing the encryption, thats about as much as you can do. (Except for completely hiding the existance of secret information; see steganography)
Okay, well how about this.
1. Take known word - let's use "abracadabra" for illustration - and send it through the card.
2. Observe encrypted results with network sniffer or similar device.
3. Take same known word and send it through software version of the algorithm you are testing (DES, 3DES, whatever).
4. Observe result of software encryption.
5. If result from step 2 = result from step 4 chip is doing what it claims.
Which brings up an interesting question. Since DES, 3DES, and the other encryption methods listed for this chip set are symetric encryption algorithms (i.e., both sender and receiver use the same key to encrypt and decrypt) how do you get the same key into the sending and receiving cards without sending the key in clear text?
I haven't read the IPSec standard yet, but the way this works for other hardware encryption systems I've worked with (like Automatic Teller Machines) is that someone has to initialize the encryption devices on both ends with a "key encryption key". This key is then used to send the first session key, and keys are randomly generated and exchanged on an ongoing basis using the previous key to encrypt the new one. (Of course one flaw that I often observe in this system is that the idiots running these networks choose 0123456789ABCDEF as the initial key, consistently).
yeah ... security through obscurity .... very effective security policy. I agree with you that it's not a panacea, but as far as security/ encryption is concerned, it is very near that. How does the adage go -- it's one thing if you can't break into my super-secret safe; it's another entirely if I can give the safe, 300 other examples of that model of safe, the specs to it, and millions of examples of what the key looks like, to you and 4,000 other friends and you STILL can't get in.
DES is about to be obsoleted and replaced by AES. Will this chip be able to
adopt new standards when they come out? It should be possible to build a
chip which is a general Feistal network engine which could run both DES and
newer algorithms such as twofish, which is an AES candidate. This chip does not
appear to have such flexibility.
Uhhh.. Why not just print the CPUID on the side of the chip if it's so equivialent to a serial number?
-josh
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.
The IP addresses need to be outside the encrypted payload for routing. This encryption won't be done at each gateway. So a snoop would know where your packets are going.
I think (but don't know since I am too lazy to read the IPSec spec) that the layer 4 (UDP / TCP) packets will be encoded so a snoop will not know if you are going to TCP port 80.
I thought his post was rather amusing --
and dead-on.
Could you be so kind as to inform those of us that don't know (like me) :)
This product is clearly designed for the corporate market, and it will likely get good play there. To answer some of the questions raised in this thread:
Why do hardware encryption? Because it's fast. Purpose designed hardware is almost always (okay, why hedge? make that always) faster than the same process in software. A hardware encryption chip will make the encryption process essentially invisible to the user. 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.
Will Intel build IDs into these things? Of course! It's called a MAC address.
Not sure why only Win2K support. Probably the IPSec calls in the IP stack.
Mark
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.
I agree with your post, except for your comments on virus prevention. Virus scanners are a fundamentally incomplete solution. Choice of an operating system does matter, but not for obscurity reasons. OpenBSD is secure because it has been designed (and verified) to be that way; it is not secure because it is "unusual". And if one has a secure platform, one should be able to run untrusted binaries (provided they are not run by a privileged user such as root).
"Whatever happened to fair use?"
-- Duff-Man
Although most companies didnt realize it, it may be a matter of survival for them to have a secure communication system without any backdoors. There are two reasons for that: Espionage: Companies might do active development, in which other companies might be interested. There are also cases reported when the NSA/CIA helped American companies to retrieve industrial secrets from foreign countries. CrackersIf there is a backdoor, and the NSA (or whoever else) can use it, a cracker might use it, too. This wouldnt be good at all for banks, credit card companies, eCommerce,... There is a real need for secure cryptography, but it must be open sourced and widely checked and accepted by leading cryptographers.
Your method is pretty good, except that there might be allowable variation in the output of an algorithm which would still allow the decryptor to work, but in practice if the chip says anything diffrent, then we have a flag to inspect it closer.. so your meathod still works. What I'm more concerned about is what if the whole card is designed to respond to or send special packets. How can we check against this possible backdoor?
Jeff
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
I can't trust *every* cracker out there who gets a copy of the source code, but I can trust *most* of them, including myself.
Let's say you've got one bad apple at RedHat who slips a trojan into an encryption driver. How long do you think it will be before it is discovered? Not long? You're right.
As soon as the code goes out the door people will start looking at it. I can do a diff against the same code acquired from different places. I can recompile the driver myself. I can inspect the code myself.
So you see, open source DOES solve these problems.
If tits were wings it'd be flying around.
Why physical layer security? This isn't physical layer security. The poster who though it was was wrong. If you want to adhere to strict OSI layer definitions -- well, you're out of touch with modern networking reality, but if you do -- then this is a Link Layer security.
Uhm, what is that comment about? If you go by the standards you're out of touch with modern networking?
How is the OSI model obsolete?
The main use for it I know of is licensing. You get a binary that asks for a code, give the company the cpu id, and they give you a code that only works for that machine & that binary. It's a technical backup for what is IMHO a pain-in-the-ass license. But it's not as evil as the company watching what your machine does.
By the way, this is very similar to how most *nix systems determine if the password you enter at login time is the same as the password in the passwd or "shadow" password file.
I would point out that the Intel CPU ID is also popular among corporate asset managers that are looking for a better system to electronically track machines.
The paranoia surrounding is issue is somewhat justified -- Intel did originally market the CPU ID as an 'Internet' feature.
Business. Numbers. Money. People. Computer World.
It would be bizarre if this were the case. I would think that any provider of networking equipment in their right mind would need to support lots of stuff (Solaris, NetWare, NT4, NT3, Linux, etc.)
But as other's said, there could be good technical and/or legal reasons for this.
Business. Numbers. Money. People. Computer World.
That doesn't mean that they won't release specs soon.
With all of the other goings-on involving encryption, do you think the Justice Department will like this? It sounds like a very good way to keep law enforcement types from looking at your transmissions.
Computers can only simulate determinism. ~Hermetic.
No Encryption works forever, so what's the point for a encryption in the physical-layer?
A year from now we'll probably see headlines about this and the included "backdoor" that allows the FBI, NSA, CIA, postman, etc. access to your encrypted data.
"Security features are for use in PC applications running the Microsoft Windows 2000 operating system only. "
Security features are for use in PC applications running the Microsoft Windows 2000 operating system only. Too bad it leaves Linux, *BSD, etc. out in the cold (assuming that we'd actually want to use it, but that's a different issue).
---
not plane, nor bird, nor even frog...
An encryption product from the company that brought us CPU ID numbers? No thank you.
Until I see that and decide for myself that is's secure... it ain't secure.
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.
Good. Now I hope it has an ID. No, that isn't flamebait. Asset management is an incredible pain in the ass with PCs and laptops and until the things get so cheap that we don't care if they are stolen, that would be the first step. Now (while I am on this tack), I want two stage bios setups so that I can roll back to the first one of an upgrade fizzles, I want 8MB of flash on the motherboard with a stripped BSD or Linux build with an ssh licence to allow me to configure the basics with the network before the OS starts, and I want ATX power supplies that don't use almost as much power off as on.
Yes, it has been inventory/budget month. Can you tell?
You mean Ft. Meade, MD.
-Doug
This looks like Intel is just catching up to Red Creek's VPN adapter.
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.
5 will get you 10 the chip design originated in... Hmmm...let me take a wild guess here...how about LANGLEY VA. Nah, they wouldn't do somthing like that, would they?
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.
Why encrypt for wireless? Just use spread spectrum equipment. Hell, direct sequence is hard enough to grab, let alone frequency hopping...
We're in agreement about operating system choice - I meant that OpenBSD is unusual because a great deal of time has been spent making it secure. The fact that OpenBSD doesn't have as many people attempting to build attacks is just a handy side benefit. I should have stated that better in my original post.
As far as untrusted binaries goes, I agree provided you have quotas setup properly, all interesting software is not user-modifiable (permissions & things like immutable) and that you minimize work done as root (which many people are lax about).
Another point about trusted code is that you want to get things like updates directly from the authors. Some people set up otherwise reasonable security & then install code off of the big archive sites without even testing a checksum. Ideally everything on your system would come with a digitally signed cryptographic hash for the archive.
"That's probably why Intel chose to implement standard, peer-reviewed algorithm:"
I have no quarrel with the algorithm they chose. It's the implementation that I don't trust. If I were to give you my very own implementation of RC4 that I wrote myself, would you use it? Why not? I might have screwed something up! Crypto algorithms are very tricky things to get right. Even if the algorithm is correct, there's all sorts of details involved with locking memory at the right times, erasing input buffers, avoiding buffer overruns, and key handling. The best way to try to crack something is to attack the implementation! It's very difficult for a single programmer or small group to get every last detail right, and if there's any gap at all you could lose all your security.
You don't believe me? How big a deal is a 1 byte buffer overrun? Who cares about that? 1 byte is sometimes is all that is necessary to crack a system wide open.
Peer review of the *implementation* is absolutely required. There's absolutely nothing at all wrong with the algorithms that Microsoft uses for security on their operating system. The problem is an implementation that is closed to peer review. Just like this device from Intel.
If tits were wings it'd be flying around.
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
True, Israel is (in theory) worse than good ole US of A wrt crypto policy. They regulate (in theory, again) even domestic usage. But they will make exception for Intel.
I didn't mean that that whole OSI model should be tossed, just that is shouldn't be applied strictly
Take IP and ATM: both "Layer 3." What does it mean if you have IP running over ATM or ATM over IP? Or NETBIOS over IP over ATM on top of Carrier Pigeons? It "Layer 2 Tunnelling Protocol" (L2TP) really Layer 2? Who cares!
The OSI model is a great starting place for modeling protocols, but the era where it can be taken as "dogma" are pretty much gone.
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.
It is neither physical layer nor link-layer encryption. It is IPSec, which means network layer. That is actually better, since IPSec is end-to-end. (Think about it: would you rather have encryption just on your LAN, or all the way across the 'Net?)
Also, 3Com came out with a similar card a few months back. I'm sure pretty much all the big NIC makers will have crypto coprocessors soon enough.
I wonder if you look at the silicon of that chip you see NSA Key written in the circuitry? :-)
You're correct about the strict OSI layer definition of physical layer.
I was thinking about it more in terms of being a dedicated chip-set (physical hardware) when I submitted the article.
--The more you know, the less you know.
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.
Ahem... what's this thingy for. Why is my modem light on when the line is didconnected?
Of course I'll be running one of these babies: f-cpu.tux.org
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.