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

[Hannes Tschofenig <[e-mail]>]

Hi Michael,

thanks for the reference to the TCG "Authenticated Countdown Timer" spec. I have not seen that spec before.

It says:

"
A typical example for the use of an ACT is as a watchdog timer that will cause a platform reset when the timer reaches
zero (expires). In a system using an ACT, a periodic platform action outside the TPM indicates that the timeout should
be set anew using TPM2_ACT_SetTimeout(). The most common reason why timeout is not set anew is that the local
system is not behaving properly because of some type of corruption (either inadvertent or malicious). The intent of
the timer is that, in the absence of a properly authorized timeout extension, the platform would be reset, putting it back
into a known state with the expectation that the corruption can be removed.
"

Thanks for the description of a possible message flow. This makes much more sense to me now.

In fact, we have the building blocks to get this working already when you combine the EAT token (for the attestation), the CWT for authorization (as mentioned in the TPM spec above), and SUIT (for the update of the software that is needed to fix the system). When we look at TEEP then we actually see these building blocks combined to get this use case working via a standardized protocol.

Now I am excited about this and maybe someone in the RATS/TEEP group wants to prototype it.

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[e-mail]>
Sent: Tuesday, June 16, 2020 10:20 PM
To: Hannes Tschofenig <[e-mail]>
Cc: Oliver, Ian (Nokia - FI/Espoo) <[e-mail]>; [e-mail]
Subject: Re: watchdog use case ... RE: [Rats] Use cases in draft-ietf-rats-architecture-04


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 =-
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.