Re: [Rats] 3 Use cases

["Panwei (William)" <[e-mail]>]

Hi Ian,

Thanks, please see inline.

Regards & Thanks!
潘伟 Wei Pan
华为技术有限公司 Huawei Technologies Co., Ltd.

From: RATS [mailto:[e-mail]] On Behalf Of Oliver, Ian (Nokia - FI/Espoo)
Sent: Monday, July 15, 2019 4:57 PM
To: [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.

[Wei] I have the same feeling with Thomas. The OEM is the Asserter in the RATS architecture, it can publish the Attestation Assertions to the Verifier (And this is out of scope of RATS). What makes this a different use case?

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.

[Wei] Sorry, I didn’t get this very clearly, can you elaborate this? I’m confused about what’s the use of this combined measurement.

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..

[Wei] This is interesting. It looks like that sending the attestation claims and the data together to attest the device and the data simultaneously. I think the claims discussed in the WG so far are not very simple (many informations need to be conveyed to show the device’s integrity), is this use case a operational one?


--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

[phone]