I’ve already mentioned a number of times that I love my Mooltipass. As I like pretending to be useful and helpful, I decided that I wanted to create a simple communication library to interface with the device.
There are a number of features that a Mooltipass communication lib should do:
- Check device state Complete
- Retrieve credentials from a device Complete
- Add new credentials to a device
- Retrieve data from device
- Add data to device
- Get device storage size
At this point, I’ve broken one of my main design rules for my Tiny Little libraries, I’ve added an external dependency. I have been using libusb. I figured this wouldn’t be a big issue as it appeared to be a cross platform lib which would do precisely what I wanted on each platform with a simple interface. It turns out I was wrong. As well as OS level permission issues on Linux, on Windows, the version I was working with didn’t support hotplugging, and on OSX I couldn’t get any communications working at all. Apparently this was a known issue.
Linux works perfectly.
Unfortunately that’s not good enough, so I’ve explored a little more. It turns out that there’s another lib, hidapi, which may be the solution I am looking for as it accesses IOKit directly on OSX. Unfortunately at this stage it appears that I still cannot communicate on OSX with the device, but I have designed a setup that allows for non-hotplug. I’ll merge these changes back to the libusb version and at least I should be able to get Windows working.
So, how does it work? When it does, of course. The Mooltipass responds to commands. That means you send something, then wait for a response back. The response might come immediately, or it might come after a few seconds while the user has time to respond, depending on the command. I began with a synchronous interface to retrieve the Mooltipass’ state. After that worked, I added an asynchronous interface for the state lookup. This sent the command to libusb and then got a callback when the transfer had completed. Then it requested the data receive, and again got a callback when it had completed. This was then sent to a callback provided by the original request, outside of the library.
The device structure then contained a little state machine, as it was waiting for the responses from libusb, it marked itself as busy so you can’t send any more requests until the current one had completed. In theory you could stack up requests for the Mooltipass and retrieve the results one after another, but I thought that this would overcomplicate the library significantly as I would have to somehow keep track of all the requests and their relevant callbacks.
Adding the credential request was similar to the status request. The main difference was that it consisted of three separate commands (select context, get login, get password) which meant that the state machine had to be slightly more complicated to handle the multiple commands and potential error cases for each of them.
One issue I have with the potential change to hidapi would be that it doesn’t have an asynchronous interface. The options would either be to add threads to tlmp or to use the OS APIs directly and hope they have async calls.
Tiny Little MooltiPass is now ‘usable’ on Linux. I have been playing with the idea of hooking it up to slock or slim to test Mooltipass based login to my netbook. In theory it should be relatively straightforward to request credentials with gethostname as the domain and use the callback to login. I’m quite happy with the interface at this point, so it should be a good proof that the system works, and can keep me from modifying the interface at a later date.
What I would like to also do is hook up the Mooltipass lib to wrap around something like ssh and use the data storage to keep ssh keys. Still, something for the future.