Re: [Rats] 3 Use cases

[Thomas Fossati <[e-mail]>]

HI Oliver,

Thanks.  A few comments inline.

Cheers, t

From: RATS <[e-mail]> on behalf of "Oliver, Ian (Nokia - FI/Espoo)" <[e-mail]>
Date: Monday, 15 July 2019 at 09:57
To: "[e-mail]" <[e-mail]>
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

[phone]

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.