Sta­tus cryp­to cards HOWTO: prob­lems with the card read­er (sup­port could be better)

After hours (spread over weeks) I come to the con­clu­sion that there is a lot of poten­tial to improve the doc­u­men­ta­tion of card read­ers (but I doubt the card read­er ven­dors will do it) and of the pcsc doc­u­men­ta­tion. It is not easy to arrive at a point where you under­stand every­thing. The com­pat­i­bil­i­ty list does not help much, as the card read­ers are part­ly past their end of life and the mod­els which replace them are not list­ed. Respec­tive­ly the one I bought does not sup­port all the fea­tures I need. I even port­ed the dri­ver to FreeB­SD (not com­mit­ted, I want­ed to test every­thing first) and a lot of stuff works, but one crit­i­cal part is that I can not store a cer­tifi­cate on the cryp­to card as the card read­er or the dri­ver  does not sup­port extend­ed APDUs (need­ed to trans­fer more than 255 bytes to the card reader).

Well, the sta­tus so far:

  • I have a HOWTO what to install to use cryp­to cards in FreeBSD
  • I have a HOWOT what to install / con­fig­ure in Windows
  • I have a HOWTO regard­ing cre­at­ing keys on a openpgp v2 card and how to use this key with ssh on FreeB­SD (or any oth­er unix-like OS which can run pcsc)
  • I have a card read­er which does not sup­port extend­ed APDUs
  • I want to make sure what I write in the HOW­TOs is also suit­able for the use with Win­dows / PuTTY
  • it seems Win­dows needs a cer­tifi­cate and not only a key when using the Win­dows CAPI (using the ven­dor sup­plied card read­er dri­ver) in PuTTY-CSC (works at work with a USB token)
  • the pcsc pkcs11 Win­dows DLL is not suit­able yet for use on Win­dows 8 64bit
  • I con­tact­ed the card read­er ven­dor if the card read­er or the dri­ver is the prob­lem regard­ing the extend­ed APDUs
  • I found prob­lems in gpg4win / pcsc on Win­dows 8
  • I have send some mon­ey to the devel­op­ers of gpg4win to sup­port their work (if you use gnupg on Win­dows, try to send a few units of mon­ey to them, the work stag­nat­ed as they need to spend their time for paid work)

So either I need a new card read­er, or have to wait for an update of the lin­ux dri­ver of the ven­dor… which prob­a­bly means it may be a lot faster to buy a new card read­er. When look­ing for one with at least a PIN pad, I either do not find any­thing which is list­ed as sup­port­ed by pcsc on the ven­dor pages (it is incred­i­ble how hard it is to nav­i­gate the web­sites of some com­pa­nies… a lot of buzz­words but no way to get to the real prod­ucts), or they only list updat­ed mod­els where I do not know if they will work.

When I have some­thing which works with FreeB­SD and Win­dows, I will pub­lish all the HOW­TOs here at once.

More dri­vers avail­able in the FreeBSD-kernel doxy­gen docs

Yes­ter­day I com­mit­ted some more con­figs to gen­er­ate doxy­gen doc­u­men­ta­tion of FreeBSD-kernel dri­vers. I mechan­i­cal­ly gen­er­at­ed miss­ing con­figs for sub­di­rec­to­ries of src/sys/dev/. This means there is no depen­den­cy infor­ma­tion includ­ed in the con­figs, and as such you will not get links e.g. to the PCI doc­u­men­ta­tion, if a dri­ver calls func­tions in the PCI dri­ver (feel free to tell me about such dependencies).

If  you want to gen­er­ate the HTML or PDF ver­sion of some sub­sys­tem, just go to src/tools/kerneldoc/subsys/ an run “make” to get a list of tar­gets to build. As an exam­ple, “make dev_sound” will gen­er­ate the HTML ver­sion for the sound sys­tem, “make pdf-dev_sound” gen­er­ates the PDF ver­sion. The sound sys­tem is prob­a­bly the most “nice” exam­ple, as it includes a page with TODO items, and has even some real API docs instead of just the call-graphs and such auto­mat­i­cal­ly gen­er­at­ed information.

Some dri­vers already have (some) doxy­gen markup (I did just a quick grep for ‘/*[*!]’ to detect doxy­gen markup indi­ca­tors, no idea about the cov­er­age or qual­i­ty), namely:

There is more doc­u­men­ta­tion than only for those dri­vers, I just list­ed those as there are at least parts of doxy­gen doc­u­men­ta­tion inside.

VDR ports docs

After a quick dis­cus­sion with nox@ I made a copy&paste of his “VDR is com­mit­ted now”-mail into the FreeB­SD wiki. I also re-styled some small parts of it to fit bet­ter into the wiki. It is not per­fect, but already usable. Now inter­est­ed peo­ple can go and improve the docs there.

Thanks to Juer­gen for all his work in this area!

Doxy­gen stuff updat­ed in 9‑current

I com­mit­ted my patch for tools/kerneldoc/subsys. Except for not gen­er­at­ing the PDF part, this is now the same con­fig which I use to gen­er­ate the online ver­sion. While writ­ing the com­mit log I noticed that I did more changes than I thought…

So any­one who wants to gen­er­ate the Doxy­gen docs of some FreeB­SD ker­nel sub­sys­tems on his own, can do it now. Adding more sub­sys­tems is easy, just make a copy of one the the exist­ing Doxyfile-* files – keep the same nam­ing scheme – and change the con­tents. Every­thing else is han­dled automatically.

I also added a link to the FreeB­SD wiki. It is not at a promi­nent place (near the end of the main page), but at least some­one can find the link to the my FreeBSD-doxygen page there.

HOWTO: “Blind” remote install of FreeB­SD via tiny disk image

In this post I write how to install FreeB­SD on a remote lin­ux sys­tem by cre­at­ing a root image pre­pared for mir­ror­ing on a local sys­tem. There is no (free) access to the remote con­sole, only access via ssh.

In this post I write how to install FreeB­SD on a remote lin­ux sys­tem by cre­at­ing a root image pre­pared for mir­ror­ing on a local sys­tem. There is no (free) access to the remote con­sole, only access via ssh.

Back­ground story

While I was at the uni­ver­si­ty, I worked remote­ly for an ISP (admin­is­tra­tion of sev­er­al FreeB­SD sys­tems). Dur­ing this time I start­ed to use my own domain, and I was allowed to host it direct­ly at the ISP for free. I tried to not use too much space on the hard­disk (at the end about 400 MB) and to not pro­vide some­thing which attract­ed too much peo­ple to keep the band­with on a sane lev­el. After the uni­ver­si­ty I was still avail­able to answer ques­tions, and I was still allowed to host my web­site there for free. As the num­ber of ques­tions can be count­ed with IIRC one hand since then, I decid­ed at some point (recent­ly, to be exact – bet­ter late than nev­er) to move my web­site to a dif­fer­ent place (I am still avail­able if they have some ques­tions – for free – but I do not expect to get much ques­tions from them).

At the same time my broth­er decid­ed to move to a new serv­er hoster, as his old one decid­ed to increase the amount of mon­ey cus­tomers have to pay for the ser­vice. So we searched togeth­er a new ISP where he either could host his serv­er, or get a root­serv­er for a good price (the idea was to have my domain in a jail on a serv­er of the com­pa­ny of my broth­er, and we share the costs for it). We found Man­i­tu (the own­er has even a blog about his busi­ness), which is even not far away from my place.

Unfor­tu­nate­ly they do not pro­vide FreeB­SD pre­in­stalled on their root­servers, but they offer a remote res­cue sys­tem (read: boot­ing a lin­ux image… I assume via PXE or sim­i­lar) and we knew some­one who has some servers there, so I was able to get a rough idea what kind of hard­ware is used there (the hard facts like PCI IDs and such). The idea was to build a very small disk image, put it on the hard­disk over the net­work via the remote res­cue sys­tem, and then to con­fig­ure the remain­der of the harddisk(s) to use it. And here is how I did it (my broth­er thought “who is bet­ter suit­ed to install a FreeB­SD sys­tem remote­ly with­out access to the con­sole of the machine (the ISP offers to hook up a KVM switch, but only dur­ing busi­ness hours and you have to pay for it) than one of the devel­op­ers of FreeBSD…”).

HOWTO

In the title of this post I wrote “via a tiny disk image”. This is true for a suit­able def­i­n­i­tion of tiny.

What we have in the root­serv­er are two 160 GB hard­disks. They shall be used in a soft­ware mir­ror (via gmir­ror). The root-FS shall have about 5 GB. This is more than need­ed, but as this is only 3% of one hard­disk, I pre­fer to keep it a lit­tle bit big­ger than too small after an remote update or two. The machine has 2 GB of RAM. We do not expect much ker­nel pan­ics (= crash dumps) there, so we do not real­ly need >2 GB of swap (for­get the rule of hav­ing twice as much swap than RAM, with the cur­rent amount of RAM in a machine you are in “trou­ble” when you need even the same amount of swap than RAM). I decid­ed to go with 1 GB of swap (mir­rored too, to pre­vent a hard­disk fail­ure to take down the machine), this is more than enough. The rest of the hard­disk will be used for jails, the distfiles/packages for/of the ports, and as WRKDIRPREFIX when build­ing ports.

Now, pushing/pulling a 160 GB image over the net­work to install a sys­tem is not real­ly some­thing I want to do. I would pre­fer to trans­fer less than 500 MB (that is 0.3% of the entire disk) to get this job done, and this is fea­si­ble. Due to an error or two I had to trans­fer the image sev­er­al times until every­thing was work­ing, so it was more in the area of maybe 2 GB (~1% of the entire disk).

First let us define some vari­ables in the shell, this way you just need to change the val­ues in one place and the rest is copy&paste:

ROOTFS_SIZE=5G
ROOTFS_NAME=root0
FILENAME=rootfs

Then change your cur­rent direc­to­ry to a place where you have enough space for the image. There we will cre­ate a con­tain­er for the image, and make it ready for partitioning:

truncate -s ${ROOTFS_SIZE} ${FILENAME}
mdconfig -a -t vnode -f ${FILENAME}

Cre­ate the rootfs:

# create one active FreeBSD slice with $ROOTFS_SIZE GB
fdisk -e /dev/mdX
gmirror label ${ROOTFS_NAME} /dev/mdXsY
bsdlabel -w /dev/mirror/${ROOTFS_NAME}
# create an "a"-partition for everything
bsdlabel -e /dev/mirror/${ROOTFS_NAME}
newfs -U /dev/mirror/${ROOTFS_NAME}a

Mount the new rootfs to /mnt and install FreeBSD:

mount /dev/mirror/${ROOTFS_NAME}a /mnt
cd /usr/src
make buildworld >&! buildworld.log
make buildkernel >&! build_generic.log
make installworld DESTDIR=/mnt
make distribution DESTDIR=/mnt
make installkernel DESTDIR=/mnt

Now you need to cre­ate /mnt/etc/rc.conf (set the default­router, the IP address via ifconfig_IF (and do not for­get to use the right IF for it), the host­name, set sshd_enable to yes, add an user (I used “vipw ‑d /mnt/etc”) which is in the wheel group so you can login remote­ly, and maybe oth­er things you are inter­est­ed in), /mnt/etc/resolv.conf, /mnt/etc/hosts. Final­ly, do not for­get to load the gmir­ror mod­ule, it will safe a lot of head-scratching (yes, an echo would be short­er, but WP con­verts the single-quotes to double-quotes), and add the rootfs to the fstab:

cat > /mnt/boot/loader.conf <<EOT
geom_mirror_load="YES"
EOT
echo "/dev/mirror/root0a / ufs rw,noatime 1 1" >/mnt/etc/fstab

Now we are ready to install, the image can be unmounted:

umount /mnt

The final steps are to login into the res­cue con­sole (the­o­ret­i­cal­ly you should be able to over­write even a run­ning sys­tem, but then you need to make sure there is a way to power-cycle the sys­tem remote­ly to force a reboot) of the new sys­tem and to install via a com­pressed ssh con­nec­tion (my remote res­cue sys­tem is a lin­ux sys­tem, so linux-syntax has to be used). The login to the res­cue con­sole is not shown here, but the install from the remote sys­tem is sim­ple (this assumes the image resides on a sys­tem which is acces­si­ble from the new system):

ssh -C -o CompressionLevel=9 user@myhost cat /path/to/${FILENAME} | dd of=/dev/hda bs=1m

Alter­na­tive­ly you can com­press it with bzip2 on your sys­tem and add an bunzip2 into the pipe above. This way you could even use an HTTP serv­er to fetch the file from, but then the com­mand to fetch the file needs to have a way to out­put the file it down­loads on std­out. Both ways of trans­fer­ring the image depend upon the sta­bil­i­ty of the trans­fer. If the con­nec­tion is cut, the sys­tem can not boot any­more. So if you do not have a res­cue con­sole which is inde­pen­dent from the con­tent of the hard­disk, you bet­ter have a plan B.

If I did not make an error here (I did this some months ago, I hope I did not for­get to write down some impor­tant step and also cor­rect­ed all steps which where not writ­ten down cor­rect­ly), you did every­thing cor­rect­ly too, and the remote sys­tem does not need oth­er ker­nel mod­ules loaded, you can now reboot the new sys­tem, cross your fin­gers for some moments, and then login to the new system.

Post install TODO

Now you should have a basic sys­tem up and run­ning, and you can start to con­fig­ure it.

I added two more FreeB­SD par­ti­tions, 1 GB for swap, and the rest of the hard­disk (I took care to not have the last par­ti­tion cov­er also the last sec­tor of the hard­disk, else gmir­ror will think it has to mir­ror the entire hard­disk and not only the last par­ti­tion) as one big par­ti­tion. For the sec­ond hard­disk I made the same par­ti­tion­ing as for the first harddisk.

Then I cre­at­ed two more gmir­rors, one mir­ror for the swap, and one for the rest of the space. The mir­ror for the swap I cre­at­ed with the option “-F”, to not syn­chro­nize the par­ti­tion after a pow­er fail­ure (not nec­es­sary for swap). All two I also cre­at­ed with the “-n” option, to not sync the con­tents (there is noth­ing yet, so it does not mat­ter what is writ­ten there).

Now just a quick “bsd­la­bel” on the two mir­rors to cre­ate a “b”-partition for the swap and a “d”-partition for the large par­ti­tion. To add the swap it is just an “echo /dev/mirror/swap0b none swap sw 0 0 >/etc/fstab”. Do not for­get to add the big par­ti­tion to the fstab (after doing a “newfs” off course).

To be sure it will sur­vive a reboot, do a quick test of man­u­al­ly mount­ing the big par­ti­tion (use the easy man­u­al way via “mount /place/where/it/is/mounted” after adding it to the fstab, not the com­plete man­u­al way, this is meant to test the fstab entry too), and a “swapon ‑a” to test the swap. I also made a reboot test, just to be sure every­thing is ok.

The final step was to add the par­ti­tion on the sec­ond hard­disk to the rootfs (“gmir­ror insert ${ROOTFS_NAME} /dev/…”).