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

Various fixes for Remote Attestation implementations #235

Merged
merged 3 commits into from
Mar 12, 2021
Merged

Conversation

zaolin
Copy link
Collaborator

@zaolin zaolin commented Feb 25, 2021

Summary:

  • Fix the wrong usage of signature decoding by using DecodeSignature function (Remote Attestation)
  • Fix decodeCertify for wrong signature decoding
  • Make EncodeCreationData public
  • Introduce OutsideInfo to key creation for key labels
  • Improve tpmutil runner with retries to stabilize virtualized TPMs usage

@zaolin zaolin requested a review from a team as a code owner February 25, 2021 15:02
@zaolin zaolin force-pushed the fix-attestation branch 10 times, most recently from 0bbd3af to e8dd2fc Compare February 27, 2021 13:03
@zaolin zaolin changed the title Improve access to data structures for remote attestation implementations Various fixes Feb 27, 2021
@googlebot I fixed it.

Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
@zaolin zaolin changed the title Various fixes Various fixes for Remote Attestation implementations Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@google google deleted a comment from google-cla bot Feb 27, 2021
@chrisfenner
Copy link
Member

Hi zaolin, I apologize in advance for my slow response time as it is a busy week for me. I would be happy to review this PR and I'm targeting getting back to you by 2021-03-05.

@zaolin
Copy link
Collaborator Author

zaolin commented Mar 1, 2021

Hi @chrisfenner, no problem at all! :)

tpm2/structures.go Outdated Show resolved Hide resolved
tpm2/structures.go Outdated Show resolved Hide resolved
@@ -827,7 +845,8 @@ type CreationData struct {
OutsideInfo tpmutil.U16Bytes
}

func (cd *CreationData) encode() ([]byte, error) {
// EncodeCreationData encodes byte array to TPMS_CREATION_DATA message.
func (cd *CreationData) EncodeCreationData() ([]byte, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this need to be exported?

(Not saying its wrong, but would like to understand the use-case. go-attestation package has been able to handle creation data by simply keeping it as bytes and only decoding when necessary, rather than doing round-trips through encode/decode).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use it to generate TPMS_CREATE_DATA structures for various tests.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the DecodeCreationData is already public. :)

if _, err := rw.Write(inb); err != nil {
return nil, 0, err
}
// f(t) = (2^t)ms, up to 2s
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awesome :D

@zaolin
Copy link
Collaborator Author

zaolin commented Mar 5, 2021

@twitchy-jsonp Any update. Does it look good to go now?

Copy link
Member

@chrisfenner chrisfenner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks good to me, thank you @zaolin for all these fixes.

Unfortunately since this looks like a breaking change, we will need to strategize about how to merge. @twitchy-jsonp, @josephlr, do you think we should rev a version number?

we could introduce another flavor of the Certify and CertifyCreation commands that returns the whole signature. CertifyCreationEx and CertifyEx2? 🤢

tpm2/structures.go Outdated Show resolved Hide resolved
tpm2/tpm2.go Show resolved Hide resolved
@twitchy-jsonp
Copy link
Contributor

I'm okay with just bumping a minor version number for this and asking users to make the (small) adjustment.

Copy link
Member

@chrisfenner chrisfenner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks good to me. If @twitchy-jsonp is OK merging as-is releasing a new minor version, then I support that plan (as opposed to some solution that involves either defining new "fixed" functions)

@zaolin zaolin merged commit 4347b8d into master Mar 12, 2021
@zaolin zaolin deleted the fix-attestation branch March 12, 2021 21:00
@tomoveu
Copy link

tomoveu commented Mar 31, 2021

I just found out about this change and I have a question.

@chrisfenner Is this a "breaking change" or a "small adjustment"?

Because I thought go-tpm maintains API compatibility. And in my opinion, breaking existing API is a major thing.

@zaolin adding new API CreateKeyWithOutsideInfo that calls create with the new argument does not help. Because the underlying create now brakes API compatibility.

@chrisfenner
Copy link
Member

Hey @tomoveu - Sorry for the inconvenience! I hope I can help.

First, a note about versioning and compatibility.
In general, go-tpm is on semantic major version 0 which means that from time to time, we have to make changes that break the existing API. Whether we use the words "breaking change" or "small adjustment", there's unfortunately change, so we don't do it except when needed (for example, to keep from having to create a lot of new flavors of existing APIs). I'd recommend depending on a specific released version of go-tpm, rather than HEAD of go-tpm main/master branch, so that such changes only affect you when you actively update dependencies, rather than transparently at inconvenient times.

The breaking API change
As far as I can see, there is no API compatibility issue with the public Create functions. Are you depending on the private create function, which took a refactor in this change? The breaking I was referring to was that code that depends on Certify* functions needs to deserialize the second parameter differently, into the structure that maps to TPMT_SIGNATURE (via DecodeSignature) instead of a raw RSA/ECC signature with scheme and hash algorithm unknown, to be passed directly to something like ecdsa.Verify. I'd be very interested to know if this change causes problems for users of public Create* APIs.

josephlr added a commit to josephlr/go-tpm-tools that referenced this pull request Feb 15, 2022
PolicySecret now returns three values (google/go-tpm#237)

We never read the encoded value from Certify, so we are not affected by:
google/go-tpm#235

Signed-off-by: Joe Richey <joerichey@google.com>
jessieqliu pushed a commit to google/go-tpm-tools that referenced this pull request Mar 2, 2022
PolicySecret now returns three values (google/go-tpm#237)

We never read the encoded value from Certify, so we are not affected by:
google/go-tpm#235

Signed-off-by: Joe Richey <joerichey@google.com>
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

Successfully merging this pull request may close these issues.

Certify, CertifyEx, and CertifyCreation return partial signature data
6 participants