Well, don't say I didn't warn you. Let me say in advance that many of these steps are somewhat magic, and please contact me if something is unclear.
Okay, the art and science of using a Java Ring with keymgr. There are several steps to this process. Firstly, you will need some appropriate software on the Java Ring itself. I wrote a simple little applet which ballooned into a monster as I speculated about keeping DH keys and various other accessories on there. A tarball of the Java source files is available here.
If you aren't familiar with the process of building and downloading applets for your Java Ring, look here.
Once you've downloaded it using those arcane and mysterious instructions, things only get worse. Firstly, you need to extract your ssh key into a usable format. I must admit, once again, I haven't written any neat tools to do this. I did put in a hack into keymgr to assist, though. I would call it an undocumented hack, but...
Anyway.
The first thing you need to do is modify the keymgr a touch. At the end of the keymgr.c file, you'll find some lines that close the usual file descriptors. Delete them and recompile. This is simply due to the fact that the aforementioned hack dumps to stdout or stderr, and isn't particular useful if the aforementioned file descriptors are pointing to an ssh waiting for a decrypted challenge.
Now having done that, append the word 'dump' to the 'load ssh' line in keymgr's rc file. Like so:
load null load ssh dump load gtk load ow
The net result of this will be a hexbyte dump of a few useful things when keymgr plays with ssh keys.
Start up the modified keymgr, and ssh-add the ssh key that you want to transfer onto your iButton. On the shell that you started keymgr from, you should see a dump of the relevant bits of the key.
Now I need to digress a little bit. The iButton has a 128 byte incoming message buffer. When you're talking APDUs at it, the various overheads drop the actual maximum APDU payload down to 114 bytes.
A typical ssh key is 1024 bits long - that's 128 bytes. The typical solution for this with the Java iButton is to have one APDU instruction defined for initializing an array and loading a value into it, and another for appending to it.
Which is what the Keyring applet does.
The Keyring applet looks for a class byte of 0x80. For the first load into an array, the instruction byte should be 0. To append, it should be 1. P1, for the purposes of loading, should always be 0. P2 signifies which particular variable you're loading.
For loading an RSA key, we need to give the applet an 'N', an 'E', a 'D', and an identification string. The dump facility in keymgr doesn't give you a useful id value. Sorry. The P2 bytes corresponding to these four variables are 0, 2, 1 and 6, respectively.
So, the commands you issue are, approximately:
jibapdu 0x80 0 0 0 < first half of N cut and pasted from keymgr >
jibapdu 0x80 1 0 0 < second half of N cut and pasted from keymgr >
jibapdu 0x80 0 0 2 < E is typically only a single byte >
jibapdu 0x80 0 0 1 < first half of D cut and pasted from keymgr >
jibapdu 0x80 1 0 1 < second half of D cut and pasted from keymgr >
jibapdu 0x80 0 0 6 < some kind of useful ASCII values >
Note that these are just space separated hex bytes.
Minor digression: at any time, you can read back a variable by passing in an instruction byte of 2 for the first 64 bytes, or 5 for the second. This is useful when you're manually feeding a challenge in and retrieving the decrypted response.
Once you've done fed in the data, you create the key. To do this, send an APDU with an instruction byte of 3.
jibapdu 0x80 3 0 0
Right. That should about do it. Now you can click the Find-JiBs button on the keymgr console, and things should progress smoothly, if slowly.
If you want to verify manually that things are working, you can. Firstly, still with your modified keymgr that you've fed a key into, ssh somewhere. It should dump hexbytes of the challenge and response.
If you load the challenge into the iButton, using a P2 byte of 5, but otherwise identically to the procedure for loading any element of the key, and then send an APDU with an instruction byte of 4, the iButton should theoretically churn away and come up with the decrypted value. Note that this is a little fragile: libow arbitrarily gives the iButton two seconds of power to do this. In my case, I found two seconds was enough, but one wasn't. YMM(BPS)V.
If that comes back with an SW of 0x9000, things worked! Read out the response using instruction bytes of 2 and 5, as explained above, and a P2 of 4, and you should find that it matches the response bytes dumped from the modified keymgr.
I can anticipate your first question: Why is it so bloody slow?
This is actually libow's fault. The iButton (well, my iButton) takes somewhere between 1 and 2 seconds to authenticate a key. libow is dumb. When the iButton needs power, it gets two seconds of power. Worse, I think there's one or two other operations in there, when exchanging an APDU, that also get two seconds of power (quite unnecessarily, since they only need about 60 ms). This will be fixed in 0.2.
Secondly, there are two communications speeds on the 1-wire bus. There is the normal one, which I happen to have forgotten the speed of, but it's something close to 10 kbits/sec. This what libow runs at. There is also an overdrive speed, which is about 140 kbits/sec. libow doesn't support this yet, but hopefully it will next version.
And to answer the second question that you are (hopefully) too polite to ask; I released it in it's current version because I was dancing around the room in glee the first time I managed to authenticate off the iButton, regardless of the speed. For the record, that happened at 5.14 am, on Thursday the 27th of April. Not that I'm particularly proud of getting it to work or anything :)