You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The method used for generating the field offsets in the cert parameters is to populate the field with a known value when generating the tbs, then to search for that value after generation. This should be reasonably robust for larger fields, but is very fragile for fields that are a single byte.
As an example, an issue was hit when a change in the FMC alias cert caused a length to be 197 (0xc5) which happened to be the value used for the SVN fuse value used when generating the cert. This caused the SVN fuse value offset to be incorrect and overwrite the length value. https://github.com/chipsalliance/caliptra-sw/blob/main/x509/build/cert.rs#L95
As a small improvement to make this easier to catch, I will be adding a check to confirm the value truly is unique in the TBS.
Overall, a more robust method is likely needed here. Either by including other known data around the unique value (such as length encodings and identifiers). Or, better yet, by actually parsing the cert for specific fields.
The text was updated successfully, but these errors were encountered:
The method used for generating the field offsets in the cert parameters is to populate the field with a known value when generating the tbs, then to search for that value after generation. This should be reasonably robust for larger fields, but is very fragile for fields that are a single byte.
As an example, an issue was hit when a change in the FMC alias cert caused a length to be 197 (0xc5) which happened to be the value used for the SVN fuse value used when generating the cert. This caused the SVN fuse value offset to be incorrect and overwrite the length value. https://github.com/chipsalliance/caliptra-sw/blob/main/x509/build/cert.rs#L95
As a small improvement to make this easier to catch, I will be adding a check to confirm the value truly is unique in the TBS.
Overall, a more robust method is likely needed here. Either by including other known data around the unique value (such as length encodings and identifiers). Or, better yet, by actually parsing the cert for specific fields.
The text was updated successfully, but these errors were encountered: