-
Notifications
You must be signed in to change notification settings - Fork 34
Title: Scheme/parsec-tpm: Add TPM vendor and model information #345
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
base: main
Are you sure you want to change the base?
Title: Scheme/parsec-tpm: Add TPM vendor and model information #345
Conversation
scheme/parsec-tpm/README.md
Outdated
| "key": [{ | ||
| "type": "pkix-base64-key", | ||
| "value": "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAETKRFE_RwSXooI8DdatPOYg_uiKm2XrtT_uEMEvqQZrwJHHcfw0c3WVzGoqL3Y_Q6xkHFfdUVqS2WWkPdKO03uw==", | ||
| "parameters": { |
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.
I don't believe CoRIM crypto keys have additional parameters. Is this some extension or proposed change to the spec?
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.
Hi sir @setrofim You're absolutely right to question this - CoRIM crypto keys in the standard specification do not have additional parameters.
This is indeed a Veraison-specific extension to the CoRIM spec. The standard IETF CoRIM specification defines crypto keys with only type and value fields.
I've implemented this extension because:
TPM-specific needs: TPM vendor/model information doesn't map naturally to the standard environment.class structure used by other schemes (like PSA)
Parsec profile: This follows the custom Parsec TPM profile ("tag:github.com/parallaxsecond,2023-03-03:tpm") which allows for scheme-specific extensions
Optional & backward compatible: Existing CoRIMs continue to work - this only adds optional metadata
I've updated the documentation to clearly indicate this is a Veraison extension and not part of the standard CoRIM specification. The implementation validates against our specific profile rather than claiming standard compliance.
Should I consider an alternative approach that stays closer to standard CoRIM, or is this extension acceptable for the parsec-tpm scheme's specific requirements? Pls reply
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.
crypto-key-type-choice offers "type choice" rather than "map" extension point. Meaning you cannot add fields to existing values, you can only add new types. So you cannot add parameters to, e.g., "pkix-base64-key", you'd need to define a whole new type, "pkix-base64-key-with-params" and register that as an extension to the type choice (and then do the same for every other variant that needs to be extended in this way).
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.
Thanks for guiding sir @setrofim, understood
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.
Ready for review sir
67d95ec to
7949f54
Compare
|
Ready for review sir @setrofim sir @yogeshbdeshpande sir @thomas-fossati |
setrofim
left a comment
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.
LGTM
yogeshbdeshpande
left a comment
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.
Please check my comments!
scheme/parsec-tpm/sanitize.go
Outdated
| @@ -0,0 +1,213 @@ | |||
| // Copyright 2024 Contributors to the Veraison project. | |||
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.
I am wondering this generic implementation of string validation and checking for specific patterns is applicable more generically across entire Services scheme and could be moved to services/common ??
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.
I don't think this validation is particularly generic. For example, dangerousChars set does not include some punctuation that one may want to escape in other contexts (e.g. @, -, =, +, etc). Some checks (hasExcessiveRepitition, 'hasAbnormalDistribution`) use seemingly arbitrary thresholds. This all seems reasonable for Parsec/TPM (at least, for the prespective of someone not intimately familiar with the specs). However, if we want something generic, this is inadequate.
I'm not even sure we want generic santization -- different systems have different restriction on what they accept and what needs to be escaped (e.g. URL vs DB input vs environment/shell variables). It is better to do specific filtering/escaping at the point where it is relevant. Otherwise we just end up with iflters that are overly restrictive or result in excessive escaping.
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.
ok, understood, thanks. Are these then coming from a spec reference for restriction in TPM specific scene setting?
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.
Not that I'm aware of (as I've said -- I'm not familiar with the specs). But this looks like it's designed specifically to catch "unreasonable" vendor/model names. From that point of view, the implementation looks reasonable. But I would not accept this as a good generic santizer (not do I think it's necesarily a good idea to have one).
|
@Sukuna0007Abhi Let us discuss this PR in Veraison Meeting on 07/10/2025 |
|
Sure sir, @yogeshbdeshpande will try my best, to explain properly 🙏 |
| Both fields support: | ||
| - Unicode characters (e.g., for international vendor names) | ||
| - Special characters (allowed in both fields) | ||
| - Variable length strings (no artificial length restrictions) |
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.
| Both fields support: | |
| - Unicode characters (e.g., for international vendor names) | |
| - Special characters (allowed in both fields) | |
| - Variable length strings (no artificial length restrictions) | |
| Both fields support: | |
| - Unicode characters (e.g., for international vendor names) | |
| - Special characters (allowed in both fields) | |
| - Variable length strings (no artificial length restrictions) |
scheme/parsec-tpm/README.md
Outdated
|
|
||
| ### CORIM Example | ||
|
|
||
| To include vendor and model information in your CORIM manifest, add them to the `environment.class` section (following standard CoRIM specification). Here are several examples: |
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.
| To include vendor and model information in your CORIM manifest, add them to the `environment.class` section (following standard CoRIM specification). Here are several examples: | |
| To include vendor and model information in your CoRIM manifest, add them to the `environment.class` section (following standard CoRIM specification). Here are several examples: |
scheme/parsec-tpm/README.md
Outdated
| ] | ||
| } | ||
| ``` | ||
|
|
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.
I do not think we need additional example, just drop them
scheme/parsec-tpm/README.md
Outdated
| ### Security Considerations | ||
|
|
||
| When using vendor and model fields: | ||
|
|
||
| 1. **Input Validation**: | ||
| - Maximum length: 1024 characters | ||
| - Strings are trimmed of leading/trailing whitespace | ||
| - Basic sanitization is applied to prevent injection attacks | ||
| - Control characters are removed (except newline and tab) | ||
|
|
||
| 2. **Storage**: | ||
| - Fields are optional and won't affect TPM validation | ||
| - Unicode characters are preserved for international vendor names | ||
| - Dangerous characters are escaped to prevent injection | ||
|
|
||
| 3. **Best Practices**: | ||
| - Use consistent vendor/model identifiers | ||
| - Prefer official vendor names and model numbers | ||
| - Keep strings concise and meaningful | ||
| - Test with various character encodings if using international names | ||
|
|
||
| Note: The vendor and model fields are always optional and are meant for informational purposes only. The TPM's security validation is based solely on its cryptographic identity and measurements. | ||
| ``` | ||
| ``` |
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.
We do not need any special Security Considerations for Vendor and Model, so please drop this section!
scheme/parsec-tpm/corim_extractor.go
Outdated
| if env.Class.Vendor != nil { | ||
| vendor := string(*env.Class.Vendor) | ||
| // Trim and validate | ||
| vendor = sanitizeAndValidate(vendor) |
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.
Line 131 not needed!
scheme/parsec-tpm/corim_extractor.go
Outdated
| if env.Class.Model != nil { | ||
| model := string(*env.Class.Model) | ||
| // Trim and validate | ||
| model = sanitizeAndValidate(model) |
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.
Line 139 not needed!
scheme/parsec-tpm/corim_extractor.go
Outdated
| func (o *CorimExtractor) SetProfile(profile string) { | ||
| o.Profile = profile | ||
| } | ||
|
|
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.
Remove Lines 213 to 231
scheme/parsec-tpm/sanitize.go
Outdated
| @@ -0,0 +1,213 @@ | |||
| // Copyright 2025 Contributors to the Veraison project. | |||
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.
File can be deleted!
scheme/parsec-tpm/sanitize_test.go
Outdated
| @@ -0,0 +1,125 @@ | |||
| // Copyright 2025 Contributors to the Veraison project. | |||
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.
File can be deleted!
yogeshbdeshpande
left a comment
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.
See my all comments, please re-work on the PR!
| VerifKey *string `json:"parsec-tpm.ak-pub"` | ||
| ClassID *string `json:"parsec-tpm.class-id"` | ||
| InstID *string `json:"parsec-tpm.instance-id"` | ||
| // Optional vendor information for the TPM |
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.
It is not just the Trust Anchor but the supply chain for SwAttr (line 24) which also has class, needs the Optional Vendor and Model information
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.
Ok sir @yogeshbdeshpande
This change implements support for TPM vendor and model information in TPM endorsements (Issue veraison#139). The implementation includes: - Extended TaAttr structure with vendor and model fields - Input validation and sanitization for security - Comprehensive test coverage including: * Real-world TPM vendor/model combinations * International character handling * Security test cases * Edge cases and input validation - Updated documentation with new fields and security considerations Signed-off-by: Sukuna0007Abhi <[email protected]>
Following @setrofim's feedback that crypto-key-type-choice uses 'type choice' not 'map' extension point, refactored to comply with standard CoRIM specification. Changes: - REMOVED: key.Parameters approach (invalid per CoRIM spec) - ADDED: Extract vendor/model from environment.class (standard location) - Follows same pattern as PSA scheme - Fixed regex backreference issues in sanitization - Updated README with complete, valid CoRIM examples - Deleted ta_attrs.go and related test files (wrong approach) - All tests passing This addresses the review comment that we cannot add parameters to existing key types like 'pkix-base64-key'. Instead, vendor/model are now stored in the standard environment.class location. Resolves: CoRIM specification compliance issue Signed-off-by: Sukuna0007Abhi <[email protected]>
Signed-off-by: Sukuna0007Abhi <[email protected]> Co-authored-by: Yogesh Deshpande <[email protected]> Signed-off-by: Sukuna0007Abhi <[email protected]>
Signed-off-by: Sukuna0007Abhi <[email protected]> Co-authored-by: Yogesh Deshpande <[email protected]> Signed-off-by: Sukuna0007Abhi <[email protected]>
- Remove sanitization files (sanitize.go, sanitize_test.go) - Extract vendor/model directly without validation - Simplify README: keep one example, remove Security section - Add vendor/model support to SwAttr for supply chain Addresses feedback from sir @yogeshbdeshpande Signed-off-by: Sukuna0007Abhi <[email protected]>
b3c6251 to
2b059c7
Compare
|
Ready for review sir @yogeshbdeshpande |
Description:
This PR implements support for TPM vendor and model information in TPM endorsements, addressing Issue #139.
Changes include:
Security Considerations:
Testing:
Documentation:
Resolves: #139
Ready for Review sir @thomas-fossati @setrofim @yogeshbdeshpande