Category Archives: Security

Alexander Leidinger » FreeBSD 2013-03-16 18:53:06

After hours (spread over weeks) I come to the conclusion that there is a lot of potential to improve the documentation of card readers (but I doubt the card reader vendors will do it) and of the pcsc documentation. It is not easy to arrive at a point where you understand everything. The compatibility list does not help much, as the card readers are partly past their end of life and the models which replace them are not listed. Respectively the one I bought does not support all the features I need. I even ported the driver to FreeBSD (not committed, I wanted to test everything first) and a lot of stuff works, but one critical part is that I can not store a certificate on the crypto card as the card reader or the driver  does not support extended APDUs (needed to transfer more than 255 bytes to the card reader).

Well, the status so far:

  • I have a HOWTO what to install to use crypto cards in FreeBSD
  • I have a HOWOT what to install / configure in Windows
  • I have a HOWTO regarding creating keys on a openpgp v2 card and how to use this key with ssh on FreeBSD (or any other unix-like OS which can run pcsc)
  • I have a card reader which does not support extended APDUs
  • I want to make sure what I write in the HOWTOs is also suitable for the use with Windows / PuTTY
  • it seems Windows needs a certificate and not only a key when using the Windows CAPI (using the vendor supplied card reader driver) in PuTTY-CSC (works at work with a USB token)
  • the pcsc pkcs11 Windows DLL is not suitable yet for use on Windows 8 64bit
  • I contacted the card reader vendor if the card reader or the driver is the problem regarding the extended APDUs
  • I found problems in gpg4win / pcsc on Windows 8
  • I have send some money to the developers of gpg4win to support their work (if you use gnupg on Windows, try to send a few units of money to them, the work stagnated as they need to spend their time for paid work)

So either I need a new card reader, or have to wait for an update of the linux driver of the vendor… which probably means it may be a lot faster to buy a new card reader. When looking for one with at least a PIN pad, I either do not find anything which is listed as supported by pcsc on the vendor pages (it is incredible how hard it is to navigate the websites of some companies… a lot of buzzwords but no way to get to the real products), or they only list updated models where I do not know if they will work.

When I have something which works with FreeBSD and Windows, I will publish all the HOWTOs here at once.

Share

Alexander Leidinger » FreeBSD 2013-01-15 17:24:30

I wrote in a previous blog post that I want to switch to crypto cards for use with ssh and GnuPG. After some research I settled on the OpenPGP cryto cards. I ordered them from kernelconcepts. As soon as they arrive (and I have some free time), I will start to use them and write down how to work with them with FreeBSD.

Share

Alexander Leidinger » FreeBSD 2012-11-25 08:37:52

The recent security incident triggered a discussion how to secure ssh/gpg keys.

One way I want to focus on here (because it is the way I want to use at home), is to store the keys on a crypto card. I did some research for suitable crypto cards and found one which is called Feitian PKI Smartcard, and one which is called OpenPGP card. The OpenPGP card also exists in a USB version (basically a small version of the card is already integrated into a small USB card reader).

The Feitian card is reported to be able to handle RSA keys upto 2048 bits. They do not seem to handle DSA (or ECDSA) keys. The smartcard quick starter guide they have  (the Tuning smartcard file system part) tells how to change the parameters of the card to store upto 9 keys on it.

The spec of the OpenPGP card tells that it supports RSA keys upto 3072 bits, but there are reports that it is able to handle RSA keys upto 4096 bits (you need to have at least GPG 2.0.18 to handle that big keys on the crypto card). It looks to me like the card is not handle DSA (or ECDSA) cards. There are only slots for upto 3 keys on it.

If I go this way, I would also need a card reader. It seems a class 3 one (hardware PIN pad and display) would be the most “future-proof� way to go ahead. I found a Reiner SCT cyberJack secoder card reader, which is believed to be supported by OpenSC and seems to be a good balance between cost and features of the Reiner SCT card readers.

If anyone reading this can suggest a better crypto card (keys upto 4096 bits, more than 3 slots, and/or DSA/ECDSA  support), or a better card reader, or has any practical experience with any of those components on FreeBSD, please add a comment.

Share

Alexander Leidinger » FreeBSD 2012-11-25 07:27:45

I pull my hat to the people handling the recent security incident on the FreeBSD infrastructure.

Guys:

  • Thanks a lot for the countless hours you invested to find and close the initial attack vector.
  • Thanks a lot for the countless hours you invested to get the machines back to a well known state.
  • Thanks a lot for the countless hours you invested to verify the source repository.
  • Thanks a lot for the countless hours you invested to get back to a trusted package building environment.
  • Thanks a lot for the countless hours you invested to get the “remainingâ€? infrastructure (and everything else I forgot to mention) back into a good state.

Or in short: Thanks a lot for the countless hours you invested to get us from “we’re busted� to “we’re back�.

And last but not least, thanks for the decision to be better safe than sorry regarding our userbase (while it is the only way to handle something like this in a OSS project, I unfortunately think it has to be mentioned instead of taking it as an obvious decision).

Share

Thomas Abthorpe, portmgr-secretary@ » FreeBSD 2010-05-28 20:16:21

Five years ago when I started dabbling with gpg, I nominally knew what I was doing, and just faked my way through it all.  Now, I think I know what I am doing with gpg, it is time for an update.  I have set 0xD069F2A0 to expire early in June, and I will work through the logistics of revocation later.

In the meantime, my new id is 0xA473C990 with a fingerprint of D883 2D7C EB78 944A 69FC  36A6 D937 1097 A473 C990.  I will start using it immediately and will update references to it accordingly as I go.

Spawning Fetchmail with a Minimal Environment

I often ran fetchmail in the background, in “daemon mode”, to keep fetching my email from multiple accounts and piping it all through the Sendmail instance running as the local MTA of my laptop.

But I don’t always remember to run fetchmail before launching GNOME or before “polluting” my shell’s environment with dozens of environment variables that may be either useless or even mildly dangerous for a long running process like fetchmail.

So I started making a habit out of starting fetchmail under a relatively minimalistic env(1) invocation like this one:

% env -i LANG='C' LC_ALL='C' \
    HOME="${HOME}" TERM='dumb' \
    MAIL="${MAIL}" TMPDIR="${TMPDIR:-/tmp}" \
    PATH='/bin:/usr/bin:/usr/local/bin' fetchmail -a -K -d 101

The env -i start of this command clears all environment variables from the current shell, and then I copy only a small set of environment values from the current shell to the env-subprocess that fetchmail will run under.

Now I feel much safer about a fetchmail process running hours or even days in the background. Even if I restart my desktop session a few times, or I decide to experiment a bit with alternate environments, I know that fetchmail will be running with a working and very minimal set of environment options.


Posted in Computers, Email, Free software, FreeBSD, GNU/Linux, Linux, Open source, Security, Software Tagged: Computers, Email, Free software, FreeBSD, GNU/Linux, Linux, Open source, Security, Software