Add speaker notes & clean up HTML

master
Garrett Mills 1 year ago
parent 3d667b8d79
commit c6bfaf69b3

@ -21,10 +21,19 @@
<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>
@ -34,6 +43,10 @@
<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>
@ -51,6 +64,10 @@
<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;">
@ -59,6 +76,11 @@
<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;">
@ -67,6 +89,15 @@
<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;">
@ -75,22 +106,49 @@
<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>
@ -99,30 +157,80 @@
<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&nbsp;&nbsp;$T_{min}$ and&nbsp;&nbsp;$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">
@ -131,10 +239,30 @@
<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>
@ -148,32 +276,6 @@
<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>
<!--<section>Hello, World!</section>
<section>
Slide 2!
<span class="attribution">
Template courtesy of <a target="_blank" href="https://code.garrettmills.dev/garrettmills/slides">my template</a>.
</span>
</section>
<section data-markdown>
<textarea data-template>
## Slide 3
This is a markdown slide!
- note1
- note2
- note3
```js
const a = `Hello, ${name}!`
```
-&#45;&#45;
## Slide 4
This contains some katex.
`$$\cfrac{(v, c) \Downarrow v'}{(v, c) \rightarrow v'}$$`
</textarea>
</section>-->
</div>
</div>
<script src="node_modules/reveal.js/dist/reveal.js"></script>

Loading…
Cancel
Save