tillitis / tkey-device-signer Goto Github PK

Thanks for your work on tkey.

It would be nice to see a version of signer that supports old-school algos such as RSA and the NIST p-curves.

I know Ed2559 is awesome and all that, but unfortunately there are applications that don't yet support Ed25519. For example CNCF project SPIFFE/SPIRE only supports EC or RSA key types. Using tkey in conjunction with SPIFFE/SPIRE could be a very interesting use-case for tkey.

Sadly whilst I am a proficient Go programmer, my C knowledge is non existent. And so sadly because tkey apps need to be written in C I would be too worried about messing up C crypto myself !

I think this will be useful, and needed for certain applications. Do this in the signer-app using our hw timer, and let the Go API return some timeout error when it happens. Maybe as a follow-up to tillitis/tillitis-key1-apps#47 (does it conflict?).

Can the timeout be configurable? If not, how many seconds?

Verification of an ed25519 signature with the monocypher crypto_ed25519_check() seems to fail, unless I did something wrong.

Fails on both real hardware (red LED) and qemu.

Did we implement some memory function in tkey-libs wrong?

See branch test-verification for a test version of the signer:

https://github.com/tillitis/tkey-device-signer/tree/test-verification

While #8 would be nice for me, I realize some use-cases that requires me to control the private key generation myself, and would thus not even want to generate private keys on the device at all. I couldn't find a feature request to support this, so I'm opening this for discussion. I think the simplest approach is to resolve tillitis/tillitis-key1-apps#34 and then "import" private keys into the device by encrypting them once, and then later supply the encrypted blob which is decrypted by the device, and its private-key operation is performed, and the output returned. Thoughts?

Hi. I'm wondering if the key derivation of the Ed25519 private key could be strengthened, so that I'm able to verify that some randomness provided by the host was included in the resulting private key or public key. Right now key derivation is memcpy:

https://github.com/tillitis/tillitis-key1-apps/blob/f45a70040059b54831ede297f892a65476f103c7/apps/signer/main.c#L66

The CDI takes USS from the user, but from my limited understanding, there is no way for me as a user without hardware knowledge to verify that the USS provided ended up in the CDI in the documented way, or am I missing some method?