Author: Stefan

Fun-Day Friday – On Permaculture and observation

Without going into too many details, my email subscribers got a note about the importance of “knowing your baselines.”  Another way to say this is, “observe your system.”  One of the pinnacle lessons of Permaculture is to observe before you design.  When you are doing a design for someone else, this is more difficult to do, but you can eek out how much the client has observed, and use that as a guide, in most cases.

Observation lets you pick out what looks like minor details that might significantly impact the system design as a whole, especially if overlooked.  For example, a “wet weather stream” may not be obvious unless it is actually raining.  There are signs that indicate that a seasonal stream may be present, but unless you witness the event, you may overlook it.  When you go to design your system, if you accidentally place a structure or earthwork in a manner that disrupts the stream, it may be disastrous in a heavy rainstorm during the Spring flood events.

This weekend, I have the privilege of walking a property for a Permaculture consultation client.  I know there is at least one stream on the property, as well as an established pond.  It is supposed to rain.  I’m hoping it’ll rain near the end of the walk, and that I can observe for a while to see how the water flows.  Water movement is one of the most important things to design to control, and the end goal is (usually) to keep every drop of water on the property as long as possible without disrupting the downstream neighbors.

I’m excited to do a design again, and looking forward to getting back to spending some time just enjoying nature for a bit.

I’m still going to focus on the GnuPG problem, though.  My hope is that I have a working solution by Monday.  We shall see.

The Lab – Status and Happenings

I don’t really have a Gear Check post to share today, but I did want to give a status update on some of The Lab projects.

The new Hak5 Bash Bunny is on schedule on time to be delivered by end of day today (Wednesday.)  I already have some payload ideas I want to try, but I need to get it in hand and see how it handles flipping between attack modes before I get too attached to any one idea.  I’ll definitely post about it as a Gear Check next week.

The Beaglebone Black Wireless is still bricked at this point, but I should find time to unbrick it before the weekend gets here.  Once I do, I’ll update the OS, then I’ll try compiling GnuPG2 by hand.  We’ll try the Yubikey 4 from it again if that’s successful.  If it isn’t, I’ll plan to update on a different machine.

In the non-tech side of the shop, I’ve been engaged for a Permaculture design by a friend of a friend, and I’ve also been asked to hold a class / workshop on an introduction to Permaculture for a local Community Group for the Spring.  This might slow down some of The Lab technical work, but the primary focus will still be Unix Security.

Friday will probably be a Permaculture related post, simply because I’m working on the design stuff and it’s on my mind.

SSH Start to Finish Architecture – GnuPG keys generated on the Yubikey 4

To get GnuPG gpg-agent to work on the Yubikey 4, we need to put the keys on the device.  We can either generate them off of the device, and then copy them up, or we can generate them directly on the device.  We will do both versions of this before we are through, but today is “generate directly on the device.”

As I was getting set up to work on this again this weekend, I gave this a try on the new Beaglebone Black Wireless, on a whim.  The last time I had tried this on the BBBW, it didn’t go so well.  There were library issues that prevented GnuPG from accessing the card correctly, and the whole thing was an exercise in frustration.  Then I “did the dumb” and managed to brick the device while working on a project.  I already wrote up the procedure I used to unbrick it, which worked fine.  Apparently something in the unbrick firmware is different from what I had before, because when I tried this “on a whim” I had no issues.

Here are the steps I used, and I’ll link the articles I followed myself at the bottom.

In order to use the Yubikey with GnuPG, we first need to generate the keys on the device, (or import them.)  Unfortunately, when I was following this, the largest key I could actually generate for all three sections was 3072 bits, not 4096, even though GnuPG supports 4096, and the specs for the Yubikey 4 state it can handle 4096 bit keys.  Still, 3072 is larger than the 2048 limit imposed by the PIV SmartCard standard.  I believe this may be because the GnuPG that is being used might be GPG not GPG2.  I’ll research version more in a later update.

The top section of this article is what I followed for this.

Of course, when I was finished, I found that the Debian Jessie image didn’t include gpg-agent.  I had to configure the wireless with connmanctl, turn off “wifi tether” because it was on by default in the unbrick firmware, and was preventing wifi scan from working, and then do an apt-get update to make things happy so I could apt-get install gnupg-agent.

Then I ran into the issue of actually loading gpg-agent.  I got assertion errors when trying to load gpgkey2ssh.  I double checked the card, and it was missing the “Encrypt” key, but had the “Sign” and “Authenticate” keys listed.  I tried re-generating and got an assert error during the generation.  Things went downhill from there.

After reading several posts, including seemingly ignored bug reports, regarding these assertions, I am beyond frustrated with this side of the SmartCard options.  I will of course continue to attempt to make this work, but at this time the only recommendation I can make is to use the PIV SmartCard solution when possible.  It was beyond painless.

While every document I can find from Yubico says that this can “generate the keys on the device,” everything I am reading about actually getting the public key off of it for SSH use seems to want to “fetch” (which pulls from one of the public servers such as used for the Web Of Trust.)  This makes me think that there is some pre-setup that needs to happen with GnuPG, first, so I will work on that (I have the book) before I make another attempt at this.  Also, I can’t seem to ssh back into the BBBW since my last attempt.  It may be unrelated, but I think another unbrick event is due, which will give me a clean slate to work from, anyway.

I just wanted to share what has been done thus far, what speed bumps have been encountered, and what questions those have garnered.  I’ve been banging on this all weekend, so I’ll leave it until another week.

 

 

Fun-Day Friday – Lab projects summary

I thought I’d just give a brief list of what the priorities are for the Lab in the next week or two.

First and foremost is finishing up the write-up on using GnuPG gpg-agent for ssh from a Yubikey 4 token.  I’ve just about got the details finished up, so this should be ready by Monday.

A Hak5 Bash Bunny has been ordered, and should arrive by Wednesday.  I’ll probably cover a different piece of equipment that day, since it won’t quite be in hand, yet, but the following Wednesday will likely cover this new gadget.

Not tech related, but I have a Permaculture consultation I’ve been approached about.  I’ll be working on the initial few very rough designs for the property.

This weekend is the local HAM Fest.  Unfortunately, I won’t be able to attend this time.  I was going to be in the market for a new radio OR a new APRS TNC, but those will have to wait since we recently had a minor hit to our budget getting everyone over being sick.

We’ll probably do another Family Game Night this weekend, assuming time permits, and people are feeling up for it.

That’s about it.  Whatever you do, I hope it has an element of fun and an element of learning.  Those are what keep life interesting.

The Lab – Gear Check – Of Bunnies and Yubikeys

At some point today, Hak5 is rumored to be releasing their newest gizmo.  This device is the Bash Bunny, and that’s about all I know about it, but I’m eagerly anticipating discovering what I can about it.  It’s some kind of USB based attack device.  Some have speculated that it’s a USB Rubber Ducky on steroids, and others have speculated it might be similar to a Raspberry Pi Zero with case and special hardware.  We’ll just have to check throughout the day and hope it’s something in the Lab Budget range.

Monday, I posted the broad overview of how the GnuPG gpg-agent based ssh set up on the Yubikey should probably somewhat go.  Tuesday, I had the opportunity to look at the other piece that caught my eye.  The “PIV SmartCard” functionality mentioned means downloading and compiling a single tool from Yubico called the yubikey-piv-tool.

I was actually able to install a couple of prerequisite packages, compile the tool, and use it to configure the PIV SmartCard authentication slot today, and testing worked like a charm.  My only beef with this method is that the PIV standards don’t call for a key size greater than 2048 bits.  I prefer the 4096 bit rsa key for SSH, but 2048 is my bare minimum, and that’s available.

I literally followed this already written excellent guide, and it just worked.

Using ssh-keygen -fl on the public key pulled from that ${OPENSC_LIBS}/opensc-pkcs11.so path showed a 2048 bit rsa key without having to pass any extra flags to try to adjust bit size.

In case that guide changes, here are the steps:

Install OpenSC as a package if available.

Download and compile (./config && make && sudo make install) the yubikey-piv-tool from here.

yubico-piv-tool -s 9a -a generate -o public.pem
yubico-piv-tool -a verify-pin -a selfsign-certificate -s 9a -S "/CN=SSH key/" -i public.pem -o cert.pem
yubico-piv-tool -a import-certificate -s 9a -i cert.pem
export OPENSC_LIBS=/usr/lib/x86_64-linux-gnu/lib
ssh-keygen -D ${OPENSC_LIBS}/opensc-pkcs11.so -e

To use this, you need to call that ${OPENSC_LIBS}/opensc-pkcs11.so file as if it is your private key.  You can either use the -I flag for ssh, or use the -s flag for ssh-add to load this.  As long as the yubikey is plugged in when you try to load the key, it’ll work.

Please note that the default PIN is 123456.  They don’t tell you that in the guide, but that’s the default.  You probably want to change this PIN at some point, if you’re following along.

I’m still hashing out the OpenPGP SmartCard using GnuPG gpg-agent.  It is far more complicated.  I’m hoping it does allow for larger keys, though.  We’ll find out when we get it Lab approved.

SSH Start to Finish Architecture – very broad overview discussion of gpg-agent

Thank you to everyone who sent get well notes.  I appreciate it.  I’m doing slightly better.  Since I’m still not 100%, I haven’t gotten the deeper details of how the Yubikey 4 will work (as in, compiling software to use it, configuring it to be used, and then explaining the step by steps of using it.)

I have, however, learned enough to give a broad overview of the expected behavior, so we’ll start with that.

Earlier in this series, we talked about loading our private ssh key using ssh-add.  This required another service to also be running: ssh-agent.  The same is still true of ssh-add, but we need to use a different agent when dealing with using OpenPGP keys as an authentication mechanism.  For GnuPG, the tool is gpg-agent.

The general gist is that GnuPG needs to be configured to support SSH keys in its configuration file.  Once this is done, we can switch to using gpg-agent instead of ssh-agent.  This agent is capable of loading standard SSH private keys as normal, but it also allows for presenting an OpenPGP key as an authentication mechanism for SSH private key logins.

One thing we need to remember about OpenPGP is that it handles multiple keys that have multiple uses.  One use is “signing” which we might use for say… email.  One use is “encrypting” which we again might use for say… email.  When we load a key with gpg-agent, we want to make sure that the signing and encrypting capabilities of the key being presented are turned OFF.  Instead, we want only the “authentication” capability to be turned ON.  We are, after all, using this to authenticate to a server, not using it to encrypt or sign static files.

There are also two ways to handle the private key in general.  It can be generated “on the device” or loaded “to the device” after being created “off the device.”  The desired solution is to generate this “on the device” so that the private key never touches a hard drive where it can be retrieved via forensic tools.  This does, however, tie the key to that specific device, so if the physical key is lost, the keyring is lost, and the web of trust for that would be difficult to re-build.  Except we’re talking about using this device for nothing more than authentication.  We should not ever actually use the OpenPGP keys on this device for signing or encrypting emails.  It has no reason to be in the OpenPGP concept of web of trust.  It should ONLY be used for authenticating ssh connections.

The other argument is that you can generate a sub-key from your primary OpenPGP key that everyone knows you buy in the web of trust, and assign this sub-key authentication roles, then upload that to the Yubikey device.  If the device is lost, the subkey can be revoked, and a new key generated to go onto the new device that would surely be purchased to replace it.

My thoughts are… go with whatever you are more comfortable with.  I personally feel that it is better to generate the private key on the device and just don’t include it in the web of trust, since it’s sole purpose is authentication.  However, if you handle the key ring like a pro because you use OpenPGP for email correspondence on the regular, and you’re more comfortable using your single OpenPGP keyring for everything, by all means, go ahead and generate the sub-key and upload it to the device.  You’ve already got a feel for handling your keys in a sanitary environment, if you’ve been doing that a while, right?

While the OpenPGP keys for authentication was my primary reason for purchasing  and testing the Yubikey 4, there are other capabilities that may also tie in for a more robust secure login regime.

The server can be configured to take Yubikey One Time Pad (OTP) passwords, if there is a PAM module (or BSD Auth module) available for your OS.  Linux and I believe FreeBSD both have PAM modules.  OpenBSD has a BSD Auth function, but it’s local authentication, only.  This means it doesn’t report to a centralized server when the OTP is used, and therefore it doesn’t keep things synchronized across multiple environments.

The device also can be configured to send a static password much like a simple two line USB Rubber Ducky payload.  You can configure this to be a “password” or you can put a pass-phrase on it.  If you do this, Yubico recommends that you only store part of the password or passphrase on the device.  Type part of it manually, and then press the button for the correct duration to trigger the rest of the passphrase to be sent via the Yubikey.

There is also reference to a PIV SmartCard capability, which seems be an OpenSC implementation that potentially may also work for SSH authentication using PKCS11 instead of OpenPGP standards.  I will make an attempt to configure each of these and demonstrate both before this series is finished.  Of course, I retain the right to state I may be confused, and the PIV SmartCard and OpenPGP SmartCard functions may be the same thing on this device.  I’ll know for sure when I dig deeper and try both.

Fun-Day Friday – Still sick

So some of you already know that I got sick.  We checked my temps right after I finished up yesterday’s email content for the mail subscribers, and I was running 101.1F, apparently.

The best part about having a large family is the puppy pile of kids you get when you complain about feeling cold.

And I’m going to cut this post short, before I get completely incoherent with it, since I’m still running a low grade as I type, and I’m a touch light headed.  The emonlaid helps.

The Lab – Gear Check – Unbricking the Bricked BeagleBone Black Wireless

Unbricking the bricked BeagleBone Black Wireless was mostly painless.  I needed a power source.  I chose to use the USB/microUSB cable that came with it for communicating over the HOST USB port.  This is the port that lets you log in via 192.168.7.2 if you are using the stock debian install.

I also needed the USB TTL serial cable, so that I could watch the console for the boot/reboot process.  This wasn’t absolutely needed, but it was very useful.  I highly recommend that you use one if you need to do this procedure yourself.  I used “cu” to connect to the console like this:

cu -l ttyUSB0 -s 115200

The first step was to download the correct recovery image.  I navigated from beagleboard.org to find it based on the board I had on hand.  I started at the troubleshooting page and worked my way to the latest images link to grab the image I needed.

Once I downloaded the .img.xz file, I ran unxz to unpack it, then copied it to the microSD card via the SD card adapter:

unxz bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz
sudo dd if=./bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img of=/dev/mmcblk0

Once this was done, I put the microSD card into the BeagleBone Black Wireless, hooked up the TTL serial cable, connected to it with cu, and plugged in the other USB cable to power it on.  I had already booted the device while pressing the button that tells it to boot from microSD instead of eMMC, but if you are in this pickle and haven’t done that, make sure you do so now.

Over the console, I watched it boot until it gave a login prompt, and then I logged in as root (no password.)  Then I checked the flashing the eMMC page to get the instructions on what file to modify, and uncommented this line in the /boot/uEnv.txt file:

cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

A reboot from there, and the console took a while to flash the eMMC, but once it was done, everything was working again.  I’ll do another write up on getting OpenBSD to work on either the wireless or the RevC in a later post.

A case of the Mondays

Once again, the SSH stuff is delayed.  What I’ve figured out so far is this:

  1. The Yubikey 4 is too new for the default installed package of GnuPG and underlying libraries that talk to it as an OpenPGP card.
  2. I have tried the default installation on Debian 7, Debian 8, Linux Mint 17, and several others.  I need to compile stuff from source to try to make this work.
  3. I have limited time at the moment due to some major in-house projects (honey-do list) over the weekends, and so I will have to try to get the custom compile taken care of a little bit here and a little bit there.

On top of this, one of my bonus children has had issues with the SD card in her handheld game.  I tried to donate one of my microSD cards to replace it, but it wasn’t working.  I may need to get a friend that has done work on NES type games in the past to take a look at the card slot.

In the process of trying to get the donation card formatted, I think I bricked the new Beaglebone Black Wireless.  I need to go through the unbricking process this week.  Yay me.

I will try to document what happens, but in light of all of the frustrations from this weekend, I have to apologize for the lack of an actual technical post for today.  I will try to post short updates on Twitter throughout the week to keep people in the loop on progress, and hopefully I’ll have things ready to pick back up with the Yubikey SSH client keys discussion NEXT Monday.