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. "

Comments

Re:Is it useful in the long term?

[coyote-san]

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.

Clues for the Clueless

[the red pen]

1. Why should we believe this is secure? Where is the spec? Read the IPSec spec. It's wide open. RSA, DH, X.509, 3DES... this is not a "black box" system.
2. 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.
3. Why should we trust hardware? The NSA only trusts hardware. After you verify that it performs the correct operations, then you don't have to worry about someone hacking it -- even if they 0wnZ your box. Please don't waste your time with hair-splitting "what if" scenarios; we all know there's "always a way to circumvent security," but when it requires physical access to a box, it's much, much, harder.
4. Hasn't this been done? Yes. IPSec is a standard. Lots of people are doing it. There is IPSec technology being built into the Linux IP stack. That means you can VPN to your pals with a RedCreek VPN or a Network Alchemy gateway or one of these Intel network cards.

Please return to your regularly scheduled rants about FBI/NSA/CIA conspiracies.

Read the article, then comment.

[adamsc]

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?

Speed. IPSec can encrypt all traffic and, on a high speed link, the protocol overhead could easily be higher than a server's application overhead. Remember that Intel's gotten very interested in creating internet server farms, precisely the type of area where this is most useful.

Finally, any algorithm implemented in silicon is unlikely to be peer-reviewed.

That's probably why Intel chose to implement standard, peer-reviewed algorithm:

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.

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?

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.