1. 4

  2. 8

    Here are the properties in the PDF. They heavily assume centralized control, and I note that ‘ability to audit the source code’ is not mentioned. Well, they would, wouldn’t they?

    Hardware-based Root of Trust:

    • Unforgeable cryptographic keys generated and protected by hardware. Physical countermeasures resist side-channel attacks.
    • Does the device have a unique, unforgeable identity that is inseparable from the hardware?

    Small Trusted Computing Base

    • Private keys stored in a hardware-protected vault, inaccessible to software. Division of software into self-protecting layers.
    • Is most of the device’s software outside the device’s trusted computing base?

    Defense in Depth

    • Multiple mitigations applied against each threat. Countermeasures mitigate the consequences of a successful attack on any one vector.
    • Is the device still protected if the security of one layer of device software is breached?


    • Hardware-enforced barriers between software components prevent a breach in one from propagating to others.
    • Does a failure in one component of the device require a reboot of the entire device to return to operation?

    Certificate-based Authentication

    • Signed certificate, proven by unforgeable cryptographic key, proves the device identity and authenticity.
    • Does the device use certificates instead of passwords for authentication?

    Renewable Security

    • Renewal brings the device forward to a secure state and revokes compromised assets for known vulnerabilities or security breaches.
    • Is the device’s software updated automatically?

    Failure Reporting

    • A software failure, such as a buffer overrun induced by an attacker probing security, is reported to cloud-based failure analysis system.
    • Does the device report failures to its manufacturer?
    1. 4

      and I note that ‘ability to audit the source code’ is not mentioned. Well, they would, wouldn’t they?

      Hard to tell if it’s an accidental omission due to them focusing on features or attributes of the product that directly relate to security. Even if I think of that, the ability to review code has contributed to more flaws found. So, maybe just because they work for a vendor of closed-source software.

      1. 3

        Yes, in the gray light of morning it dawns on me that everything I had my doubts about relates to trust, not security.

        For example, the auto-updating and centralized reporting seemed dubious to me because I don’t know if I can trust device manufactures not to compromise devices on governments’ behalves; but for for a highly secure device, you’d want someone centralised auditing anomalies and patching vulnerabilities, right?

        (As is probably obvious, I am no security expert.)

        1. 2

          Most of the attacks come from people other than host government or manufacturers. So, patches from manufacturers already reduces risk of that. Then, there’s downtime risk where latches break stuff which is mitigated by testing them. Finally, there is risk of malicious manufacturer that’s mitigated by viewing design and source before and during a change.