Comments (9)
I agree we could probably eliminate the self-certify and still get the security properties we want. A few things:
-
I implemented it this way at the beginning to mirror the behavior of the windows Platform Crypto Provider, which generates + ships a creation certification while bootstrapping.
-
We are using
CertifyCreation
rather thanCertify
, which demonstrates that the caller created the key in the same breath as when the certification was invoked (via ticket/creation hash data), or at least a certification was done within that context and then stored.
While we don't support it now, self-certification can include extra data, which can become a nonce to prove the AK was created for a specific purpose / CA (as opposed to re-using an existing AK).
I didnt plan on using the other data, as it would be obfuscated for keys not produced under the endorsement hierarchy.
from go-attestation.
I implemented it this way at the beginning to mirror the behavior of the windows Platform Crypto Provider, which generates + ships a creation certification while bootstrapping.
Interesting. Is this publicly documented anywhere, or just details reverse engineered through using it?
(I've tried looking at Microsoft's documentation about TPMs, but it often seems very high-level and abstract; I'd love if they had any detailed documentation explaining secure TPM usage that I could peruse.)
We are using CertifyCreation rather than Certify,
Oops, yes, I meant TPM2_CertifyCreation. (Wouldn't be able to trust the TPMS_CREATION_DATA otherwise!)
While we don't support it now, self-certification can include extra data, which can become a nonce to prove the AK was created for a specific purpose / CA (as opposed to re-using an existing AK).
Ack. I was considering that. I'm just not sure I can envision why the server would be concerned about AK reuse. Maybe I'm not being creative enough though.
If long-lived, reused RSA 2048 / NIST P-256 keys are a security risk, then EKs are probably about as compelling of a target as AKs. Admittedly, an attacker who successfully compromises an activated AK is one step ahead of an attacker who only compromises an EK, as the EK-attacker will first need to use the compromised EK to enroll a compromised AK. (Maybe I'm underestimating how hard this would be to do undetected.)
There's a privacy concern regarding AK reuse, but this is probably something the client has to be more concerned about rather than the server anyway. E.g., the server can't guarantee that its own AKs aren't mistakenly reused for some other purpose, nor can it prevent the client from intentionally correlating multiple AKs that it controls.
I didnt plan on using the other data, as it would be obfuscated for keys not produced under the endorsement hierarchy.
Fair point. I was assuming if you really did want/need that data, that you would just create the AK within the endorsement hierarchy, and then require appropriate endorsement authorization. But maybe that's not an option?
from go-attestation.
Interesting. Is this publicly documented anywhere, or just details reverse engineered through using it?
(I've tried looking at Microsoft's documentation about TPMs, but it often seems very high-level and abstract; I'd love if they had any detailed documentation explaining secure TPM usage that I could peruse.)
The only documentation available that I've found is the pdf in a github repository: https://github.com/microsoft/TSS.MSR/blob/9fb1fac9ee6b7ee2dfe8040069ae68e09d948d0d/PCPTool.v11/Using%20the%20Windows%208%20Platform%20Crypto%20Provider%20and%20Associated%20TPM%20Functionality.pdf
Ack. I was considering that. I'm just not sure I can envision why the server would be concerned about AK reuse. Maybe I'm not being creative enough though.
I haven't cared enough to implement it, but my guess is a nice separation of concerns.
Fair point. I was assuming if you really did want/need that data, that you would just create the AK within the endorsement hierarchy, and then require appropriate endorsement authorization. But maybe that's not an option?
Yepp, but for windows we would need to implement delegate authorization and read the authorization value out of an undocumented registry key.
from go-attestation.
From what I can tell, with this change AK activation should be possible with just the EK certificate and AK public key on both TPM 1.2 and 2.0. Does that sound right?
from go-attestation.
@brandonweeks I'm not really familiar with TPM 1.2, sorry.
But on TPM 2.0 at least, the server still needs the AK's TPM2B_PUBLIC structure (which contain's the AK's public key), since that's (1) how you compute the Name to use with TPM2_MakeCredential, and (2) how you verify that its attributes are appropriate (e.g., that it's restricted, non-exportable, and TPM-generated).
However, if the server wants to force the client to generate a new AK (which Microsoft at least seems to think is valuable, but I'm still unclear on), you need the TPM2_CertifyCreation data.
from go-attestation.
Sorry for the delay, forgot to respond and realised when looking at a different change.
From what I can tell, with this change AK activation should be possible with just the EK certificate and AK public key on both TPM 1.2 and 2.0. Does that sound right?
No. We would need to know the version of the TPM, and whether to use the tcsd credential activation format.
While we could eliminate checking of the self-certify to simplify this flow, I'm not a huge fan of removing the requirement for the client to ship TPM2B_PUBLIC
. We don't control the template that microsoft uses to create attestation keys, and they can change it any time. At least by shipping it, we can verify its sane, rather than breaking the library for any change.
from go-attestation.
I've been trying to use go-attestation for the server side only, and the validation of the CertifyCreation values during the params.Generate()
call is causing issues.
Your sample and the NewAK function creates a key in the storage hierarchy if I'm not mistaken. The example I'm working on (in TSS.Net) deals with a key in the Endorsement hierarchy (which is what I require) and is also a primary key, so I don't think it can't be used for the CertifyCreation call (or I'm new enough to TPM behavior that I'm making some fundamental mistakes).
Should I be able to use CertifyCreation in this case (and have issues in my client) or is what I'm trying to do incompatible with this implementation?
from go-attestation.
Correct on usage of the storage hierarchy. Two main reasons:
- Getting authorization for the endorsement hierarchy is particularly annoying/hard, especially on windows.
- We want the AK lifecycle to roughly match the lifecycle of the OS install, rather than the life of the device. So it makes sense for it to be under the storage hierarchy (which in theory gets reset every time the system is 'rebuilt').
Creating an AK under the endorsement hierarchy is valid. Im 90% sure that creating a restricted primary key under the endorsement hierachy is also valid.
As for your other questions, do you mind opening a new issue? It might be helpful if you can share the errors your encountering and possibly some blobs of the values of ActivationParameters
? I'm not sure if what youre doing is incompatible with go-attestation at this stage.
from go-attestation.
There's probably no need to make a new issue as I don't have anything for CreateAttestation
or CreateSignature
in the ActivationParameters
as I haven't gotten CertifyCreation
to work.
From the sounds of your comment I should be able to even with a primary endorsement key, so I've probably got issues on my client code. Example code I'm working from doesn't make the call and the "server side" code in the example doesn't do the same kind of validation.
Should be fine once I get that working then. Thanks.
from go-attestation.
Related Issues (20)
- Cannot set key attributes in NewKey and RSA template doesnt allow for "decrypt" - mTLS in Chrome not possible HOT 2
- Implicit platform attestation (question) HOT 2
- A question about EK,SRK HOT 5
- rhshim introduced a MokListTrusted event, leading to failed parsing of the SecureBootState
- error code 0x04: value is out of range or is not for the correct context when Activating credentials HOT 11
- OSS-Fuzz issue 52044 HOT 1
- Wrong decoding of ints in win_events.go HOT 1
- OSS-Fuzz issue 52520 HOT 1
- OSS-Fuzz issue 53008 HOT 1
- [Windows] Guidance around access management for key-attestation on TPMs via the Windows PCP library HOT 4
- OSS-Fuzz issue 54576
- EC Nist P521 key size too short? HOT 2
- suggest go.mod version bump HOT 1
- Proposal to add tpm_event package in an experimental directory HOT 2
- Handle "AttestedCertifyInfo" in ActivationParameter checks for TPM2.0 Challenges HOT 3
- Make AttestationParameters.CreateData an optional field HOT 3
- Support using AK from NV
- Fails to parse malformed Nuvoton EK certs with leading 0s in serial number HOT 1
- MarshalSubjectAltName should support specificing if the extension is critical.
- ECDSA Support on Windows HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-attestation.