1. 4
  1.  

  2. 1

    This design let’s me safely use my device on an untrustes system. The system can’t reprogram my device to compromise a secondary host system.

    The spec doesn’t have a way for the device to authenticate itself to me. The attacker will physically swap the device when I’m not monitoring it. Next time I use it, gg.

    1. 1

      The system can’t reprogram my device to compromise a secondary host system.

      I haven’t read the publications yet. When I see this, I just always ask if you saw any protections from timing channels, analog attacks, or RF attacks (active/passive) in the work. If you saw all that, what you say is possibly true with a chance someone defeated it since those are cat and mouse games. If you didn’t, then you can have no confidence in what you say since it’s not just TLA’s focusing on that stuff these days. Regular researchers are doing it in public with others trying to emulate their results.

      If it involves safe languages, add source-to-object code verification to ensure the compiler didn’t screw something up. If multiple languages and/or assembly, ensure there isn’t an attack across abstraction gaps between languages. If software and hardware together, ensure there isn’t an abstraction attack between software and hardware. Then, there’s always cosmic rays, RAM errors, and noise that can throw off tiny parts of the digital illusion.

      Might still take effort, though, if they have to resort to any of that. Just a few things to keep in mind when evaluating these security techs designed for stronger mitigations.

      1. 1

        What you say is true, but to be fair, in security there is rarely an absolute answer to an attack threat (as you said, it is a cat and mouse game). A wookey stick will have several protection in place to prevent rogue host systems to flash a malicious firmware, but this only will work against a certain level of attackers.

        1. 2

          The project’s competition include IC’s from companies like Gemalto designed to resist some physical attacks with formal methods used on some components. They’re sold dirt cheap in volume, too. The black hats in this field stay hitting the devices with physical attacks. They publish their findings for others to copy. Addressing hardware/software security is the status quo.

          That’s why I bring it up. People not worried about attacks on the device itself, but who don’t trust the host, can ignore that to focus on whatever benefits they get. People who are blocking lots of attacks on device and host might want to go with something based on a tamper-resistant IC. Different folks have different requirements.