Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow user-controlled private keys #9

Open
jas4711 opened this issue May 9, 2023 · 4 comments
Open

Allow user-controlled private keys #9

jas4711 opened this issue May 9, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@jas4711
Copy link

jas4711 commented May 9, 2023

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/tkey-ssh-agent#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?

@udf2457
Copy link

udf2457 commented Aug 19, 2023

Unless I misunderstand you, aren't you basically just suggesting "implement HSM-style CKM AES key wrapping" ?

@jas4711
Copy link
Author

jas4711 commented Aug 19, 2023

SSH keys are Ed25519 and not AES keys, but yes, some similar functionality is what I would like. I want to generate my Ed25519 key using a randomness generator that I can audit, rather than being forced to trust the Tillitis RNG.

@udf2457
Copy link

udf2457 commented Aug 19, 2023

True, but the AES is just for wrapping. I have a YubiHSM and you can optionally export keys in an AES wrapped state, the keys can be in any of the algorithms supported. The YubiHSM just follows the NIST AES-CCM standard.

@secworks
Copy link
Contributor

One could definitely build an app that would use the CDI to generate a key wrapping key, and use that do verify integrity as well as decrypt an Ed25519 key pair to be used instead of a generated key pair. The USS would then be important to ensure that the CDI will be something you control. The app would have to support either loading the wrapped key pair, or receiving a keypair, wrap the key pair and return them to the client.

We have talked about writing an example app that use the CDI for wrapping some sort of internal data and send it to the client, to be loaded later on and unwrapped. This would be useful for TOTP, HOTP applications. Basically an AE-protected cookie.

The exact wrapping mechanism can be discussed. AES-CCM is possible. AEC-OCB, AES-SIV, AES-KEYWRAP ar all possible alternatives. Or something totally different. What would you choose?

@dehanj dehanj added the enhancement New feature or request label Sep 11, 2023
@dehanj dehanj transferred this issue from tillitis/tkey-ssh-agent Sep 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants