Here is a schematic of the new prototype Wee-Gee boards. I just shipped these to China where they’ll make half a dozen boards for testing. The end product (without batteries) is about the size of a pack of cigarettes…
<
Finally; this is something I’ve been working on, on & off, for the past 18 months. It’s a small box that enables your voice (and data) to securely wriggle through complicated NATs in order to connect you & a friend. For this to work, you & the person you’re communicating with, attach this device (which is transparent to the rest of your network) to each of your home or office voice/data lines. See Figure 1.
If you are concerned about confidentiality on your phone conversations, or instant messaging, or any other type of IP data, this may be interesting to you. The Wee-Gee boxes, establish a highly secure communication channel between themselves. You don’t have to make any other changes to your network for this to work. Traffic destined for the remote Wee-Gee will automatically be encrypted & forwarded to it, while your other browsing and email traffic remains unaffected. All you have to do is connect the Wee-Gee into your network, give it the IP address of the remote Wee-Gee, & power it on. Figure 2 shows a working prototype.
The last picture in this set just shows a couple of the boards, boxed & unboxed. If you have any questions about these, please email me at: tporter@dtool.com
Ether is a company that lets experts get paid for talking about what they know. They protect the expert’s privacy as well.
I’ve been thinking & writing about the state of information security eight years from now, & I’ll be putting up some of the pieces here. First, what will the Network look like?
Many people believe that the 50,000 foot view of networked systems beyond this generation will be characterized by a variety of wireless access networks connected to an all IP-based optical core network (enabling global roaming using the radio technique best suited to support the requested service), and by endpoints that may consist of several different radios, which combine to form personal area networks (PANs). Internet access from the home will probably be a mixture of Broadband over Power Lines (BPL), Fiber to the Home (FTTH), 802.16 WIMAX, or ADSL2/ADSL2+.
The technology underpinning these systems is still mostly a subject of research, but certain key technological features are already emerging. There seems to be a common understanding that they will be characterized by the following features:
The main difference between contemporary mostly static networks and the network in 2015 is the logical location of intelligence within the network. Other significant differences will include: a lack of dependable power sources, questionable and varying bandwidth, on/off connectivity, no standard methods for determining membership, dynamic real-time configuration, difficult physical security implementation, and vastly increased points of network ingress/egress.
Lastly, in 2015, networks will depend to a much greater extent on wireless at the access layer. Wireless presents a new range of problems. Security in wireless networks differs markedly from security for their wireline counterparts due to the very nature of the physical medium. While communicating over a wireless medium, the transmitted and received signals travel over the air. Hence, any node that resides in the transmission range of the sender and knows the operating frequency and other physical layer attributes (modulation, coding, etc.) can potentially decode the signal without the sender or the intended receiver knowing about such an interception
Although the ColdFire architecture is closely related to the Motorola (now Freescale) m68K there are many simplifications to the RISC instruction set. The MCF5474 microprocessor is a member of the MCF547x pin compatible ColdFire family. It is based on the V4e ColdFire core and features multiple connectivity peripherals including two Ethernet, USB, PCI and other serial interfaces. I need the two ethernet interfaces in order to continue developing the encrypting bridge I’ve been working on for the past 9 months.
I tried doing this w/ a PIC architecture (see several items below), but that was way too slow. Several days ago, I finally got through a number of stupid problems, and got Linux running on the Coldfire. It’s running a 2.6.10 kernel with boa webserver, ftp, ssh, busybox, and other common services. The filesystem is NFS mounted so it’s pretty easy to make changes on the host and recompile & send to the chip.
Here’s a capture of the teminal screeen after the commands netstat -ln and set…
I’m currently programming a V4e Coldfire with a MCF5474 Fire Engine module that drives two fast ethernet controllers, serial, CAN, and and I2C bus. The base RTOS is a highly customized linux 2.6.15 kernel, and in order to build this kernel I have to, of course, build the M68K-specific compilation tools (binutils, gcc, etc), or a toolchain.
I installed Ubuntu Linux 6.0.6 on VMWare (Ubuntu is, IMHO, the easiest current Linux distro to install & upgrade without too much hassle. Now that Ubuntu is installed, the toolchain build has been huffing away for the past three hours. Hopefully, soon it’ll be done & I can get on w/ the task of building the kernel & getting it installed. More to come on this…
Some additional notes… The BCS toolchain finally built on Ubuntu after I made a few minor modifications including: Use bison, not bison++. There’s apparently some problem in the way bison++ parses some tcl packages. Have to add all of the rpm packages to Ubuntu since it uses apt for package management. There were a couple of other little gotchas but they don;t come to mind right now.
Anyway, now I’ve built the appropriate colilo bootloader, filesystem, and 2.6.10 kernel image. To load this on a ColdFire chip, I have to run the chip in debug mode, tftp over the bootloader, and then copy the bootloader code into flash. TFTP was no problem, but the flash write utility is supposed to first erase, then write to location 0xe0000000 and that appears to be an invalid memory location. After this step, I should be able to boot the colilo loader by executing “g 0xe0000400. That location, as far as I can tell has executable code, but I don’t know what that code is. So that’s where I’m stuck today…
This May has been odd, weatherwise, in Munich. It has rained almost every day, & the temperature has been anything but warm. It’s good weather for working inside at the ITCC (IT Command Center) at the Munich Messe. It’s even too cold & wet to bike to the English garden.
An American, Benjamin Thompson, aka Reichsgraf von Rumford (1753-1814) had the idea to build the “Englischer Garten". In its center is the Kleinhesseloher See - a large lake that hosts ducks and swans. The “Seehaus", a large beer garden, sits on one side of the lake. I took this picture of a swan there.
I’m in Munich for the next three months working as the director of network security on the FIFA World Cup 2006. For the past two years, I’ve been commuting to and from the US, Germany, and Switzerland every couple of weeks - all of this planning going into defending the world’s largest (when it’s completely built out) converged network.
Munich is a beautiful city of parks w/ the ambience of a large village. Unfortunately, it’s been raining for the last few days. However, today was just about perfect - 70 degrees & sunny - went & biked to the Englisher Gartens - The English Garden is the biggest city park in Europe - bigger than Central Park in NYC, plus it has a river flowing past its east edge.
My new book is out. If you click through the link, you can buy it at Amazon.
The Title of the book is, “Practical VoIP Security". It is designed for three related purposes - to educate data system administrators about the PSTN and how VoIP protocols work, and how these should be secured.
I learned alot while writing this book - key was that VoIP really is different than most other types of data traffic. Packetized voice is indistinguishable from any other packet data at layers 2 and 3, and thus is subject to the same networking and security risks that plague data-only networks. However, VoIP is a specific challenge because:
H.235 is expected to operate in conjunction with other H-series protocols that utilize H.245 as their control protocol and/or use the H.225.0 RAS and/or Call Signaling Protocol. H.235’s major premise is that the principal security threat to communications is assumed to be eavesdropping on the network, or some other method of diverting media streams.The security issues related to DoS attacks are not addressed.
This family of threats relies on the absence of cryptographic assurance of a request’s originator. Attacks in this category seek to compromise the message integrity of a conversation.This threat demonstrates the need for security services that enable entities to authenticate the originators of requests and to verify that the contents of the message and control streams have not been altered in transit. Authentication is, in general, based either on using a shared secret (you are authenticated properly if you know the secret) or on public key-based methods with certifications (you prove your identity by possessing the correct private key). The basis for authentication (trust) and privacy is defined by the endpoints of the communications channel. For a connection establishment channel, this may be between the caller (such as a gateway or IP telephone endpoint) and a hosting network component (a gateway or gatekeeper). For example, a elephone “trusts” that the gatekeeper will connect it with the telephone whose number has been dialed.The result of trusting an element is the confidence to reveal the privacy mechanism (algorithm and key) to that element. Given the aforementioned information, all participants in the communications path should authenticate any and all trusted elements.
Encryption methods are defined as DES, 3DES, and AES.TLS (Transport Layer Security) and IPSec (IP Security) are recommended to secure layer 4 and layer 3 protocol messages, respectively. IPsec and TLS provide solutions at different levels of the ISO model—IPSec in the Network Layer, and TLS in the Transport Layer. Both use the same type of negotiation to set up tunnels, but IPSec often encrypts crucial header information, and TLS encrypts only the application payload of packet, thus TLS encryption retains IP addressing.
I made a mistake on the previous board revs by misconnecting some address lines [SA:0-SA5] that both of the ethernet chips require in order to read from and write to their respective registers. This required some board redesign and some testing on a breadboard.
Here’s a closer look at this setup. This is more for software development then for board design - although one of the things I need to test is whether or not I need an octal latch on the muxed data lines. More to come later…
Here are some pictures of my latest project: an encrypting ethernet bridge. Figures 1 and 2 are of the prototype board fully stuffed. The last two pictures are of the PCB unstuffed (top/bottom). In Figures 1 and 2, the RJ-45 PHY’s are on the elevated mini-PCB’s. MAC is handled by the Realtek RTL8019As chip on each PHY.
The big microcontroller in the lower center of the picture (PIC18F452) controls packet logic and encryption. The small micro at top center is the RS232 MCU (It manages the voltage changes that this spec requires), and is used principally for programming debug stuff. The small MCU on the lower right is an EEPROM that holds 256K memory. The connector on the lower right is an ISCD programming header, and the stuff on the lower left is the power regulation module.
These are the first PCB’s I’ve designed - only one error on them so far, after burn-in, and it was easily fixed.
One of my current interests is low-level development of ethernet drivers and hardware for deep-packet inspection of TCP streams, and for attempting other weird things w/ L1-L2 ethernet. This picture shows the latest incarnation of the LAN whacker. The RS-232 circuitry is in the upper left corner next to a small EEPROM that is not (at the moment) hooked up. The PICF18452 is in the center top - it is the controller for all of this mess. The RTL ethernet MAC/PHY is on the right. The LCD at the bottom right is driven by the PIC, and is currently displaying the hex representation of each packet that this device receives.
Here’s a quick utility for generating WPA-PSK keys: WPA keys