Questions for a Kingston DT5000 driver

Questions for a Kingston DT5000 driver

[Joel Holdsworth]

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

Questions for a Kingston DT5000 driver

[Bjørn Mork]

Joel Holdsworth <joel@airwebreathe.org.uk> writes:

> 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.

And after this the password application quits and the device is unlocked
and works as a normal usb-storage device until it is unplugged?  Or
ejected?

Or are all storage transactions encrypted?

> 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?

udisks offer a D-Bus API and a 'udisksctl lock|unlock' command using it:
http://www.freedesktop.org/wiki/Software/udisks/

But as usual with fdo projects, this might already be obsolete for all I
know...

> 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?

If the device can work with the generic usb-storage driver after a
device specific initialization, then I would propose using a libusb
based userspace application to initialize it.  This application could be
autorun by udev when the device is detected.  A kernel driver is not
required.

Doing it in userspace has quite a few advantages.  Like: Most of your
questions becomes void :-) And you are free to use whatever crypto
library you need.  And the choices you have to make, like how to get the
password from the user, are not carved in stone as a kernel userspace
API.

See also
http://linuxdriverproject.org/mediawiki/index.php/No_Linux_Driver_Needed


Bj?rn