On 12/6/2017 4:13 AM, Roberto Sassu wrote:
I think this is not suitable for scenarios where unknown Requestors are
attested.
Could you explain. The relying party can either accept the unknown
requester or reject it. What's the issue?
https://trustedcomputinggroup.org/wp-content/uploads/IWG_Architecture_v1_0_r1.pdf
(Section 4)
- if it's the first quote after a reboot, send the entire log, else
- if PCRs haven't changed, don't send anything, else
- send a delta since the last attestation.
Even without this obvious optimization, the transmit time is
negligible compared to the quote signature generation time.
Having large measurement lists introduces additional issues:
1) overhead to generate/parse the TCG Integrity Report
(Requestor/Verifier)
1 - When I profiled my code, the TPM quote signing was nearly all the
time. For the first quote, verifying the IMA signatures at the relying
party was also measurable.
Everything else - parsing at the requester and relying party, transmit
time, even reconstructing the PCRs from the event log, was insignificant.
General principle: Whenever there's an asymmetric key operation, it's
likely that nothing else affects performance.
2) storage requirement (Verifier)
3) overhead to build the complete Integrity Report from base + delta if
the verification tool is not stateful (Verifier)
2 - I assume that the verifier will have a disk. With our logs running
1-10 mbytes, a generic 2017 disk can handle 100,000's of requesters.
3 - All implementations I know of use some database for the verifier.
It already has to hold public keys, error reports, etc. Adding one more
integer - the number of events in the last report - isn't hard.
I have open source sample code that does all this already.
