salrashid123 / signer

golang crypto.Signer for Trusted Platform Module (TPM) and Google Cloud KMS
Apache License 2.0
30 stars 10 forks source link

RFE: Support TPMv2 wrapped PEM keys #14

Closed dwmw2 closed 1 year ago

dwmw2 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.