Questions for a Kingston DT5000 driver
Joel Holdsworth
joel at airwebreathe.org.uk
Tue May 6 19:56:00 EDT 2014
Hi Folks,
I've just joined this ML, and I'm hoping someone can give me some advice.
I've been experimenting with Kingston DT5000 hardware encrypted usb pen
drives, and I'm hoping to write a driver.
The DT5000 drives are probably most useful in corporate settings, where
sensitive need to be protected. They might also be useful for machines
that have sensitive information that must be left unattended. They also
have excellent tamper evident characteristics.
The device is a composite device containing an ejectable mass storage
device, and a read only virtual cdrom. The cdrom contains windows
software which autoruns and pops up a dialog that prompts the user to
give the password, this is then conded and sent to the device via USB
vendor control packets.
I've got quite far hacking around with the device with pyusb and usbmon,
and now I'm trying to gather information for a driver, so I have a few
questions:
First, via a series of messages the host PC uses Elliptic Curve Diffie
Helman to establish a shared secret with the DT5000. The shared secret
is then used to encrypt the password hash. I couldn't find any elliptic
curve code in the kernel. Is this correct? Perhaps there are patent
concerns? are there any plans to add it in?
For a device like this, how would the user space interface look? Would
one just make a sysfs file into which the the password plaintext is
written? Or is it more normal to enter it via some userspace application
that hashes and encrypts the password with the shared secret. Does
dm_crypt, or IPSEC stuff offer a pattern to follow here? Or are there
any very simple examples of password locking devices?
I'm trying to figure out where the crypto work should be done. If the
kernel did all the crypto, I guess the password interface would be very
simple. If the task is split with user space then this is going to
expose all this password hand-shake protocol to userspace - not such a
slick interface I would say.
Also, the device contains a few user programmable fields: For example
the owner's name, address, and a hint for the password etc. These things
are read-only when the device is locked, but become writable when the
device is unlocked. I suppose this information would be communicated via
sysfs. Is the pattern generally to have a separate file for each one?
Also are there any general comments that I should take on board as I
embark on this?
Thanks for your help
Best Regards
Joel Holdsworth
More information about the Kernelnewbies
mailing list