From the point of view of the Bitcoin white paper, trusted platform modules, programmable secure elements, and secure enclaves are all examples of the presence of trusted third parties. They are “Treacherous Computing” hardware that someone other than you ultimately controls, and who you must trust to act in your best interests.
If it was the case that the use of hardware that obeys trusted thirds parties in order to improve the security or speed of cryptocurrencies offered obvious benefits that cannot be achieved in any other way then objecting to this on ideological grounds might seem like an example of Emerson’s maxim that “a foolish consistency is the hobgoblin of little minds”. But trusted third party hardware is not necessarily always more secure and trustworthy than hardware or software that the user controls.
Promoting trusted third party hardware solutions in cryptocurrency without acknowledging this should therefore be questioned both ideologically and pragmatically.
Ideologically because the CEO of a hardware wallet company should not have more control of the systems that you use to hold your cryptocurrency than you do, and they should not be beholden to their chip vendor for that power either.
Pragmatically because adding more places for malware to infect and hide in, and in ways that may be impossible to detect and remove, does not make things more secure.
Given all this it is important to look beyond the marketing of trusted third party hardware. Here are some articles describing issues with such systems.
Government agencies do pressure chip producers to include backdoors to their products, so why should one suppose it would be different with SE, especially knowing that these are being used for financial transactions? The user would never learn about this, because of the nature of the SE.
A team of security engineers from Rapid7 at Black Hat USA 2016 conference in Las Vegas demonstrated how a small and simple modifications to equipment would be enough for attackers to bypass the Chip-and-PIN protections and enable unauthorized transactions.
The Infineon Bug
A crippling flaw in a widely used code library has fatally undermined the security of millions of encryption keys used in some of the highest-stakes settings, including national identity cards, software- and application-signing, and trusted platform modules protecting government and corporate computers.
A vulnerability was identified in the RSA key generation method used by Trusted Platform Modules (TPMs) manufactured by Infineon and contained in some Lenovo products. RSA public keys generated by the Infineon TPM for use by certain software programs should be considered insecure.
Of course, if Infineon made this mistake, who else could have made a similar faux pas?
Researchers have demonstrated using Intel’s Software Guard Extensions to hide malware and steal cryptographic keys from inside SGX’s protected enclave
It’s still too early to know what the full fallout from the SEP’s decryption will be, but it could open the door for password harvesting, spoofing, and other security-compromising attacks.