Forwarded with permission.
--- Begin Message ---Let me answer this in two emails, because I want to make sure that we are on the same page before continuing. I also want to note that some of these remarks are specific to how BRSKI uses audit-vouchers.There are other uses of vouchers (including NETCONF), and some of them do not need audit-vouchers or would accept audit-vouchers. Eric Rescorla <[email protected]> wrote: draft> Audit Voucher: An Audit Voucher is named after the logging draft> assertion mechanisms that the Registrar then "audits" to enforce draft> local policy. The Registrar mitigates a MiTM Registrar by auditing draft> that an unknown MiTM registrar does not appear in the log draft> entries. This does not directly prevent the MiTM but provides a draft> response mechanism that ensures the MiTM is unsuccessful. This draft> advantage is that actual ownership knowledge is not required on draft> the MASA service. > Can you walk me through the attack in question and how > auditing/logging > detects it, because I'm really not following from this document. > I'm > sure I'll have more questions later but I think I need to > understand > this one first. You will recall the light-bulb attack you postulated at the 2012 IoT Security Workshop. The threat was that an attacker that could control millions of smart light bulbs, would be able to turn them all on and off at the same time, causing stress and possibly damage to the electrical grid. The postulated situation was that attacker wanders through DIY store (Home Depot, etc.) or better yet, works there. They remove light bulbs from packages (carefully), go through the official imprint situation and then as the official owner, replace the firmware with one that they have control over, and then they "factory" reset the device (and put it back in the package) such that the end purchaser is unaware that the firmware is trojan'ed. For the purposes of this discussion, let's assume that the IDevID certificate and private key is secure in a tamper-proof TPM. I'll stop here because I want to make sure that we agree on the attack. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
--- End Message ---
-- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
