Authentic Execution of Distributed Event-Driven Applications with a - PowerPoint PPT Presentation

Authentic Execution of Distributed Event-Driven Applications with a Small TCB Job Noorman, Jan Tobias Mühlberg and Frank Piessens jantobias.muehlberg@cs.kuleuven.be imec-DistriNet, KU Leuven, Celestijnenlaan 200A, B-3001 Belgium STM’17, Oslo, September 2017

empty Authentic Execution of Distributed Event-Driven Applications 2 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications Authentic Execution • We can explain every observed output event based on a trace of actual input events and the (source) code of the application, in the presence of network and software attackers 3 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications Authentic Execution • We can explain every observed output event based on a trace of actual input events and the (source) code of the application, in the presence of network and software attackers . . . modulo availability and confidentiality, but . . . 3 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications Authentic Execution • We can explain every observed output event based on a trace of actual input events and the (source) code of the application, in the presence of network and software attackers . . . modulo availability and confidentiality, but . . . Distributed Event-Driven Applications • Application modules execute on heterogeneous distributed infrastructure • Each module provides input and output channels that transparently connect to other modules’ channels • Physical events enter or leave the application through I/O channels • Multiple distrusting applications share the infrastructure 3 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications Authentic Execution • We can explain every observed output event based on a trace of actual input events and the (source) code of the application, in the presence of network and software attackers . . . modulo availability and confidentiality, but . . . Distributed Event-Driven Applications • Application modules execute on heterogeneous distributed infrastructure • Each module provides input and output channels that transparently connect to other modules’ channels • Physical events enter or leave the application through I/O channels • Multiple distrusting applications share the infrastructure With a small (run-time) Trusted Computing Base • Code that is not part of an application cannot interfere with that application 3 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications A (complicated & unrealistic) Example Scenario A car park with 2 parking positions and 2 monitoring applications: Violation monitor A Vio and position availability monitor A Avl Violation D P1 D P2 Button D T1 D T2 D D1 Sensor driver Sensor driver Button Display Violations: Clock driver Clock driver driver None M VioP1 M VioP2 Tick Tick M VioD Display M AvlP1 M AvlP2 Violation Untrusted OS CarMoved Untrusted OS Untrusted OS N D 1 N P 1 N P 2 D D2 Display Available: M Agg driver 2 Untrusted OS M AvlD AvlChanged Untrusted OS N Agg N D 2 4 /21 Jan Tobias Mühlberg Authentic Execution

empty The Shared Infrastructure Requirements: some form of Trusted Computing • Authenticated communication • Software & device attestation • Secure I/O 5 /21 Jan Tobias Mühlberg Authentic Execution

empty The Shared Infrastructure Requirements: some form of Trusted Computing • Authenticated communication • Software & device attestation • Secure I/O Implementation options • Intel SGX (no I/O) • ARM TrustZone (only one trusted world) • Sancus (lightweight & embedded, no complex computations) • . . . Embracing heterogeneity • Application modules can exploit specific features of an architecture, as long as authenticated communication and attestation are available & compatible • Prototype for Sancus 5 /21 Jan Tobias Mühlberg Authentic Execution

empty Sancus: A Security Architecture for IoT [NAD + 13, NVBM + 17] • Extends TI’s MSP430 with strong security primitives • Software Component Isolation • Cryptography & Attestation • Secure I/O through isolation of MMIO ranges • Efficient • Authentication in µ s • 6% increased power consumption • Cryptographic key hierarchy for software attestation • Isolated components are typically very small ( < 1kLOC) • Sancus is Open Source: https://distrinet.cs.kuleuven.be/software/sancus/ 6 /21 Jan Tobias Mühlberg Authentic Execution

empty Sancus: A Security Architecture for IoT [NAD + 13, NVBM + 17] • Extends TI’s MSP430 with N = Node; SP = Software Provider / Deployer strong security primitives SM = protected Software Module • Software Component Isolation • Cryptography & Attestation SM protected data section SM text section • Secure I/O through isolation Entry point Memory of MMIO ranges Unprotected Code & constants Unprotected Unprotected Protected data • Efficient • Authentication in µ s • 6% increased power K N , SP , SM SM metadata Protected consumption storage area K N • Cryptographic key hierarchy Layout Keys for software attestation • Isolated components are typically very small ( < 1kLOC) • Sancus is Open Source: https://distrinet.cs.kuleuven.be/software/sancus/ 7 /21 Jan Tobias Mühlberg Authentic Execution

empty Attestation and Communication Ability to use K N , SP , SM proves the integrity and isolation of SM deployed by SP on N • Only N and SP can calculate K N , SP , SM N knows K N and SP knows K SP • K N , SP , SM on N is calculated after enabling isolation No isolation, no key; no integrity, wrong key • Only SM on N is allowed to use K N , SP , SM Through special instructions 8 /21 Jan Tobias Mühlberg Authentic Execution

empty Attestation and Communication Ability to use K N , SP , SM proves the integrity and isolation of SM deployed by SP on N • Only N and SP can calculate K N , SP , SM N knows K N and SP knows K SP • K N , SP , SM on N is calculated after enabling isolation No isolation, no key; no integrity, wrong key • Only SM on N is allowed to use K N , SP , SM Through special instructions Remote attestation and secure communication by Authenticated Encryption with Associated Data • Confidentiality, integrity and authenticity • Encrypt and decrypt instructions use K N , SP , SM of the calling SM • Associated Data can be used for nonces to get freshness 8 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications A (complicated & unrealistic) Example Scenario A car park with 2 parking positions and 2 monitoring applications: Violation monitor A Vio and position availability monitor A Avl Violation D P1 D P2 Button D T1 D T2 D D1 Sensor driver Sensor driver Button Display Violations: Clock driver Clock driver driver None M VioP1 M VioP2 Tick Tick M VioD Display M AvlP1 M AvlP2 Violation Untrusted OS CarMoved Untrusted OS Untrusted OS N D 1 N P 1 N P 2 D D2 Display Available: M Agg driver 2 Untrusted OS M AvlD AvlChanged Untrusted OS N Agg N D 2 9 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications 1 module AvlP1 · · · 2 on Button(pressed): Standard entry stub CarMoved(entered) 3 SetKey 4 module AvlP2 Entry points Generated 5 # Similar to AvlP1 HandleInput 6 HandleOutput 7 module Agg Non-entry CarMoved1 functions 8 on CarMoved1(entered): Event handlers CarMoved2 p1 = entered 9 CbTable Generated num_avl = NUM_PARKINGS 10 Constants NUM_PARKINGS Constants if (p1): num_avl = num_avl - 1 11 12 if (p2): num_avl = num_avl - 1 · · · AvlChanged(num_avl) Standard runtime 13 14 on CarMoved2(entered): data (stack,.. . ) Generated # Similar to CarMoved1 15 KeyTable 16 NonceTable 17 module AvlD Variables p1 18 on AvlChanged(num_avl) Globals p2 Display(num_avl) 19 · · · 10 /21 Jan Tobias Mühlberg Authentic Execution

empty Authentic Execution of Distributed Event-Driven Applications Developer / Software Provider provides: • Source code of all application modules · · · Standard entry stub • Deployment descriptor SetKey • Mapping modules to nodes Entry points Generated HandleInput • Configuration of communication channels HandleOutput and I/O channels Non-entry CarMoved1 functions Event handlers CarMoved2 CbTable Generated Constants NUM_PARKINGS Constants · · · Standard runtime data (stack,.. . ) Generated KeyTable NonceTable Variables p1 Globals p2 · · · 11 /21 Jan Tobias Mühlberg Authentic Execution