IPv6 Stickers

Just a quick note to everyone interested in my IPv6 stickers. I uploaded the source files (see projects). Feel free to use, reprint or build upon!

ipv6 stickers

Boot time unlocking of encrypted disk via IPv6 SSH (Debian 8 Jessie)

Sometimes I have to deploy servers that require full disk encryption (FDE). Either for compliance reasons or just because I do not fully trust the data center they end up in.

Unlocking FDE means interfacing with the machine at boot time. This, however, has proofed to be quite a challenge. Especially remote management and KVM solutions like IPMI or IMM are sometimes buggy, usually hid away using VPN and I have my doubts about their understanding of strong cryptography ;)

Not wanting to go through all the hassle that is involved with unlocking FDE via remote management, I looked for better solutions. Luckily, boot-time unlocking of FDE via SSH over IPv6 in current Linux distributions has improved a lot lately. Read ahead to learn about my FDE setup on Debian 8 Jessi featuring dual-stack accessible SSH.

The bigger picture: We want to a server with freshly installed, and full disk encrypted, Debian 8 Jessie to boot an initial ramdisk that is capable of dual-stack networking (we still need IPv4 sometimes). A SSH server, we choose dropbear as it is small and fast, will wait for us to log in and unlock the encrypted disk. After unlocking the system continues to boot until it reaches its normal mode of operation.

Let’s assume we are logged in as super user on the corresponding machine. First step is to install the dropbear SSH server.

# apt-get install dropbear
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  dropbear
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
✂️
Preparing to unpack .../dropbear_2014.65-1_amd64.deb ...
Unpacking dropbear (2014.65-1) ...
✂️
Setting up dropbear (2014.65-1) ...
✂️
Wrote key to '/etc/initramfs-tools/root/.ssh/id_rsa'

Unfortunately, the package creates a SSH key on its own, which can be used to login via SSH. We will remove the auto-generated keys as it is not a good idea to store any private key at the unencrypted part of the system.

# rm /etc/initramfs-tools/root/.ssh/id_rsa
# rm /etc/initramfs-tools/root/.ssh/id_rsa.pub
# rm /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

For authentication against the pre-boot SSH we will have to place the public SSH keys of all users who should be able to unlock the drive in /etc/initramfs-tools/root/.ssh/authorized_keys. This file will automatically become part of the initial ramdisk later.

Now that we have taken care of security, let’s move on to preparing the initial ramdisk building configuration. We edit /etc/initramfs-tools/initramfs.conf to enable dropbear, configure networking and set legacy IP address (if required).

DROPBEAR=y
✂️
DEVICE=eth0
IP=100.64.1.2::100.64.1.1:255.255.255.0::eth0:off

For IPv6 configuration we need to add a script to the initial ramdisk that gets executed before the disk is being unlocked. We create /etc/initramfs-tools/scripts/local-top/ipv6 which contains the IPv6 configuration, among with important boilerplate which makes sure it does not get executed at build-time.

#!/bin/sh

PREREQ=""
prereqs()
{
  echo "$PREREQ"
}
case $1 in
  prereqs)
    prereqs
    exit 0
    ;;
esac

ip addr add 2001:db8::1337/64 dev eth0
ip route add default via 2001:db8::1

exit 0

We now have to make sure this script is executable, as it is required by update-initramfs which we will run eventually.

# chmod +x /etc/initramfs-tools/scripts/local-top/ipv6

There are different ways of unlocking the disk once we have logged in to the pre-boot SSH server. One that makes sure we can unlock via SSH but still allows unlocking directly by connecting a keyboard and a screen to the server is the passfifo method. A simple script that uses the method might look like this and should be placed in /etc/initramfs-tools/hooks/unlock:

#!/bin/sh

PREREQ=""
prereqs()
{
  echo "$PREREQ"
}
case $1 in
  prereqs)
    prereqs
    exit 0
    ;;
esac

. /usr/share/initramfs-tools/hook-functions

cat > "${DESTDIR}/root/unlock" << EOF
#!/bin/sh
/lib/cryptsetup/askpass 'passphrase: ' > /lib/cryptsetup/passfifo
EOF

chmod u+x "${DESTDIR}/root/unlock"

exit 0

Once again we will have to make sure the script is executable:

# chmod +x /etc/initramfs-tools/hooks/unlock

Small caveat ahead! The network interface configuration is more persistent than one might wish. We need to flush the address configuration of the interface after unlocking the disk. Otherwise it might interfere with boot-time network configuration. I therefore recommend creating another script named /etc/initramfs-tools/scripts/local-bottom/flush which flushes the interface’s configuration.

#!/bin/sh

PREREQ=""
prereqs()
{
  echo "$PREREQ"
}
case $1 in
  prereqs)
    prereqs
    exit 0
    ;;
esac

ip addr flush dev eth0
ip route flush dev eth0

exit 0

You know the drill, we have to make sure this script is executable again.

# chmod +x /etc/initramfs-tools/scripts/local-bottom/flush

And that finishes configuration! It is now time to build the initial ramdisk and reboot the system.

# update-initramfs -u
# reboot

Like to see a preview? Here is how it looks like:

$ ssh root@2001:db8::1337
BusyBox v1.22.1 (Debian 1:1.22.0-9+deb8u1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # ./unlock
passphrase: *********************************************

Enjoy and don’t hesitate to drop me a line if you like to comment on this post.

Michael Ossmann on HackRF One, rad1o and SDR

A couple of weeks ago, at DefCon 23 in Las Vegas, I missed the chance to talk to Michael Ossmann. Luckily, he decided to join us at the Chaos Communication Camp in Germany a week later.

Our official camp badge is a powerful Software-defined Radio (SDR) device based on the layout of Michael’s famous HackRF One. Thanks to sponsors and the amazing work of your fellow Munich CCC hackers, we were able to release 4500 rad1o SDR devices into the hands of hackers and interested parties.

I guess we will see a lot of broken protocols in the future. But who could tell better than a guy who teaches wireless security, invented an affordable SDR device and is the founder of Great Scott Gadgets. I had the chance to sit down with him for an interview after the rad1o badge talk.

ccc rad1o badge

soldering

Interview

Dan: Michael, you are the driving force behind the HackRF One. What was your motivation behind building it?

Michael: I wanted to make SDR more accessible to people. I teach a class on SDR and I tried to teach people in the security community how to use SDR. The HackRF One was built because it is incredibly powerful for wireless communication, security research and development.

Dan: What do you think about the rad1o badge, which is based on the HackRF?

Michael: I put all the work into making low cost SDR transceiver and I suggested just copying my design. The design is open-source on purpose. I found out about the rad1o badge about a month ago on twitter. My initial thought was: Wow, i have to go to the camp, I can’t miss this! Since then I have met the creators of the rad1o badge and it has been great. I am a big fan of what they are doing and they welcomed me into their talk tonight.

Dan: In your opinion, what is the state of wireless security?

Michael: A lot of people in the security community are familiar with wifi and the tools that you can use on wireless networks. These tools are very good, you can buy an of-the-shelf wifi adapter that is a good tool for wireless security work. However, for anything other than wifi the tools are few and far between. That is the thing that excited me the most about SDR. SDR is a universal radio. It allows me to explore protocols other than wifi and it allows me to create tools for protocols other than wifi. When you start exploring other protocols, especially low speed protocols, you often find that security is either poor or absent. It is like computer security of the eighties. the makers of the protocols don’t have a mature view of communication security.

Dan: Is there something that everyone, including non-technical users, should know about wireless?

Michael: I think the thing that everyone should now is, that you can experiment with it. You don’t have to go to school for years to experiment with wireless. All you need is a SDR device and you can explore the wireless spectrum. Homes are incredible full of wireless systems such as windows shields and heating now, especially compared with 20 years ago. You got a bunch of radios in your pocket. In the car, every wheel has a radio, and it is parked in a garage with a radio controlled door.

Dan: What industries do you think are the most endangered or disrupted with SDR devices like the HackRF becoming more affordable, better in quality and more widely spread?

Michael: We have already seen the incredible explosion of low-cost low-power wireless communication systems. The trend will continue. I think what HackRF enables, is not necessarily industry, but the community. It enables individual people to experiment with radio, instead of companies with research labs. I do see HackRF be used a lot by startups, low-budget startups that try to do a lot with a little bit of funding. They use HackRF instead of high-cost RF test equipment. They replace signal generators and spectrum analyzers, saving tens of thousands of dollars which lowers their development costs. I was thanked by people personally for saving them lots of money. It is also very good for education. Instead of one expensive piece of lab equipment, they can buy many HackRFs and get a device in each students hand. That is very rewarding to me personally, as education is one of the goals I had in mind when I was making hackRF.

Dan: One last question. Is there anything that you recommend for the average user to avoid getting owned? What are the top things to do, and what are the top things to avoid?

Michael: Unfortunately, the wireless communication protocols used by common household devices typically don’t have very good security features. If they run on wifi, they are usually better. For anything else, the best advice I can give you is, learn a bit SDR, explore the interfaces yourself and find out what is vulnerable and what is not. And do please share the knowledge!

The same debates and problems we had about computer security in the nineties are happening now for new type of devices that do not used to be a computer before. Your ceiling fan is now a computer with a wireless interface. It is made by a company that made fans in the past, not computers. The company has no experience in building computers. It has no experience in bug hunting and it does not even have a bug bounty program. It has a huge misconceptions about the security of their products. Things the computer industry had to learn long before is now a challenge for every industry that builds anything that is becoming a computer, basically everything. The compute industry understands that it is a hard problem, it requires iteration and input from users and researchers. Other industries have to learn that.

Dan: Thanks you very much for the interview and also for giving the community such a great tool and making it open-source.

Michael: You are welcome.