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

▶
authentic execution of distributed event driven
SMART_READER_LITE
LIVE PREVIEW

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

Jul 24, 2023 268 likes •571 views

Authentic Execution of Distributed Event-Driven Applications with a Small TCB Job Noorman, Jan Tobias Mhlberg and Frank Piessens jantobias.muehlberg@cs.kuleuven.be imec-DistriNet, KU Leuven, Celestijnenlaan 200A, B-3001 Belgium STM17, Oslo,

slide-1
SLIDE 1

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

slide-2
SLIDE 2

empty

Authentic Execution of Distributed Event-Driven Applications

2 /21 Jan Tobias Mühlberg Authentic Execution

slide-3
SLIDE 3

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

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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 AVio and position availability monitor AAvl

DP1 DT1 DP2 DT2 Sensor driver Clock driver MVioP1 MAvlP1 Untrusted OS NP 1 Sensor driver Clock driver MVioP2 MAvlP2 Untrusted OS NP 2 MAgg Untrusted OS NAgg Display driver MVioD Untrusted OS ND1 Violations: None DD1 Display driver MAvlD Untrusted OS ND2 Available: 2 DD2

Violation Violation AvlChanged Display Button Button Tick Tick CarMoved 4 /21 Jan Tobias Mühlberg Authentic Execution

slide-8
SLIDE 8

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

slide-9
SLIDE 9

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

slide-10
SLIDE 10

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
  • f 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

slide-11
SLIDE 11

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
  • f 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/

7 /21 Jan Tobias Mühlberg Authentic Execution

N = Node; SP = Software Provider / Deployer SM = protected Software Module

Unprotected Entry point Code & constants Unprotected SM text section Protected data SM protected data section Unprotected Memory KN,SP,SM SM metadata Layout Keys Protected storage area KN

slide-12
SLIDE 12

empty

Attestation and Communication

Ability to use KN,SP,SM proves the integrity and isolation

  • f SM deployed by SP on N
  • Only N and SP can calculate KN,SP,SM

N knows KN and SP knows KSP

  • KN,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 KN,SP,SM

Through special instructions

8 /21 Jan Tobias Mühlberg Authentic Execution

slide-13
SLIDE 13

empty

Attestation and Communication

Ability to use KN,SP,SM proves the integrity and isolation

  • f SM deployed by SP on N
  • Only N and SP can calculate KN,SP,SM

N knows KN and SP knows KSP

  • KN,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 KN,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 KN,SP,SM of the calling SM
  • Associated Data can be used for nonces to get freshness

8 /21 Jan Tobias Mühlberg Authentic Execution

slide-14
SLIDE 14

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 AVio and position availability monitor AAvl

DP1 DT1 DP2 DT2 Sensor driver Clock driver MVioP1 MAvlP1 Untrusted OS NP 1 Sensor driver Clock driver MVioP2 MAvlP2 Untrusted OS NP 2 MAgg Untrusted OS NAgg Display driver MVioD Untrusted OS ND1 Violations: None DD1 Display driver MAvlD Untrusted OS ND2 Available: 2 DD2

Violation Violation AvlChanged Display Button Button Tick Tick CarMoved 9 /21 Jan Tobias Mühlberg Authentic Execution

slide-15
SLIDE 15

empty

Authentic Execution of Distributed Event-Driven Applications

1 module AvlP1 2 on Button(pressed): 3

CarMoved(entered)

4 module AvlP2 5 # Similar to AvlP1 6 7 module Agg 8 on CarMoved1(entered): 9

p1 = entered

10

num_avl = NUM_PARKINGS

11

if (p1): num_avl = num_avl - 1

12

if (p2): num_avl = num_avl - 1

13

AvlChanged(num_avl)

14 on CarMoved2(entered): 15

# Similar to CarMoved1

16 17 module AvlD 18 on AvlChanged(num_avl) 19

Display(num_avl)

10 /21 Jan Tobias Mühlberg Authentic Execution

· · · Standard entry stub SetKey HandleInput HandleOutput CarMoved1 CarMoved2 CbTable NUM_PARKINGS · · · Standard runtime data (stack,.. . ) KeyTable NonceTable p1 p2 · · ·

Entry points Non-entry functions Constants Variables Generated Event handlers Generated Constants Generated Globals

slide-16
SLIDE 16

empty

Authentic Execution of Distributed Event-Driven Applications

Developer / Software Provider provides:

  • Source code of all application modules
  • Deployment descriptor
  • Mapping modules to nodes
  • Configuration of communication channels

and I/O channels

11 /21 Jan Tobias Mühlberg Authentic Execution

· · · Standard entry stub SetKey HandleInput HandleOutput CarMoved1 CarMoved2 CbTable NUM_PARKINGS · · · Standard runtime data (stack,.. . ) KeyTable NonceTable p1 p2 · · ·

Entry points Non-entry functions Constants Variables Generated Event handlers Generated Constants Generated Globals

slide-17
SLIDE 17

empty

Authentic Execution of Distributed Event-Driven Applications

Developer / Software Provider provides:

  • Source code of all application modules
  • Deployment descriptor
  • Mapping modules to nodes
  • Configuration of communication channels

and I/O channels

Toolchain:

  • Compilation and linking
  • Generate code to configure channels,

communication keys, and to encrypt and decrypt events

  • Prepare secure linking with I/O modules
  • Deployment:
  • Load and activate modules
  • Configure communication channels

11 /21 Jan Tobias Mühlberg Authentic Execution

· · · Standard entry stub SetKey HandleInput HandleOutput CarMoved1 CarMoved2 CbTable NUM_PARKINGS · · · Standard runtime data (stack,.. . ) KeyTable NonceTable p1 p2 · · ·

Entry points Non-entry functions Constants Variables Generated Event handlers Generated Constants Generated Globals

slide-18
SLIDE 18

empty

Deployment

Deployment of application code

1 Compile all source modules to PMs 2 Load them on the node specified in the deployment descriptor 3 Generate cryptographic keys for each connection 4 Send keys to the sending and receiving modules, encrypted by the

appropriate module keys KN,SP,SM Connections to physical I/O channels

5 Generate keys for connections to physical outputs, send them to application

module and protected driver module and attest success

6 Generate keys for connections to physical inputs and send them to application

module and protected driver module Infrastructure that implements deployment is trusted.

12 /21 Jan Tobias Mühlberg Authentic Execution

slide-19
SLIDE 19

empty

Protected Driver Modules

Driver modules have to satisfy properties that depend on the desired security guarantee:

  • E.g. Integrity:
  • Applications must be able to take exclusive ownership of protected driver

modules of output devices

  • But protected driver modules for input devices can broadcast input events to all

applications with only integrity protection → Integrity protected channel from physical inputs to physical outputs

  • Confidentiality is dual
  • Properties to be checked by the application deployer / SP
  • Architectural support (i.e. hardware) is crucial

13 /21 Jan Tobias Mühlberg Authentic Execution

slide-20
SLIDE 20

empty

Security Properties

Remember our security objective:

  • We can explain every observed output event based on a trace of actual input

events and the (source) code of the application

  • Security properties that hold for the source code should hold at run-time in the

presence of arbitrary attackers within the attacker model → https://people.cs.kuleuven.be/~jantobias.muehlberg/stm17/ This holds for arbitrary safety properties

  • E.g. “No violation is signalled on the display unless a car entered and stayed

there for > n clock ticks” But it does not hold for:

  • Arbitrary confidentiality properties; can be fixed at the expense of efficiency
  • Availability or real-time properties; work-in-progress, weaker attacker model

14 /21 Jan Tobias Mühlberg Authentic Execution

slide-21
SLIDE 21

empty

Extended Application Scenarios

“An Implementation of a High Assurance Smart Meter using Protected Module Architectures”, Mühlberg et al., WISTP 2016, pages 53–69.

15 /21 Jan Tobias Mühlberg Authentic Execution

slide-22
SLIDE 22

empty

Extended Application Scenarios

“Efficient Component Authentication and Software Isolation for Automotive Control Networks”, Van Bulck et al., ACSAC 2017, in press.

16 /21 Jan Tobias Mühlberg Authentic Execution

slide-23
SLIDE 23

empty

Summary & Conclusions

Authentic Execution of Distributed Event-Driven Applications

  • Secure and open software application platforms for distributed IT, in the

presence of network / software attackers

17 /21 Jan Tobias Mühlberg Authentic Execution

slide-24
SLIDE 24

empty

Summary & Conclusions

Authentic Execution of Distributed Event-Driven Applications

  • Secure and open software application platforms for distributed IT, in the

presence of network / software attackers

  • Critical software components are resilient against attacks
  • Security of each module independent from other software
  • Authenticated communication and remote attestation links components of

application

  • We have a chain of mutual trust among distributed application modules

→ Output is guaranteed to be reproducible, wrt. application’s (source) code and inputs

17 /21 Jan Tobias Mühlberg Authentic Execution

slide-25
SLIDE 25

empty

Summary & Conclusions

Authentic Execution of Distributed Event-Driven Applications

  • Secure and open software application platforms for distributed IT, in the

presence of network / software attackers

  • Critical software components are resilient against attacks
  • Security of each module independent from other software
  • Authenticated communication and remote attestation links components of

application

  • We have a chain of mutual trust among distributed application modules

→ Output is guaranteed to be reproducible, wrt. application’s (source) code and inputs

  • Run-time TCB is drastically reduced!
  • Applicable in many domains: automotive, medical, . . .

17 /21 Jan Tobias Mühlberg Authentic Execution

slide-26
SLIDE 26

empty

Ongoing Research

IoT Trust Assessment: implement light-weight and secure inspection components that integrate seamlessly with existing deployment scenarios [MNP15] Programming Models and Infrastructure: guarantee authenticity and integrity properties of event-driven distributed applications; integration with server/desktop PMA; automating secure compilation to PMAs [BNMP15, PAS+15, vGSMP16] Secure I/O: Trusted Paths between microcontrollers attached to sensors and actuators [NVBM+17, MCM+16] Safe Languages and Formal Verification: Protected Modules must be free of vulnerabilities (e.g. memory safety, information flow) to guarantee safe operation [vGSMP16] Availability and Real-Time Guarantees: to control reactive safety-critical components in, e.g. automotive, avionic and medical domains [VBNMP16]

18 /21 Jan Tobias Mühlberg Authentic Execution

slide-27
SLIDE 27

empty

Thank you!

Thank you! Questions?

https://people.cs.kuleuven.be/ jantobias.muehlberg/stm17/ https://distrinet.cs.kuleuven.be/software/sancus/

19 /21 Jan Tobias Mühlberg Authentic Execution

slide-28
SLIDE 28

empty

References I

  • J. V. Bulck, J. Noorman, J. T. Mühlberg, and F. Piessens.

Secure resource sharing for embedded protected module architectures. In WISTP ’15, vol. 9311 of LNCS, pp. 71–87, Heidelberg, 2015. Springer.

  • J. T. Mühlberg, S. Cleemput, M. A. Mustafa, J. V. Bulck, B. Preneel, and F. Piessens.

An implementation of a high assurance smart meter using protected module architectures. In WISTP ’16, vol. 9895 of LNCS, pp. 53–69, Heidelberg, 2016. Springer.

  • J. T. Mühlberg, J. Noorman, and F. Piessens.

Lightweight and flexible trust assessment modules for the Internet of Things. In ESORICS ’15, vol. 9326 of LNCS, pp. 503–520, Heidelberg, 2015. Springer.

  • J. Noorman, P

. Agten, W. Daniels, R. Strackx, A. Van Herrewege, C. Huygens, B. Preneel, I. Verbauwhede, and F. Piessens. Sancus: Low-cost trustworthy extensible networked devices with a zero-software trusted computing base. In Proceedings of the 22Nd USENIX Conference on Security, SEC’13, pp. 479–494, Berkeley, CA, USA, 2013. USENIX Association.

  • J. Noorman, J. Van Bulck, J. T. Mühlberg, F. Piessens, P

. Maene, B. Preneel, I. Verbauwhede, J. Götzfried, T. Müller, and F. Freiling. Sancus 2.0: A low-cost security architecture for IoT devices. ACM Transactions on Privacy and Security (TOPS), 20:7:1–7:33, 2017.

  • M. Patrignani, P

. Agten, R. Strackx, B. Jacobs, D. Clarke, and F. Piessens. Secure compilation to protected module architectures. ACM Trans. Program. Lang. Syst., 37(2):6:1–6:50, 2015.

  • J. Van Bulck, J. Noorman, J. T. Mühlberg, and F. Piessens.

Towards availability and real-time guarantees for protected module architectures. In MASS ’16, MODULARITY Companion 2016, pp. 146–151, New York, 2016. ACM. 20 /21 Jan Tobias Mühlberg Authentic Execution

slide-29
SLIDE 29

empty

References II

  • N. van Ginkel, R. Strackx, J. T. Mühlberg, and F. Piessens.

Towards safe enclaves. In 4th Workshop on Hot Issues in Security Principles and Trust (HotSpot ’16), pp. 33–48. IFIP , 2016. 21 /21 Jan Tobias Mühlberg Authentic Execution