On 2023/8/19 7:17, Mimi Zohar wrote: > On Fri, 2023-08-18 at 09:25 +0800, Guozihua (Scott) wrote: >> On 2023/8/17 22:19, Mimi Zohar wrote: >>> On Thu, 2023-08-17 at 14:13 +0800, GUO Zihua wrote: > [...] > >>> Other proposals have changed the hard coded hash algorithm and PCR >>> value from SHA1 to SHA256. Both that proposal and this will break >>> existing userspace applications. >> >> This is the part I would like to "RFC" on, and thanks for the comment! > > Another proposal included all of the enabled TPM bank digests. > >> In deed this change should break userspace as well as all the existing >> remote attestation implementation. It should be better to have a brand >> new file for this. > > True SHA1 is being phased out due to hash collisions. Verifying the > template data hash against the template data isn't necessary for the > attestation server to verify a TPM quote against any of the enabled TPM > banks. The attestation server walks the measurement list calculating > the bank specific template data hash. Breaking existing applications > is unreasonable. I get what you mean. Attestation could still extract result of the other PCR and do the verification ignoring the SHA1 hash in the measurement list. > >>> >>> Before we can introduce this sort of change, we would need to introduce >>> an IMA measurement list version. Perhaps its time to define an IMA >>> security critical-dbata record, which would include this and other >>> information. The measurement list itself would need to include a >>> version number. >>> >> I guess one of the easy way to do it is to make a >> ascii_runtime_measurements_ng and binary_runtime_measurements_ng, which >> contains a changed template supporting configurable template hash. What >> do you think? > > Defining additional pseudo filesystems would allow both the old and new > measurement list formats to be enabled at the same time. > Something like an IMAfs? Or maybe showing different format based on flags when file is opened. -- Best GUO Zihua
