Subject: Re: [Rats] 3 Use cases

From: Thomas Fossati <[email-masked]>
Date: Mon, 15 Jul 2019 10:36:04 +0000

HI Oliver,

Thanks.  A few comments inline.

Cheers, t

From: RATS <[email-masked]> on behalf of "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Monday, 15 July 2019 at 09:57
To: "[email-masked]" <[email-masked]>
Subject: [Rats] 3 Use cases

Supply Chain Attestation

A device is shipped from an OEM via some delivery mechanism and is received by a customer. The customer requires assurance that the device has not been tampered with. This differs from the usual attestation scenarios between a device/element and attestation server/verifier in that this requires knowledge of the partial or full configuration of the device being shipped and configured before introduction into the customer's environment.

This use case then requires interaction between two attestation points to ensure that the integrity of the device has not changed with regards to a) the device, b) the original [possibly partial] configuration, c) the device manufacturer's measurements and d) the receiver - customer's - measurements.

It's not clear to me what you mean by “usual attestation scenarios” and therefore why this should be different from those.

I also don’t understand what are the “two attestation points” you mention?

ISTM that in the scenario that you are describing above the OEM has all the information regarding the installed software and its configuration upfront, i.e., before shipment.  If so, it can just communicate the expected values to the Verifier, and that’d close the loop.  (I think I might be missing something crucial?)

Dynamic Systems

All current integrity mechanism assume a certain degree of fixed properties, eg: TPM's CRTM/SRTM, and known configurations. A case exists where a set of, say, IoT devices each with integrity measurements are attested by some Edge node. The Edge node may combine the IoT device measurements into a single measurement (eg: Merkel Tree). If the configuration of IoT device changes, particuarly in relation to availability of device, then this combined measurement will change. This changed measurement however may be a valid configuration.

For example, in a medical case, the set of measurement devices may be rapidly changing due to necessity of network provisioning, device availabiltiy etc, but the permutations of devices may still be valid.

This looks similar to https://tools.ietf.org/html/draft-richardson-rats-usecases-04#section-5.1.3 except it spells out the “continuously changing topology” trait.

Do you envisage this needing something more than the application of a local policy for aggregating the measurements, or could it be treated similarly to the “Proxy RoT” use case (e.g., by defining a claim that specifies the used aggregation mechanism to the verifier)?

Data Attestation

A piece of data received from a trusted element may itself contain information about the configuration of that device when that data was received.. This might be a single measurement or a combination of measurements over time bounded by a session or transacition.

In this use case we continue the chain-of-trust up from the device firmware/operating environment to the data. This enables that once a data packet is received, it's integrity can be checked (cf: JWT) and this information also be traced to the device that produced that data. The data and device then can be attested together..

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

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.

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 23 Jul 2019 11:26:51 +0000

Resending.

Supply Chain Attestation

The use case we are looking at is how multiple attestation points can be utilised together. Particularly in the case of supply chain scenarios where an element (product, item, software, VM image etc) may pass through a number of configuration points. For example, in the case of firmware, some expected measures might be known by the firmware provider, but the OEM themselves can make additional configuration changes which build upon the former.

Dynamic Systems

> This looks similar to https://tools.ietf.org/html/draft-richardson-rats-usecases-04#section-5.1.3 except it spells out the “continuously > changing topology” trait.
>
> Do you envisage this needing something more than the application of a local policy for aggregating the measurements, or could it be > treated similarly to the “Proxy RoT” use case (e.g., by defining a claim that specifies the used aggregation mechanism to the verifier)?

I think this extends 5.1.3 in the way mentioned above.

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Thomas Fossati <[email-masked]>
Sent: 15 July 2019 13:36
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; [email-masked] <[email-masked]>
Cc: Thomas Fossati <[email-masked]>
Subject: Re: [Rats] 3 Use cases

HI Oliver,

Cheers, t

Supply Chain Attestation

Dynamic Systems

Data Attestation

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237