Secure Hardware and Blockchain Technologies - PowerPoint Presentation

Secure Hardware and Blockchain Technologies Stanford Cyber InitiativeJanuary 2017Nicolas Bacca @btchip

about:speakerNicolas 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

about:talkComments 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

Typical use cases for Secure HardwareProtect 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

Key elements from the different use casesIdentify who / what to trust, depending on the scenario from the purchase/deployment to the actual interaction of the solutionFlexibility 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)

Protecting secretsThe 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

Secure hardware distributionSecure 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

Protection against software attacksNovel use case with security functionalities of generic application processors (TrustZone, SGX), high convenienceDifferent 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)

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

A popular abstraction : Java CardJava Card, started 2000More 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)

Naive provisioning model (Issuer Security Domain)GlobalPlatform Card specification, adds Security Domain isolationProvisioning 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 User ISD Install application Owns application

Less naive but still non workable provisioning model (SSD)Supplementary Security Model delegated to the customerProvisioning 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 User SSD Install application Owns application ISD Third party Create SSD

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 informationProvisioning bound to the knowledge of a symmetric SSD key No additional trust implied User SSD Install application Owns application ISD Creates SSD on behalf of the customer

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

Java Card open development resourcesGetting 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/

Lessons learned from Java CardMonolithic 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)

ARM enclaves basicsThe 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)

Commercially deployed ARM enclavesA mixed bag ofFully 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)

Deploying on a Trustonic enclaveThe 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

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

Experimenting with ARM enclavesUSB 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

Intel enclave basicsSGX works at a higher level, already defines memory zones for secure executionNo 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

Experimenting with SGXIntel 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)

Common enclaves limitationsNo 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)

ConclusionStart early and limited trust - change with deploymentImprovements on chip auditability Improvements on process auditability

Thank you @btchip