# Review of Petzi et al. 2022

SCRAPS:
Scalable Collective Remote Attestation for Pub-Sub IoT Networks with Untrusted Proxy Verifier
Petzi et al. 2022 (31st USENIX Security Symposium, pp. 3484-3501)
Summary: Garrett Mills <glm@ku.edu>
https://garrettmills.dev/go/scraps
Attestation (noun) - the activity of making a claim to an appraiser about the properties of a target by supplying evidence which supports that claim. [1]
Used in large systems to establish trust between components
The requester trusts the appraiser to "attest to" the target
Smart Contracts (noun) - scripts stored on the blockchain. The contracts have their own state, and are triggered by messages/transactions sent to their respective addresses. [2]
For our purposes: can be immutable and publicly verified as trustworthy
Challenges adapting RA to IoT:

1. IoT relies on asynchronous channels
2. IoT devices may go offline to save power
3. IoT networks use untrusted brokers

Most traditional RA requires synchronous, direct, and always-on connections between elements in the system
SCRAPS

- Manufacturer's SC (config)
- ProxyVerifier SC (appraiser)
- Prover (target)
- Verifier (requester)

1. Prover registers with Broker
2. Prover computes measurement using chain hash
3. ProxyVerifier appraises evidence using config & freshness
4. Verifier requests appraisal from ProxyVerifier

Broker is the message passing system used by the IoT network, like MQTT

1. Prover registers with Broker
2. Prover computes measurement using chain hash
3. ProxyVerifier appraises evidence using config & freshness
4. Verifier requests appraisal from ProxyVerifier

In traditional RA, a unique nonce guarantees freshness. In SCRAPS, the current block hash of the chain is used as the nonce instead.

1. Prover registers with Broker
2. Prover computes measurement using chain hash
3. ProxyVerifier appraises evidence using config & freshness
4. Verifier requests appraisal from ProxyVerifier

1. PV uses the MFR SC's address from the evidence to look up configuration
2. PV uses $T_{min}$ and $T_{exp}$ from config to determine freshness
3. If fresh, PV appraises the evidence to determine if it is acceptable
4. If so, the Prover is marked as trusted as of the current block hash

1. Prover registers with Broker
2. Prover computes measurement using chain hash
3. ProxyVerifier appraises evidence using config & freshness
4. Verifier requests appraisal from ProxyVerifier

As long as the appraisal is fresh ($T_{max}$), the PV attests to the Prover
Stale or invalid evidence marks the Prover as requiring new evidence
LegIoT: current state-of-the-art IoT RA system based on transitive trust relations
Hit percentage: the system's ability to effectively re-use cached attestations
Here, SCRAPS is much more efficient at caching for large networks
Query %: the total number of attestation queries able to be processed by the system
Again, SCRAPS scales better than LegIoT in large networks

### Smart Contracts

1. Had to learn what a smart contract could do, at a technical level. It was surprisingly difficult to wade through the cesspool of crypto propaganda.
2. One of the first legitimate/interesting use cases for SC's.
Stength: Problem/architecture formulation
Identified a broad set of concerns/complications w/ IoT networks & RA
Architecture of SCRAPS solves these problems neatly (prover-driven attestation, cached appraisals, &c.)
Strength: Performance
Strength: Appraiser is as secure as the chain
This is a double-edged sword, but because of the architecture of SC's, the integrity of the appraiser (PV) is as good as the integrity of the blockchain itself, presumably pretty good.
Strength: Use of blockchain eliminates some attacks
DoS (responses from the chain, not the devices)
Replay attacks (signed w/ the hash nonce, so can't be forged in the future)
Weakness: Interaction between freshness and sleep
Authors formulate $T_{min}$ as an amount of time in which an adversary cannot compromise a device, therefore measurements from that device can be trusted.
However, this really has nothing to do with the length of time the device sleeps. What happens when the compromise time is less than the supposed sleep time? This could result in provers becoming untrusted/pending due to sleep.
Weakness: Limited appraisal & trust flexibility
An important aspect of RA, imo, is the ability of the appraiser and the requester to determine whether certain evidence is sufficiently trustworthy based not just on the evidence, but also the needs of the requester.
e.g. Someone performing broad statistical analysis might be more lenient on freshness than a service waiting to execute IoT commands. However, because appraisal is done in the SC and evidence is never emitted, the appraisal and parameters must be sufficient for all requesters.
Weakness: Determination of $T_{min}$ and $T_{exp}$
Broader note, it's unclear how you would determine these values meaningfully
Weakness: Depends on manufacturer's pub-key to verify
The device configurations and the trust anchors on the provers themselves are all trusted based on their relation to the manufacturer's private key.
This means that, in order for the appraiser to make a valid judgement, it must be told to trust/ validate the mfr's key, which may limit flexibility in heterogenous IoT systems.
However, without this, there's nothing stopping a prover from sending the address of a fabricated manufacturer's SC.
Weakness: Evidence & appraisal privacy
This system requires targets to accept that their evidence will be exposed to the chain directly.
It also makes public the requirements used to determine whether evidence is acceptable, which may make it easier to game the system.
Future work: Formal verification of ProxyVerifier
Future work: SC-based flexible mechanisms
The authors note that IoT devices are heterogeneous, but SCRAPS assumes only one type of evidence and appraisal.
This could be extended to support a broader array of evidence and appraisal by allowing the manufacturer's SC to specify a mapping from device model to SC which contains an evidence-type specific appraisal-code.
Future work: SC-based flexible mechanisms (reprise)
The appraisal could be made even more flexible by allowing Verifiers to register addresses of their own SC's when they request attestation.
Then, the ProxyValidator sends its appraisal and some add'l metadata like freshness as input to each Verifier's SC, which all determine trustworthiness according to their requirements.
We could even go further and allow the ProxyValidator to enforce privacy policies about appraisal, only sending evidence to Verifier SC's if those SC's obey certain rules.
References

[0] Petzi, Lukas, Ala Eddine Ben Yahya, Alexandra Dmitrienko, Gene Tsudik, Thomas Prantl, and Samuel Kounev. “SCRAPS: Scalable Collective Remote Attestation for Pub-Sub IoT Networks with Untrusted Proxy Verifier,” 2022, 18.

[1] Coker, George, Joshua Guttman, Peter Loscocco, Amy Herzog, Jonathan Millen, Brian O’Hanlon, John Ramsdell, Ariel Segall, Justin Sheehy, and Brian Sniffen. “Principles of Remote Attestation.” International Journal of Information Security 10, no. 2 (June 2011): 63–81. https://doi.org/10.1007/s10207-011-0124-7.

[2] Christidis, Konstantinos, and Michael Devetsikiotis. “Blockchains and Smart Contracts for the Internet of Things.” IEEE Access 4 (2016): 2292–2303. https://doi.org/10.1109/ACCESS.2016.2566339.

[3] Helble, Sarah C., Ian D. Kretz, Peter A. Loscocco, John D. Ramsdell, Paul D. Rowe, and Perry Alexander. “Flexible Mechanisms for Remote Attestation.” ACM Transactions on Privacy and Security 24, no. 4 (September 30, 2021): 29:1-29:23. https://doi.org/10.1145/3470535.