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

RFE: Support TPMv2 wrapped PEM keys #14

Closed
dwmw2 opened this issue Jun 16, 2023 · 4 comments
Closed

RFE: Support TPMv2 wrapped PEM keys #14

dwmw2 opened this issue Jun 16, 2023 · 4 comments

Comments

@dwmw2
Copy link

dwmw2 commented Jun 16, 2023

Ideally, applications should silently accept a PEM file containing a -----BEGIN TSS2 PRIVATE KEY----- and use the TPM for it without asking the user to do anything more.

This is the file type supported by GnuTLS and the two OpenSSL engines, as well as other things like OpenConnect. It's documented here

Please consider supporting this format. There's example code at https://github.com/dwmw2/rolesanywhere-credential-helper/blob/tpm/aws_signing_helper/tpm_signer.go which is Apache v2 licensed and you're welcome to use.

@salrashid123
Copy link
Owner

thanks for the pointer.

yeah, i'm aware of the wrapped format which as you cited, i used with openssl (eg for nginx+ssl

this repo is pretty much scratchpad for tinkering w/ stuff only (i.e nobody should use this in prod as-is)...but will try to find sometime to add it in (since you've got it working, i'll cite your repo and attribution for any of the structs i use).

on the topic of AWS, apart from signing, you maybe interested in HMAC based auth (i.,e you can save the access secret to tpm (or import or duplicate, and then use it for authentication.

@dwmw2
Copy link
Author

dwmw2 commented Jun 16, 2023

yeah, i'm aware of the wrapped format which as you cited, i used with openssl (eg for nginx+ssl

Nice, but I hate that you have to do anything except give nginx the /root/tpm_certs/tpm.key as its private key file. All that messing around with openssl.cnf and explicit OpenSSL engine stuff is not something any user should ever have to do. Is there already a bug open with nginx for that?

this repo is pretty much scratchpad for tinkering w/ stuff only

Background: http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

tl;dr: We should stop hating our users and making life hard for them. This stuff should Just Work™ — whether they give us any sensible kind of file, or just a PKCS#11 URI in place of a filename, or whatever.

The crypto libraries seem to actively make it hard for applications to get that right. It takes hundreds, perhaps even thousands of lines of code, to make an application which simply conforms to what I've written there, which I consider best practice.

Perhaps we should take something based on your code and turn it into a standard library for "give me a crypto.Signer and a cert based on (certificateId string, privateKeyId string)" and stop expecting application authors to do all the work?

@dwmw2
Copy link
Author

dwmw2 commented Jun 16, 2023

on the topic of AWS, apart from signing, you maybe interested in HMAC based auth (i.,e you can save the access secret to tpm (or import or duplicate, and then use it for authentication.

https://github.com/salrashid123/aws_hmac

Nice. Duly heckled at the PKCS#11 support there :)

Now, can we get to a mode where role credentials for an instance are not presented in plain text through IMDS but are instead presented as a TPM-loadable key for the NitroTPM of that instance?

@salrashid123
Copy link
Owner

agree, its incredibly tedious to do anything with all this

re: simplify nginx, i'm not sure if there is any bug to make it easier (either cognitively or convenience is the number of specific steps require).

re: pkcsURI for the aws_hmac stuff.
you're right; i'll reply on that issue/repo.
that stuff i really should add in; i'll work on that shortly.

The idea for the aws_hmac was really to allow users ouside of AWS environment to securely stash their creds (vs in a file). I don't know much about nitro so i can't really comment there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants