Secure Hardware and Blockchain Technologies Stanford Cyber Initiative January 2017 Nicolas Bacca

1. Secure Hardware and Blockchain Technologies Stanford Cyber Initiative January 2017 Nicolas Bacca @btchip

2. about:speaker Nicolas Bacca, Ledger CTO Ledger : Hardware Wallet manufacturer / Portable security solutions (Secure Elements, Enclaves, HSMs) Previously Oberthur Technologies, consulting on secure embedded solutions design Security analysis / embedded reverse engineering on the side

3. about:talk Comments from commercial, real world deployments of secure hardware Suggest some classification scheme for different architectures to achieve interesting properties regarding Blockchain applications (auditability, openness, ...) Pointers to dig further into somewhat obscure technologies Not : a sales pitch for a given technology Not : a demonstration that secure hardware should be dismissed immediately

4. Typical use cases for Secure Hardware Protect secrets against physical attacks Distribute hardware in a given, confirmed configuration with limited risks Protect secrets against software attacks Provide proof of code execution (attestation) in a given environment

5. Key elements from the different use cases Identify who / what to trust, depending on the scenario from the purchase/deployment to the actual interaction of the solution Flexibility of the solution (additional code support) Auditability of the solution Interoperability of the solution / which parts are replaceable transparently Consider convenience and price point Privacy is still very much a work in progress (see DAA efforts)

6. Protecting secrets The original use case for third party secrets (SIM card holding the network secret, banking card holding the bank secret) Holding the user secrets for Hardware Wallets, and hiding secrets for specific use cases (for example see Othercoin private key exchange https://bitcointalk.org/index.php?topic=319146.0) Key point is physical attack resistance requiring specific countermeasures Encrypted memory buses Tamper sensors Meshes ... Hard to audit by design

7. Secure hardware distribution Secure Element use case (additional hardware shipped) Typically done by providing each customer with a specific key at factory Limited trust points : the manufacturer, the customer. TPM / Secure Boot use case (integrated hardware) “Freeze” the environment in a given configuration More trust points in the implementation + trust the original measurement / sealing

8. Protection against software attacks Novel use case with security functionalities of generic application processors (TrustZone, SGX), high convenience Different enclaves, different trust levels, different scopes, sometimes in the same implementation - looking at a modern Samsung phone Assisting in Secure Boot (AOSP + Samsung) Monitoring the system integrity following Secure Boot (Samsung Knox) Providing a trusted store for cryptographic operations (AOSP + Google Trusty) Providing a secure application execution environment (GlobalPlatform)

9. Proof of code execution Novel use case, different scenarios for Blockchain applications Consensus related (Sawtooth Lake) Application related (Town Crier, Teechan) Trust points depending on the stack : implementation, provisioning, issuer, blacklists ...

10. A popular abstraction : Java Card Java Card, started 2000 More or less frozen since Java Card 2.2 (2002), only adding new cryptographic algorithms Widely deployed on SIM cards, yubikeys, generic Secure Elements, high end TPM chips - popular for porting certified applications Not auditable (proprietary OS, proprietary VM, no Open Source port) No attestation mechanism (proof of installation, not available at runtime)

11. Naive provisioning model (Issuer Security Domain) GlobalPlatform Card specification, adds Security Domain isolation Provisioning bound to the knowledge of a symmetric card key - optional confidentiality No additional trust implied Not a realistic deployment model (full card access), only for development cards Install application User ISD Owns application

12. Less naive but still non workable provisioning model (SSD) Supplementary Security Model delegated to the customer Provisioning bound to the knowledge of a symmetric SSD key Additional trust : DoS / impersonation of the app by the third party Trust requirement cannot work for commercial deployments Install application Create SSD User SSD Owns application Third party ISD

13. Could have worked but not available to end user (CCCM) Confidential Card Content Management, GlobalPlatform Amendment A let the ISD create a SSD directly on behalf of the party requesting the information Provisioning bound to the knowledge of a symmetric SSD key No additional trust implied Install application Creates SSD on behalf of the customer User SSD Owns application ISD

14. What has been deployed instead (TSM) Trusted Service Manager, set of GSMA standards - basically puts the previous logic around a blackbox Additional trust : application developer, application issuer Provides application Installs application TSM Application Developer User Manages SSD/applications life cycle Application Issuer

15. Java Card open development resources Getting used to it without hardware : https://github.com/licel/jcardsim With hardware : Yubikey with Fidesmo http://www.fidesmo.com/ - SSD model with keys handled by Fidesmo, applications can be audited by disabling confidentiality when loading Comparison of cryptographic features supported by different vendors : https://www.fi.muni.cz/~xsvenda/jcalgtest Applets zoo : https://javacard.pro/

16. Lessons learned from Java Card Monolithic model (OS + Virtual Machine in a blackbox) The core provisioning protocols let end users upload / verify their own applications Not what’s commercially deployed No arbitrary applications upload Confidentiality cannot be disabled The TSM model is a reference for the deployment of other secure services (TEE applications)

17. ARM enclaves basics The TrustZone CPU feature just defines a security bit - swap access to resources between a Secure and a Non Secure world Minimum part to put on top of it : Secure Monitor (“specialized MMU”) Additional parts : API and resource sharing Basic trust requirements : TZ implementation / resources sharing (typically RAM) Secure Boot mechanism protecting the Secure Monitor (often proprietary)

18. Commercially deployed ARM enclaves A mixed bag of Fully proprietary and closed enclaves exposing simple cryptographic APIs (Apple) - analysis https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf Mostly proprietary and closed enclaves exposing simple cryptographic APIs (Android + Google Trusty) GlobalPlatform TEE compatible enclaves allowing third party code deployment (Android + Trustonic)

19. Deploying on a Trustonic enclave The provisioning part is not standardized, here it follows the TSM model (now rebranded Trusted Applications Manager) over an encrypted channel Provisioned code cannot be verified Additional trust requirements : Trustonic, TSM, Application vendor Other side issues, related to commercial agreements : Slow deployment with different feature set per deployment Trusted UI support is CPU dependant

20. Simulating portable arbitrary code to the end users Steep trust requirements, cost of jumping through all the previous hoops Can bootstrap an additional vendor-known secret at Trustlet installation (weak attestation logic) Runtime available at https://github.com/ledgerhq/bolos-tee

21. Experimenting with ARM enclaves USB Armory : offers a fully documented Secure Boot on i.MX53 https://inversepath.com/usbarmory.html Genode implementation notes : http://genode.org/documentation/articles/trustzone GlobalPlatform TEE implementation : https://github.com/OP-TEE/optee_os

22. Intel enclave basics SGX works at a higher level, already defines memory zones for secure execution No third party involved in building extra layers to create the core logic Deployment policy is still TBD (will likely not use an encrypted channel though) Attestation of the running code is built in, Intel trust required, around a non public group signature algorithm

23. Experimenting with SGX Intel Core CPU Skylake or above, Linux SDK doesn’t require a specific compiler : https://01.org/intel-softwareguard-extensions Linux limitation : all services are not available (typically validation of remote attestation) Self signed enclave limitation : debugging cannot be disabled (not to be used in a production system)

24. Common enclaves limitations No on chip storage available - full state rollbacks are always possible unless a specific anti replay flash is used (starting to appear, likely costly) Monotonic counters are not available on all platforms, making application rollbacks possible Extremely complex reviewing process (no adversarial EAL evaluation of a commercially deployed product yet)

25. Conclusion Start early and limited trust - change with deployment Improvements on chip auditability Improvements on process auditability

26. Thank you @btchip