Re: [Rats] watchdog use case ... RE: Use cases in draft-ietf-rats-architecture-04

[Michael Richardson <[e-mail]>]

Hannes Tschofenig <[e-mail]> wrote:
    > Could the authors of the use case explain the watchdog use case a bit
    > more?

Sure.
Dave's reference to the TCG "Authenticated Countdown Timer" is rather
detailed, but perhaps misses the forest for the trees.
Perhaps I can be a bit more concise.
Ian, please let us know if this describes your situation as well.

    > I do not understand how this is supposed to work. How is the device
    > allowed to reboot when it sends attestation information to a remote
    > server?

There are usual three parties: Attester, Verifier, Relying Party.

The Attester (secure enclave/TPM/etc.) collects Evidence as to health and
sends this to a remote Verifier.

The Verify creates an Attestation Result as normal.

But, in the case, the Relying Party is the Watch Dog timer in the TPM/secure
enclave itself.  So the Attestation Results are returned to the PC, and
provided to the enclave.

If the watch dog does not receive regular, and fresh, Attestation Results as
to the systems' health, then it forces a reboot.

    > If malware prevents the device from rebooting, as the text indicates,
    > why doesn't that malware also prevent the interaction with the
    > attestation server (for example, pretending that network connectivity
    > is down)?

The arrangement is that of a deadman's switch: if the malware were to prevent
the communication, then the watch dog would go off.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-