Anyways, the offer boasted…
- A HASP HL “Time” dongle with built-in AES, host-accessible 4kB EEPROM, and “tamperproof” real-time clock (RTC).
- A cross-platform SDK with libraries and example code in C and a handful of other languages.
- Printed API documentation.
After pestering them with a few emails over the course of a week, AKS sent me the kit and it arrived just in time to distract me from the first round of exams during my Senior year `X|`
The SDK includes a demo application which can…
- Read/write the token’s EEPROM.
- Ask the token to encrypt/decrypt data with its key.
- Read the RTC.
To prevent its use in a commercial setting, AKS hard-codes the encryption keys on its evaluation kit tokens.
So, I set out to make use of one of the ”un-crippled” features: the on-token EEPROM. Claiming 1,000,000+ read/write cycles, it seems like a nice place to store ”my own” encryption keys or perhaps store two-factor authentication data.
At the time, Miklos Szeredi had just released his Filesystem-in-userspace (FUSE) framework thus extending the Real Ultimate Power(tm) of the *NIX “everything-is-a-file” paradigm to mere mortals1.
I hacked up the demo application to implement a bare-bones FUSE filesystem – one which provides a single file, `hello`, backed by the token’s EEPROM. I call the result “haspfuse“.
Here are its limitations. See the haspfuse code for details.
- The filesystem only supports a single file. This wouldn’t be too bad if you were to stack a fuse-zip or archivemount-based tarball-backed filesystem on top. Don’t even think about JFFS(2) or ext2 – they each require more than 4kB for a single block.
- The single file has a fixed size of 3584.
- No operation besides: `getattr`, `readdir`, `open`, `read`, `write`, `truncate`, and `chmod` is supported.
- The filesystem probably isn’t “eject-safe”. See FUSE’s `direct_io` for a starting point.
Additionally, a proprietary blob “driver” named `aksusbd` and a static library from the SDK named `libhasp_linux.a` are required. I had trouble with version 3.5.0 so I included v1.8.1 with the haspfuse code.
`aksusbd` is a userspace driver that employs usbfs to interact with the token. Unfortunately, the deprecation of usbfs is apparently now complete with the release of the 220.127.116.11 Ubuntu kernel. This means that the old standby methods for re-enabling it no longer work.
You’ll need to use a custom kernel with usbfs support, or better yet, develop an open source driver for these tokens!
The latter approach would be especially helpful because my friend Bob claims that “`aksusbd` is setuid root and full of vulnerabilities”. But that’s another story…
Be aware that various AKS licenses and draconian US laws may prohibit you from reverse engineering `akusbd`.
What Bob and I learned
- Filesystem design for severely space-constrained storage devices.
- How to build a virtual filesystem using the FUSE C API.
- Methods for rebuilding ELF symbol tables and the idiosyncrasies that result when the binary is dynamically-linked and uses the Native POSIX Thread Library (NTPL).
- The software tools available for USB protocol reversing.
- The myriad sorts of implementation failures that lead to “cracked” hardware tokens.
- etokenonlinux.org – A great resource for using other AKS tokens to do two-factor authentication, one-time password storage, and encrypted partition unlocking The Right Way™. Provided by Cornelius Koelbel.
- Guy-Gregoire Leclercq’s detailed notes on using the eToken 64k with OpenCT/OpenSC on Debian.
- Andy Smith’s rebuilt, OpenSC-enabled, openssh-client and how to store SSH keys on an eToken with it.