TKeys with non-standard UDIs

[quite]

Caveat: this is me using a TKey flashed by myself, and with "random" UDI. I understand that we can be expected to be on our own in this case.

With the v1.1.0 release fixing the USS issue, and with my specific TKey, I ran into a changed pubkey because my UDI's ProductID (pid) happened to be pid >= UDIPIDCastor. I read the docs saying --force-full-uss Force use of 32 byte USS digest. Default is 31. and thought I was good. But there were details in the tkeyclient code. Though I see now that on main the docs have been adjusted, now saying Castor and later defaults to 32 bytes, nice (still, my homebrew TKey is not a Castor :)

So it looks like the v1.1.0 release of tkey-ssh-agent brought about the first prominent user-facing decision based on UDI.

On main I now also see that device-app will be based on ProductID. In my case, the function making that decision is going to return an error.

I wonder if anything can be done to cater for non-standard ProductIDs (etc)? Would it help to lock also on Tillitis VendorID (0x1337), when making hardcoded decisions for standard TKeys? But maybe that would still end up requiring various config flags, which could blow up complexity -- probably flags like --really-force-short-uss and --device-app {precastor,castor,foo} just to begin with. Perhaps folks like me should just be expected to also patch and build our own software (again, said in good faith).

[niels-moller]

My 2 cents:

• For the full-uss-flag (and for any similar flags in the future), I think it would be desirable with three states: "auto" (the default), "yes" and "no", where only the "auto" state tries to make a reasonable decision based on device ids, and the explicit variants can be used as overrides.
• I think it makes a lot of sense with a --device-app flag to let user override the device app to load, without having to recompile the host app. Argument can be a file name, say foo-app.bin, possibly with some magic syntax to instead reference one of the embedded apps.

[jas4711]

+1 on --device-app -- this is already reported in #125

Where is this UDI coming from? Is this trustworthy and integrity protected information? Basing security-relevant decisions based on information coming from the device seems a bit weird to me.

[niels-moller]

Where is this UDI coming from? Is this trustworthy and integrity protected information? Basing security-relevant decisions based on information coming from the device seems a bit weird to me.

The device seems implicitly trusted. In principle, it would be nice to somehow verify authenticity of the device and establish an encrypted channel before telling it the (hash of) the USS. But current state, as I understand it, is that if I could trick you to insert my fake tkey, or if I can eavesdrop the USB bus, then I could get your (hashed) USS. And I think that is somewhat reasonable: Once you have an attacker's USB devices attached to your computer, you're likely in lot of other trouble as well.

[jas4711]

Where is this UDI coming from? Is this trustworthy and integrity protected information? Basing security-relevant decisions based on information coming from the device seems a bit weird to me.

The device seems implicitly trusted. In principle, it would be nice to somehow verify authenticity of the device and establish an encrypted channel before telling it the (hash of) the USS. But current state, as I understand it, is that if I could trick you to insert my fake tkey, or if I can eavesdrop the USB bus, then I could get your (hashed) USS. And I think that is somewhat reasonable: Once you have an attacker's USB devices attached to your computer, you're likely in lot of other trouble as well.

Would a USB-man-in-the-middle tunnel device be able to trick tkeyclient or tkey-ssh-agent into a different behaviour somehow? Assuming the user inserts the real trusted device into a malicious USB cable. I think the software running on the host has to assume the worst from the device side, and shouldn't trust things it cannot verify.

[dehanj]

@quite The short term solution for your TKey is to downgrade, if you don't have an affected USS you are fine (but be aware to check if you start using a new USS).

I wonder if anything can be done to cater for non-standard ProductIDs (etc)? Would it help to lock also on Tillitis VendorID (0x1337), when making hardcoded decisions for standard TKeys? But maybe that would still end up requiring various config flags, which could blow up complexity -- probably flags like --really-force-short-uss and --device-app {precastor,castor,foo} just to begin with. Perhaps folks like me should just be expected to also patch and build our own software (again, said in good faith).

As you see in the code the reason is simply to support multiple version of hardware, such as upcoming Castor. The guarantee is that our apps support TKey Unlocked that are built according to our documents at dev.tillitis.se. It includes the UDI (except for the serial number part which you can choose freely). It can definitely be written more clearly that if you don't follow this the apps might break in all kind of different ways.

As you say, I think it would be hard to accommodate all different variants people might build on their own, but I think it is far fetched to say that you should expect to patch and build your own software. At least for this thing. Unless it is a hard requirement for you to have random data in the product id and revision field of the UDI.

[quite]

The guarantee is that our apps support TKey Unlocked that are built according to our documents at dev.tillitis.se. It includes the UDI (except for the serial number part which you can choose freely). It can definitely be written more clearly that if you don't follow this the apps might break in all kind of different ways.

Currently on https://dev.tillitis.se/unlocked/build/ it is written to use:

Vendor ID, use 16 (decimal)
Product ID, use 8 (decimal)
Product Revision, use 3 (decimal)

This will cause the exact problem I have run in to, my ProductID even happen to be 8 (decimal).

Since this is already in the open, it would be very nice if you implemented Nisses suggestions in #150 (comment)

[dehanj]

Well, that is a problem. Which is obviously missed..

[mchack-work]

@quite Here's a PR that hopefully solves your immediate problem: tillitis/tkeyclient#26

Please try it with the v1.0.0-maintenance branch.