Add speaker notes & clean up HTML

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