| || || |
|encrypting ethernet bridge|
News: Thursday, May 9, 2002
I've updated the kernel patch. It is now diffed against 2.4.19-pre8, cleaned up quite a lot, and most importantly, adds some error checking which avoids kernel crashes. :-)
The error handling is not complete - in some situations, problems are handled by either dropping the packet or forwarding it unencrypted.
This is the home page of a modified version of the Linux Ethernet Bridge driver. It can encrypt or decrypt ethernet frames using the AES (Rijndael) algorithm, with unique keys for each destination address.
This code (and this page) was put together by Torrey Hoffman, the rest of my web site is up one level: www.arnor.net
If you don't know what the ethernet bridge driver does, you can read about it here.
This is not a general-purpose network encryption system. If you want that, check out the FreeSwan IPSec project.
Instead, this is a tool for software developers who are building custom encryption systems. The advantages of doing packet encryption and decryption in the kernel bridging code are higher speed, lower latency, and better consistency in inter-frame timings (as compared to an application which reads from the network, encrypts or decrypts, and then writes back to the network again.)
The AES encryption and decryption code included in this patch was written by,
and is Copyright (c) 2001, Dr Brian Gladman.
The rest of the code is based on the standard Linux ethernet bridge code, together with ideas and code lifted from the macprotofilter patch and the AES loopback driver patch. Thanks to all those developers who made it so easy for me to create this. The code is GPL'ed, aside from the part written by Dr. Gladman which is under a even more permissive license.
Why I wrote this
I put this together to encrypt multiple streams of MPEG video across a network. The video source is an specialized server which can simultaneously stream dozens of 4 Mbps streams out to multiple network clients. The goal is to prevent attackers from copying the video off the network using a packet sniffer. Putting this encrypting bridge between the server and the network makes it possible to encrypt all the streams, using a unique 128-bit AES key for every client. Since the encryption is done in the kernel, very little latency or packet timing variation is introduced to the stream. I decrypt the video stream in the client application.
This revision to the bridge code allows you to specify a 128-bit key, for any destination MAC address, which will be used to encrypt or decrypt packets as they flow through the bridge. It is easy to modify the code to adjust the details: what packets to encrypt, what to do with packets that are not encrypted, etc. It is also possible to specify the destination addresses by IP instead of MAC, this is a bit of a kluge but it works.
This code doesn't do any key management, that is left to a higher-level application. A modified version of the "brctl" command-line app allows you to specify (key,address) pairs for encryption or decryption, and to disable encryption or decryption to destination addresses.
Here is the kernel patch for the encrypting kernel driver. This patch is against 2.4.19-pre8, and is configured to encrypt based on destination IP rather than MAC.
Here is the source code for the modified brctl application, which adds the "encryptmac", "decryptmac", and "clearmac" commands. To compile this application, you will need to make /usr/include/linux a symlink to your patched kernel tree include/linux to pick up the #defines for the new IOCTLS. (yeah, I know, it should have a private header file... sorry.)
Some final cautions... decryption in the bridge has not been tested yet by me, (I do decryption in the client application), and also that the "showcryptmacs" command for brctl is not fully implemented. I hope to get around to both of those soon.
Email me! Bug reports, comments, questions, suggestions, and patches are welcome, but spam is not.
Updated May 9, 2002