My Link Graveyard

Sometimes I just need to “stash that link to read it later“.

It happens at work, at home while sitting at my desk , on my phone, while surfing on the tablet. The solutions to these kinds of problems? Well the CLOUD of course!

Ah, and I want an open-source solution I can self-host although I don’t want to do the work.

So thank you kind people of the world: http://www.inthepoche.com/

I stumbled upon this because the android app made it into F-Droid recently.

But asmw! you say. It’s PHP and PHP is vile and evil. Have you at least read all the source and made sure it’s safe?

Bah! I respond to this. It’s there when you need it and a link stash is not valuable enough [for asmw, at least] to worry too much. Just put it somewhere, where it [probably] can’t hurt anything else when things break.

Thus I installed it and added this to my ~/.pentadactylrc:

So I can :pc pages to my poche. I also installed the Android Poche app on my phone and tablet.

Problem solved (for now).

You want some entropy with that?

In the light of certain developments in the world and the temperatures in autumn getting colder again I have decided to put on a thicker tin-foil hat.

As can be read in the previous post, I’ve recently acquired two STM8S Discovery boards and abused one of them to play with gnuk, an open implementation of the OpenPGP card version 2.0 specification.

Today I put neug on the other one, a random number generator.

Building and installing is pretty similar to gnuk so I won’t talk about that.

I’ve played with the RNG test tools rngtest from rng-tools and dieharder a bit. There are scripts and results in the neug source tree if you want to follow along.

I cobbled together a udev rule to get a /dev/neug device and set the line discipline on the device.

I’ve not used any USB IDs here because they might vary (you have to set them with configure) , but I guess the product attribute is pretty unique.

Gnuk OpenPGP 2.0 Token (Update 1)

Update: If you don’t have the skill/time to do this or want to run Gnuk on open hardware see here: FST-01

After having gotten my OpenPGP smartcards to work I wondered if there are any open versions. After all they use a proprietary Operating System (BasicCard) and the software implementation isn’t open as well (AFAIK).

Enter Gnuk.

From the documentation:

Exactly what I was looking for. So here’s a quick HOWTO on getting your very own Gnuk up and running. (Maybe read it all first once and don’t just take it step-by-step)

What you need

  • One (or more) supported boards. Probably the cheapest version way to get one is cannibalizing a Stm8s-Discovery kit. I got two for less than 20 €. You’ll only need the programmer (ST-Link) part, not the actual microcontroller. Weird, eh?
  • A JTAG adapter. I got a Bus Blaster for 32 € which should cover you on future endeavors into the embedded world. It could be cheaper to get an actual ST-Link V2. Or, if you are more versed in the dark arts of DIY, build your own.
  • Some jumper wires
  • A soldering setup
  • A 2×8 pin header
  • Debian unstable for openocd 0.7 (and urjtag if you want to give your Bus Blaster a different persona)

What to do

Software

So here’s the easy part.

Download a suitable arm-none-eabi toolchain, I used this one: gcc-arm-embedded.
(On a 64-bit Debian you might have to enable i386 multiarch support and install libc6:i386)

I put all the stuff under ~/gnuk, so for easy copy-and-pasting do the same, otherwise adapt accordingly. Also check the linked pages for updated versions/if the direct links break.

You should now have a gnuk.elf binary to flash.

Hardware

  • Solder (or make someone solder)  the pin header onto the CN5 holes.
    stm8s_cn5_pinheader
  • Connect your Bus Blaster to it. Pinouts here. Just match the characters on the Blaster and the pinout :)
    connection
  • Connect the Bus Blaster to your PC and the Discovery board to power (any USB plug should do). I’m not sure if you could just connect the Discovery to your PC too, but it reduces error sources not to.
  • Install the binary (original docs). I’m assuming you’re in ~/gnuk/gnuk-1.0.4/.
    • Check flash ROM state:
    • See how it says Readout Protection On
    • Unlock the flash ROM
    • Check for: stm32x unlocked.
    • Power cycle the Discovery board two times to allow for erase/initialize cycles (see also: original docs)
    • If you like you can check again with the options_read script. Should now say: Readout Protection Off
    • Flash our binary

Update: don’t forget to re-lock your flash.

And that’s it. Connect the token to your PC and check what it does:

An empty OpenPGP card. Congrats.

Read on here: Personalization

Using the OpenPGP 2.0 smart-card with a Reiner SCT cyberJack RFID standard

… wow, that’s a long title.

Anyhow. After the last post I decided to see if there had been any developments w.r.t. the issues I had with the cyberJack reader.

Turns out it is fairly simple now. This was tested on Debian sid.

  • Install libifd-cyberjack6
  • Make sure you have enable-pinpad-varlen in your ~/.gnupg/scdaemon.conf
  • Restart your pcscd
  • Restart your gpg-agent daemon

Done.

There’s still an issue with pcscd crashing when I unplug the reader, but it works. Pinpad and all.

Using your OpenPGP card with Debian (Update 1)

Introduction

For some time now I’ve had an OpenPGP (version 2) smart-card laying in my drawer, waiting to be used.

When I bought it a couple of months ago I wanted to use the card together with a card-reader featuring a pin-pad. What I had at hand at that time was a Reiner SCT cyberJack standard combined RFID and smart-card reader with alleged Linux support. I never got that one to work properly. (Looking at some mailing list posts the situation could be better now, I might give the reader a second chance one day)

So I went ahead and bought an SCM ChipDrive pinpad pro (SPR 532), as those are supposed to work according to the docs.

My current reader:
spr532

 

Anyhow, I couldn’t get the setup working the way I wanted. The reader worked, and I could use the card by entering the PIN on the computer, but I could not get gpg to use the pin-pad on the card-reader. I tried different versions of gpg (1.4, 2.0, packages, self-built …) to no avail.

Frustrated I banished the card to my drawer.

Lately I’ve been working on a project at work which involves a cryptographic smart-card and decided to give it another shot.

So here’s a HOWTO getting your OpnPGP 2.0 smart-card working on Debian stable (7.1) using a SCM Chipdrive pinpad pro. The results are probably transferable to other distributions.

If you have any ides for improvements, please let me know.

HOWTO

  • I assume you have already set it up. If not follow the docs
  • Install Debian stable (I chose all defaults for a desktop install)
  • Attach the reader
  • Install additional packages: gnupg2 gpgsm
  • Launch a terminal
  • Import your cards public key: gpg2 –import yourpubkey.gpg
  • If your are not using a fresh install and have the pcscd package installed and the pcscd daemon running. Stop it for now (service pcscd stop). This has to be done before launching the agent. (Update: doesn’t seem to be required)
  • Add the following line to your ~/.gnupg/scdaemon.conf: enable-pinpad-varlen
  • Start a gpg-agent: eval $(gpg-agent –daemon)
  • Run gpg2 –card-status to make the card known.
    • If it isn’t check your setup, this should work out of the box
    • There might be issues with using the key on the card if you already have a secring (~/.gnupg/secring.gpg). If you have troubles, try moving it out of the way.
  • Create a test file: echo “I’m a test file.” > test.txt
  • Test the card: gpg2 –detach-sign –output test.sig test.txt

You should then hear a beep from the reader and get a pin entry pop-up with a signature count:

Screenshot from 2013-09-08 16:45:28

Enter your pin on the reader and admire your new signature.

As a side note: Realize that you are putting your keys on a proprietary piece of hardware with a proprietary operating system. If you are bothered by that read on here: http://www.fsij.org/gnuk/

Note to self: remote kernel updates

Whenever you feel the urge to remotely switch the kernel of a system you have no physical access to for another week because you ‘really need feature XYZ now‘: don’t.

*Sigh* I really wanted that iptables module. See what it got me.

Update:
Turns out everything went ok with the machine itself, but the static DHCP entry didn’t do its job.
Meh

Note to self: debian packages

On a clean debian system I need to install these:
apt-get install tmux vim openvpn openssh-server iotop htop bash-completion avahi-daemon aptitude fail2ban elinks gnomint

…and purge nano…
aptitude purge nano