Add speaker notes & clean up HTML
This commit is contained in:
parent
3d667b8d79
commit
c6bfaf69b3
154
index.html
154
index.html
@ -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 $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">
|
||||
@ -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}!`
|
||||
```
|
||||
---
|
||||
## 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…
Reference in New Issue
Block a user