|
|
<!doctype html>
|
|
|
<html lang="en">
|
|
|
<head>
|
|
|
<title>Review of Petzi et al. 2022</title>
|
|
|
<link rel="stylesheet" href="node_modules/reveal.js/dist/reveal.css">
|
|
|
<link rel="stylesheet" href="node_modules/reveal.js/dist/theme/night.css">
|
|
|
<link rel="stylesheet" href="node_modules/reveal.js/plugin/highlight/zenburn.css">
|
|
|
<link rel="stylesheet" href="node_modules/reveal.js-drawer/dist/drawer.css">
|
|
|
<link rel="stylesheet" href="lib/attribution/plugin.css">
|
|
|
</head>
|
|
|
<body>
|
|
|
<div class="reveal">
|
|
|
<div class="slides">
|
|
|
<section style="text-align: left">
|
|
|
<b>SCRAPS</b>:<br><b>S</b>calable <b>C</b>ollective <b>R</b>emote <b>A</b>ttestation for <b>P</b>ub-<b>S</b>ub IoT Networks with Untrusted Proxy Verifier
|
|
|
<br><br>
|
|
|
<small><i>Petzi et al.</i> 2022 (31st USENIX Security Symposium, pp. 3484-3501)</small>
|
|
|
<br><small>Summary: Garrett Mills <glm@ku.edu><br>
|
|
|
<i style="color: #888">https://garrettmills.dev/go/scraps</i></small>
|
|
|
</section>
|
|
|
<section>
|
|
|
<b>Attestation</b> <i>(noun)</i> - the activity of making a claim to an appraiser about the properties of a target by supplying evidence which
|
|
|
supports that claim. <small><i>[1]</i></small>
|
|
|
|
|
|
<aside class="notes">
|
|
|
Used in large systems to establish trust between components<br>
|
|
|
The requester trusts the appraiser to "attest to" the target
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section>
|
|
|
<b>Smart Contracts</b> <i>(noun)</i> - scripts stored on the blockchain. The contracts have their own state, and are triggered by messages/transactions
|
|
|
sent to their respective addresses. <small><i>[2]</i></small>
|
|
|
|
|
|
<aside class="notes">
|
|
|
For our purposes: can be immutable and publicly verified as trustworthy
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section>
|
|
|
<b>Challenges adapting RA to IoT:</b><br><br>
|
|
|
|
|
|
<ol>
|
|
|
<li>IoT relies on asynchronous channels</li>
|
|
|
<li>IoT devices may go offline to save power</li>
|
|
|
<li>IoT networks use untrusted brokers</li>
|
|
|
</ol>
|
|
|
|
|
|
<aside class="notes">
|
|
|
Most traditional RA requires synchronous, direct, and always-on connections between elements in the system
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section>
|
|
|
<b>SCRAPS</b><br><br>
|
|
|
<ul>
|
|
|
<li>Manufacturer's SC (config)</li>
|
|
|
<li>ProxyVerifier SC (appraiser)</li>
|
|
|
<li>Prover (target)</li>
|
|
|
<li>Verifier (requester)</li>
|
|
|
</ul>
|
|
|
</section>
|
|
|
<section data-transition="none" style="text-align: left">
|
|
|
<ol style="font-size: 0.75em;">
|
|
|
<li><b>Prover registers with Broker</b></li>
|
|
|
<li>Prover computes measurement using chain hash</li>
|
|
|
<li>ProxyVerifier appraises evidence using config & freshness</li>
|
|
|
<li>Verifier requests appraisal from ProxyVerifier</li>
|
|
|
</ol>
|
|
|
|
|
|
<aside class="notes">
|
|
|
Broker is the message passing system used by the IoT network, like MQTT
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section data-transition="none" style="text-align: left">
|
|
|
<ol style="font-size: 0.75em;">
|
|
|
<li>Prover registers with Broker</li>
|
|
|
<li><b>Prover computes measurement using chain hash</b></li>
|
|
|
<li>ProxyVerifier appraises evidence using config & freshness</li>
|
|
|
<li>Verifier requests appraisal from ProxyVerifier</li>
|
|
|
</ol>
|
|
|
|
|
|
<aside class="notes">
|
|
|
In traditional RA, a unique nonce guarantees freshness. In SCRAPS,
|
|
|
the current block hash of the chain is used as the nonce instead.
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section data-transition="none" style="text-align: left">
|
|
|
<ol style="font-size: 0.75em;">
|
|
|
<li>Prover registers with Broker</li>
|
|
|
<li>Prover computes measurement using chain hash</li>
|
|
|
<li><b>ProxyVerifier appraises evidence using config & freshness</b></li>
|
|
|
<li>Verifier requests appraisal from ProxyVerifier</li>
|
|
|
</ol>
|
|
|
|
|
|
<aside class="notes">
|
|
|
<ol>
|
|
|
<li>PV uses the MFR SC's address from the evidence to look up configuration</li>
|
|
|
<li>PV uses $T_{min}$ and $T_{exp}$ from config to determine freshness</li>
|
|
|
<li>If fresh, PV appraises the evidence to determine if it is acceptable</li>
|
|
|
<li>If so, the Prover is marked as trusted as of the current block hash</li>
|
|
|
</ol>
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section data-transition="none" style="text-align: left">
|
|
|
<ol style="font-size: 0.75em;">
|
|
|
<li>Prover registers with Broker</li>
|
|
|
<li>Prover computes measurement using chain hash</li>
|
|
|
<li>ProxyVerifier appraises evidence using config & freshness</li>
|
|
|
<li><b>Verifier requests appraisal from ProxyVerifier</b></li>
|
|
|
</ol>
|
|
|
|
|
|
<aside class="notes">
|
|
|
As long as the appraisal is fresh ($T_{max}$), the PV attests to the Prover<br>
|
|
|
Stale or invalid evidence marks the Prover as requiring new evidence
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section>
|
|
|
<img src="img/fig-6.png" alt="Figure 6" style="filter: invert(100%);">
|
|
|
|
|
|
<aside class="notes">
|
|
|
LegIoT: current state-of-the-art IoT RA system based on transitive trust relations<br>
|
|
|
Hit percentage: the system's ability to effectively re-use cached attestations<br>
|
|
|
Here, SCRAPS is much more efficient at caching for large networks
|
|
|
</aside>
|
|
|
</section>
|
|
|
<section>
|
|
|
<img src="img/fig-8.png" alt="Figure 8" style="filter: invert(100%);">
|
|
|
|
|
|
<aside class="notes">
|
|
|
Query %: the total number of attestation queries able to be processed by the system<br>
|
|
|
Again, SCRAPS scales better than LegIoT in large networks
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section data-background-image="img/live-laugh-learn.jpg">
|
|
|
<div style="background: rgba(0, 0, 0, 0.4)">
|
|
|
<h3>Smart Contracts</h3>
|
|
|
</div>
|
|
|
|
|
|
<aside class="notes">
|
|
|
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.<br><br>
|
|
|
2. One of the first legitimate/interesting use cases for SC's.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section>
|
|
|
<b>Stength:</b> Problem/architecture formulation
|
|
|
|
|
|
<aside class="notes">
|
|
|
Identified a broad set of concerns/complications w/ IoT networks & RA
|
|
|
<br><br>Architecture of SCRAPS solves these problems neatly (prover-driven attestation, cached appraisals, &c.)
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section>
|
|
|
<b>Strength:</b> Performance
|
|
|
</section>
|
|
|
|
|
|
<section>
|
|
|
<b>Strength:</b> Appraiser is as secure as the chain
|
|
|
|
|
|
<aside class="notes">
|
|
|
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.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Strength:</b> Use of blockchain eliminates some attacks
|
|
|
|
|
|
<aside class="notes">
|
|
|
DoS (responses from the chain, not the devices)
|
|
|
<br><br>Replay attacks (signed w/ the hash nonce, so can't be forged in the future)
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Weakness:</b> Interaction between freshness and sleep
|
|
|
|
|
|
<aside class="notes">
|
|
|
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.
|
|
|
<br><br>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.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Weakness:</b> Limited appraisal & trust flexibility
|
|
|
|
|
|
<aside class="notes">
|
|
|
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.
|
|
|
<br><br>
|
|
|
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.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Weakness:</b> Determination of $T_{min}$ and $T_{exp}$
|
|
|
|
|
|
<aside class="notes">
|
|
|
Broader note, it's unclear how you would determine these values meaningfully
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Weakness:</b> Depends on manufacturer's pub-key to verify
|
|
|
|
|
|
<aside class="notes">
|
|
|
The device configurations and the trust anchors on the provers themselves are all trusted based
|
|
|
on their relation to the manufacturer's private key.
|
|
|
<br><br>
|
|
|
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.
|
|
|
<br><br>
|
|
|
However, without this, there's nothing stopping a prover from sending the address of a fabricated
|
|
|
manufacturer's SC.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Weakness:</b> Evidence & appraisal privacy
|
|
|
|
|
|
<aside class="notes">
|
|
|
This system requires targets to accept that their evidence will be exposed to the chain directly.
|
|
|
<br><br>
|
|
|
It also makes public the requirements used to determine whether evidence is acceptable, which may
|
|
|
make it easier to game the system.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Future work:</b> Formal verification of ProxyVerifier
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Future work:</b> SC-based flexible mechanisms
|
|
|
|
|
|
<aside class="notes">
|
|
|
The authors note that IoT devices are heterogeneous, but SCRAPS assumes only one type of evidence
|
|
|
and appraisal.
|
|
|
<br><br>
|
|
|
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.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section style="font-size: 0.9em">
|
|
|
<b>Future work:</b> SC-based flexible mechanisms <i>(reprise)</i>
|
|
|
|
|
|
<aside class="notes">
|
|
|
The appraisal could be made even more flexible by allowing Verifiers to register addresses of their
|
|
|
own SC's when they request attestation.
|
|
|
<br><br>
|
|
|
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.
|
|
|
<br><br>
|
|
|
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.
|
|
|
</aside>
|
|
|
</section>
|
|
|
|
|
|
<section>
|
|
|
<b>References</b>
|
|
|
<br>
|
|
|
<br>
|
|
|
<div style="text-align: left; font-size: 0.5em;">
|
|
|
<p>[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.</p>
|
|
|
<p>[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.</p>
|
|
|
<p>[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.</p>
|
|
|
<p>[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.</p>
|
|
|
</div>
|
|
|
</section>
|
|
|
</div>
|
|
|
</div>
|
|
|
<script src="node_modules/reveal.js/dist/reveal.js"></script>
|
|
|
<script src="node_modules/reveal.js/plugin/markdown/markdown.js"></script>
|
|
|
<script src="node_modules/reveal.js/plugin/highlight/highlight.js"></script>
|
|
|
<script src="node_modules/reveal.js/plugin/math/math.js"></script>
|
|
|
<script src="node_modules/reveal.js/plugin/notes/notes.js"></script>
|
|
|
<script src="node_modules/reveal.js/plugin/search/search.js"></script>
|
|
|
<script src="node_modules/reveal.js-drawer/dist/drawer.js"></script>
|
|
|
<script src="lib/attribution/plugin.js"></script>
|
|
|
<script>
|
|
|
Reveal.initialize({
|
|
|
plugins: [
|
|
|
RevealMarkdown,
|
|
|
RevealHighlight,
|
|
|
RevealMath.KaTeX,
|
|
|
RevealNotes,
|
|
|
RevealSearch,
|
|
|
RevealDrawer,
|
|
|
RevealAttribution,
|
|
|
],
|
|
|
progress: false,
|
|
|
hash: true,
|
|
|
hideCursorTime: 2000,
|
|
|
});
|
|
|
</script>
|
|
|
</body>
|
|
|
</html>
|
