architectural requirements for intransitive trust and
play

Architectural Requirements for Intransitive Trust and - PowerPoint PPT Presentation

Architectural Requirements for Intransitive Trust and Fault-and-Intrusion Tolerance Marcus Vlp University of Luxembourg Interdisciplinary Centre for Security, Reliability and Trust CritiX Critical and Extreme Security and Dependability


  1. Architectural Requirements for Intransitive Trust and Fault-and-Intrusion Tolerance Marcus Völp University of Luxembourg Interdisciplinary Centre for Security, Reliability and Trust CritiX – Critical and Extreme Security and Dependability Research Group PEARL Grant FNR/P14/8149128 – Paulo Esteves-Veríssimo We are hiring marcus.voelp@uni.lu PhDs/Postdocs! http://wwwen.uni.lu/snt/people/marcus_voelp

  2. The world is becoming infrastructure-centric ISP Re-identifying de-identified data ISP Identifying persons from 1000-Genomes database (2013) • Y chromosome is transmitted from father to son, as are familY surnames, • this strong correlation allowed to reveal the identitY behind 131 genomes! 2

  3. Attack sophistication vs. attacker expertise High At t a t t ackers TARGETED Bot Net s ATTACKS a.k.a. “ st ealt alt h” / adv advan anced d scanni nning ng t echni hnique ues ADVANCED Em be bedde dded d packet spoof pac poofin ing m al alic iciou ous de denial of ial of PERSISTENT code ode service DDO DDOS sniffers THREATS at at t ac acks w w w w w w sw eeper ers Required at at t ac acks au aut om om at at ed d pr probe obes/ scan ans attacker GUI expertise bac back door doors net w or ork m gm gm t . diagn diagnos ost ic ics disabli dis abling au g audit dit s hij ac acking g Available bu burglar glarie ies se sessi ssions attack exploit ploit ing k g know ow n vuln lnerabili abilit ies sophistication passw or pas ord d crac ackin ing self-repli plicat at ing c g code ode pas passw or ord d gu guessin ing At t a t t acks Low 1 9 8 5 1 9 9 0 1 9 9 5 2 0 0 0 2 0 xx… 1 9 8 0 (Source: Adapted from Lipson, H. F., Tracking and Tracing Cyber-Attacks: Technical Challenges and Global Policy Issues, Special Report CMS/SEI-2002-SR-009, November 2002. (CERT) 3

  4. The functionality/code size dilemma • Application scenarios require systems to provide a certain set of functionalities … e - e - low latency Control Control Control Control ESP / ABS ESP / ABS V2V / V2I V2V / V2I driving … lane keeping distance image processing trajectory situation recognition / planning platoon joining / leaving navigation complexity / computation demand adapted from: Urmson et al. “Autonomous driving in urban environments: Boss and the urban challenge,” Journal of Field Robotics ‘08 Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 4

  5. The functionality/code size dilemma • Application scenarios require systems to provide a certain set of functionalities … • … but to implement these functionalities we need a certain amount of code – even if development time and costs don’t matter; and – even if you only use high-class developers 5-13 PY • RTOS ca. 5 KLOC formal • Microkernel 10 – 15 KLOC verification • Legacy OS 15 – 50 MLOC • Chou et al. (SOSP’01): one bug every 1000 lines of code Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 5

  6. The functionality/code size dilemma Microkernel-/Microhypervisor Enclaves Based Systems Monolithic Operating Systems Apps. Apps. Apps. Enclave Enclave Apps. Apps. Apps. Apps. Apps. Apps. Management Operating System Legacy Operating System (Linux) Legacy Apps. Enclave Enclave Operating Filesystem Network Network Filesystem Drivers Drivers System Microkernel / Microhypervisor Memory Memory (Linux) Scheduling Threads Scheduling Threads Enclave Provider Mechanisms Policies Hardware (Multi- / Manycore ) Hardware (Multi- / Manycore ) Hardware (Enclave Provider) ~15-50 million LOC ~15 kLOC ? Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 6

  7. From transitive trust … secure secure App App legacy Player App App Legacy OS Resource Mgmt Net FS Driver Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 7

  8. … to intransitive trust secure secure App App legacy Player App App Legacy OS Codec Resource Mgmt Stub VPFS FS En-/Decryption Driver Framebuffer Mgr. • Weinhold et al., “ jVPFS: Adding Robustness to a Secure Stacked File System with Untrusted Local Storage Components”, USENIX ATC, 2011 • Singaravelu et al., “ Reducing TCB Complexity for Security-Sensitive Applications: Three Case Studies” , Eurosys, 2006 … • Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 8

  9. … to intransitive trust legacy Player App App Legacy OS secure secure Codec App App Resource Mgmt Stub VPFS FS En-/Decryption Driver Framebuffer Mgr. • Weinhold et al., “ jVPFS: Adding Robustness to a Secure Stacked File Inktag System with Untrusted Local Storage Components”, USENIX ATC, 2011 M3 Intel SGX Hoffmann et al. ‘13 • Singaravelu et al., “ Reducing TCB Complexity for Security-Sensitive Manycore + DTUs microhypervisor Applications: Three Case Studies” , Eurosys, 2006 … • Asmussen, Völp, … ARM Trustzone / … ASPLOS ‘16 Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 9

  10. … to intransitive trust legacy secure Player App What we know: App App • isolation fault A ≠> fault B Legacy OS VPFS VPFS VPFS VPFS VPFS VPFS • diversity Resource Mgmt • rejuvenation Stub Vote FS En-/Decryption Driver Inktag M3 Intel SGX Hoffmann et al. ‘13 Manycore + DTUs microhypervisor Asmussen, Völp, … ARM Trustzone / … ASPLOS ‘16 Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 10

  11. Architectural implications What we know: • i solation (fault A ≠> fault B) • diversity secure • rejuvenation App VPFS VPFS VPFS microhypervisor Core Core Core … Memory / IO Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 11

  12. Architectural implications What we know: What we don’t know: • isolation (fault A ≠> fault B) • is the digital system abstraction enough? • diversity • how can we prove absence of side-channels? • rejuvenation • how can we insert strong isolation into … (we like to keep plug+play HW design; existing structures (FPGA, GPU, …)? • IP cores in NoC) • novel materials structures (transistor-granular reconf. circuits, …)? need strong core-to-core isolation secure µ HV VPFS VPFS VPFS App Core Core Core GPU SiNW Neuro Core FPGA Core … Memory / IO need to be isolated from local core Dagstuhl Seminar 17061 - Wildly Heterogeneous Post-CMOS Technologies Meet Software - Marcus Völp (marcus.voelp@uni.lu) 12

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend