Uwe Hermann | A slightly paranoid Debian developer

How nice. The FCC wants "a "back door" be built into all Internet-communications hardware and software to provide access for law enforcement agencies".

This and similar horror scenarios for the freedom and privacy of the people are nothing unusual these days.

A more general (and more paranoid) question:

How do we know whether our software or hardware is backdoored/wiretapped? We all know that using a certain OS from Redmond opens a lot of security holes in itself. Add to that all the now-public attempts of agencies and companies ranging from the FBI, NSA, Sony to antivirus-software vendors who install backdoors on your PC, and you've got some very good reasons to never trust any closed-source software again.

This is not a problem for most of us using Free Software and free operating systems (Linux, *BSD, etc.). Theoretically, we can read the source code of almost every single instruction being executed on our hardware, and verify that the software doesn't do any funny things like phoning home, logging keystrokes, opening backdoors and so on.

However, how can we know whether or not our hardware has been backdoored/wiretapped/trojaned (or whatever you want to call it)? Given that almost all devices we own nowadays (PDA, iPod, cell phone, hardware VOIP phone, and all the other gadgets) as well as most parts of our PCs and laptops have some sort of microcontrollers on them, how can we be sure that there is no secret code hidden in there which spies on us or provides hidden backdoors to them (whoever that may be)?

With some devices you can dump the firmware and analyze that, but most parts are probably not easily analyzable by mere mortals. Think network cards, builtin wireless cards, sound cards, bluetooth chips and so on. IMHO, a good first step in the right direction are things like OpenBIOS (Free Software firmware/BIOS) and OpenEZX (Free Software GSM phones). Alas, I think DRM will pose a major threat here in future, as we probably cannot easily replace custom firmware/software anymore if DRM in the worst form becomes reality.

So, how would you go about to ensure that your hardware has not been backdoored? How can we detect such things? How can we defend against such things? How can we remove backdoors if we find any? Do you know of any relevant research, papers, documents, HOWTOs? Any cases you know of where such things happened? Any practical tips or advice?

Yet another thing that has been on my TODO list for quite a while: encrypted USB thumb drives and/or encrypted external USB hard drives.

I have finally tried this over the weekend using loop-AES. This is very useful for securing your USB thumb drive contents in case you lose it or it gets stolen. Also, I use an external USB hard drive for backups (previously unencrypted). This is encryped now, too.

Here's a quick HOWTO:

1. Get the loop-AES kernel patches, apply them, enable "AES encrypted loop device support" in "Device Drivers -> Block Devices -> Loopback device support", and recompile the kernel.
   I also enabled "loop encryption key scrubbing support" as it seems to promise higher security (can anybody confirm that?).
   If you're using the Debian kernel packages, apt-get install loop-aes-2.6-686 (or a similar package) should suffice.
2. Get a loop-aes enabled losetup, mount etc.:
   apt-get install loop-aes-utils
3. Securely delete the target partition: shred -n 1 -v /dev/sda3.
   Use -n 25 or higher if you want more security and have a few days time to wait for the thing to finish...
4. Setup the loopback device: losetup -e aes256 -C 3 -S 'seed' /dev/loop0 /dev/sda3.
   Notes:
   • I used AES-256 as cipher, but others are possible.
   • The -C 3 means "run hashed password through 3000 iterations of AES-256 before using it for loop encryption. This consumes lots of CPU cycles at loop setup/mount time but not thereafter." (see losetup(8)). This is supposed to be more secure.
   • Using -S 'seed' (replace "seed" with a secret string like "g7sN4" or something) should make brute force attacks a bit harder. Don't forget the seed!
   • You'll be asked for a passphrase > 20 characters. Choose a good one. Don't forget it!
5. Create the filesystem (I used ext3): mke2fs -j /dev/loop0
6. Detach the loopback device: losetup -d /dev/loop0
7. Add this to /etc/fstab:
   /dev/sda3 /mnt/crypted_sda3 ext3 noauto,loop=/dev/loop0,encryption=AES256,itercountk=3 0 0
8. Mount the (now encrypted) partition by supplying the seed and entering the chosen password: mount -o pseed=seed /mnt/crypted_sda3
9. Done. You can now copy stuff to /mnt/crypted_sda3 which will be encrypted automatically.

For a more detailed guide read the Encrypted-Root-Filesystem-HOWTO. A performance comparison of different ciphers is available, but in general I didn't notice too much of a slow-down because of the encryption...

Al Gore, former vice president of the US, has given a very, very interesting and impressing speech on Martin Luther King Day a few days ago.

He states very clearly a huge number of (unlawful, illegal, or immoral) things the current US president Bush and/or his administration have done. For example:

• illegal wiretapping of American citizens
• illegal imprisonment of American (and other) citizens
• illegal torture by the CIA
• illegal kidnapping of people
• suppression of free speech by threatening NASA scientists
• and lots more

A quote of Al Gore, from a small Reuters summary of the speech:

We still have much to learn about the NSA's domestic surveillance. What we do know about this pervasive wiretapping virtually compels the conclusion that the president of the United States has been breaking the law repeatedly and insistently.

Transscripts are available from The Raw Story and the Washington Post, and there's also a full audio recording of the speech (MP3, 48 MB).

Although I'm not very political usually (or at least I don't write too much about it), this is really something I highly recommend listening to. I cannot imagine why a president of a democratic country can still be in charge, after all these things have become publically known...

(via Tim Pritlove)

Daniel H. Wilson, Ph.D. from the Robotics Institute of Carnegie Mellon University, has written a book about HOW TO SURVIVE A ROBOT UPRISING.

Bruce Schneier asked for more suggestions, and he received. Plenty.

(via Bruce Schneier)

This is old news by now, but still interesting IMHO. Jonathan Brossard has posted an article on BugTraq which gives a pretty good introduction to the inner workings of the BIOS (with lots of links to more detailed resources) as well as known vulnerabilities of the BIOS password mechanism.

The most interesting part is when he explains that the BIOS doesn't seem to erase its own keyboard buffer before it hands over control to the operating system. Also, current OSes (Linux, Windows, *BSD, etc.) don't seem to clear that buffer either.

This may not sound dangerous, but it actually allows anyone who can read the contents of your RAM, starting from address 0x041e, to view the keyboard buffer contents. And this buffer contains the BIOS password you type in when booting your machine (if you set/use a BIOS password, of course).

This one-liner (executed as root) should let you view your password as plain text:

dd if=/dev/mem bs=512 skip=2 count=1 | hexdump -C | head


(Only every second character belongs to the password, the rest are key scan codes, I think).

I also noticed that this same buffer also contains your LILO password, too! The same is probably true for passwords of other boot loaders such as GRUB, but I didn't test that.

Yes, reading this part of the RAM usually requires root privileges in Unix-like OSes, but as the security problem is OS-independant other OSes (e.g. DOS, or older Windows versions) might be directly affected.

But even on more secure OSes this plain-text storage of the BIOS/boot loader passwords might be a problem. Combine this with some Firewire insecurities and attackers with physical access to your machine (e.g. your unattended laptop, while you are on the toilet) might be able to read your BIOS/LILO passwords even though you locked your machine. I haven't yet tried this, but I'm pretty sure it's possible. Please post the results here if you try this.

(via Stefan 'Sec' Zehl)

Update 2006-01-09: It seems that when you use software suspend (swsuspend2) the RAM area can/will also contain your root password! Thanks nelson for reporting.