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
Comments
Unless I misunderstand you, aren't you basically just suggesting "implement HSM-style CKM AES key wrapping" ? |
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. |
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. |
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? |
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?
The text was updated successfully, but these errors were encountered: