-
Notifications
You must be signed in to change notification settings - Fork 28
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
Make attest-enroll
more configurable, pluggable; make it escrow and make it use AEAD
#125
Conversation
03eba1e
to
df67546
Compare
Need to add tests. |
Here's a sample config:
The Each
The idea is to allow multiple additive enrollments (when the Note that multiple hostnames are allowed, if you keep enrolling the same |
Maybe this script could also |
|
eff54e9
to
881cb5c
Compare
|
ecd7747
to
09a9256
Compare
Now with a test (which I'm running manually). I need to integrate it into the Mariner and non-Mariner workflows. The test starts an swTPM for each of three simulated clients and an swTPM for an escrow agent, checks that all the clients can enroll, and then checks that TBD:
|
attest-enroll
more configurable, pluggable; make it escrow and make it use AEAD
Not ready. I've got to finish changing various bits of various scripts. |
I may need to make each
Thoughts? |
30f54dd
to
182db39
Compare
I now have a complete test -minus HTTP- that works. It tests I've also added TOFU golden PCR learning, which I needed for now, especially for testing. I've removed uses of TBD:
|
Regarding privsep... the code that does the secrets generation, and the git add/commit/push, all has to be privsep'ed from the flask code (HTTP server) if we're going to do privsep at all, because otherwise a compromise of the HTTP server would allow the attacker to push known-to-them |
"77 files changed". This is going to take a little while to review... For the most part the fixes for more modern
The different policies for different keys makes lots of sense. That's something that we should figure out if there is a clean way to specify the alternate policy. More later. |
Regarding the changes to
|
The house style is one hard-tab for each indentation and for multi-line shell commands to put the arguments one tab stop deeper, regardless of the length of the shell command so that changing commands doesn't require re-indenting the additional lines, with one argument and parameter per line, and with the line continuation characters one space separated from the end. For tpm2 subcommands, I've been meaning to make sure that we're using long arguments everywhere to try to document their meaning as well. Not all the code has been updated to use this, I'm trying to do it consistently in the new code. So instead of this:
The style guide would call for:
|
For
|
One additional bit of flexibility that we should consider as part of the pluggable enrollment is that Windows requires specific per-machine file names for the encryption key. I've created a separate issue so we don't forget to think about it after this is merged #129 |
This adds aead_encrypt and aead_decrypt shell functions that implement confounded and padded AES-256-CBC with HMAC-SHA-256 for integrity protection. AEAD == authenticated encryption w/ additional data These utils are not quite AEAD because there's no AD support yet, though it should be easy to add, being just more data thrown into the HMAC computation input stream.
This: info() { ((VERBOSE>0)) && echo "$*"; } breaks when VERBOSE == 0, causing `info` to return 1. The issue is that there was no successful command in `info` when VERBOSE == 0. Rewrite as: info() { ((VERBOSE>0)) && echo "$*"; return 0; }
Just gotta make sure that EDIT: |
I think this is very close now. |
Do not validate any PCRs in phase 1. There's still code to TOFU learn golden PCRs for phase 2 systems... But! That's on the attestation server side, which has a read-only DB. How can that ever work? It can't. We need a different plan for any "golden" PCRs handling.
This now also handles the PEM case using the fix from BTW, it isn't actually necessary for the I do have a test in |
# Compute the policyDigest of a given policy by executing it in a trial | ||
# session. | ||
function make_policyDigest { | ||
tpm2 flushcontext --transient-object |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tpm2_flushsome
?
|
- tpm2-send encrypts a small secret to an EKpub using either of two encryption-to-TPM methods: - use TPM2_MakeCredential() with a well-known key's cryptographic name as the activation object's name, - use TPM2_Duplicate() to export a software RSA keypair to the EKpub and then encrypt the small secret to the RSA keypair. Both methods allow an optional policy to be asserted by the sender that the target TPM will enforce at decrypt time. - tpm2-recv decrypts ciphertexts made by tpm2-send Any policy asserted by the sender has to be provided for the purpose of executing and satisfying it. The two methods have the same characteristics and are morally equivalent: - all the sender needs is the target's EKpub, - only an entity with access to the target's TPM can decrypt ciphertexts addressed to that target - the sender gets to assert a policy that the target TPM will enforce when it comes time to decrypting the sender's ciphertext, Credit: - Trammell Hudson came up with the TPM2_Duplicate() approach - Erik Larsson came up with the TPM2_MakeCredential() approach
Also: use the tpm2-send/tpm2-recv scripts.
Tested manually.
This PR adds:
TBD:
git add
/git commit
/git push
, or whatever, at the end of enrollmentCurrent usage message: