Sancus: A Low-Cost Security Architecture for Distributed IoT Applications on a Shared Infrastructure Job Noorman Public PhD Defence 19 Apr 2017
Safety considerations when lodging in a hotel Untrusted guests Locked room Unknown personnel Just trust them Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 1 / 33
A hotel as an analogy for computing devices Untrusted guests Other applications Locked room Virtual memory, virtual machines,. . . Unknown personnel Operating system Just trust them Just trust it Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 1 / 33
A hotel as an analogy for computing devices Untrusted guests Other applications Locked room Virtual memory, virtual machines,. . . Unknown personnel Operating system Just trust them Just trust it Hostile environment Untrusted network Guarded transportation Cryptography Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 1 / 33
A hotel nobody would want to go, a good analogy for embedded devices Untrusted guests Other applications Locked room Virtual memory, virtual machines,. . . Unknown personnel Operating system Just trust them Just trust it Hostile environment Untrusted network Guarded transportation Cryptography No rooms/walls No software isolation Don’t go there Well, just go there anyway. . . Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 1 / 33
Lack of isolation problematic for third-party extensibility Private hotel Monolithic application No other guests Single, fixed binary Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 2 / 33
Lack of isolation problematic for third-party extensibility Private hotel Monolithic application No other guests Single, fixed binary Trusted guests First-party extensibility Bouncer at the entrance Authenticated binaries Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 2 / 33
Lack of isolation problematic for third-party extensibility Private hotel Monolithic application No other guests Single, fixed binary Trusted guests First-party extensibility Bouncer at the entrance Authenticated binaries Untrusted guests Third-party extensibility Rooms for security Memory isolation for security Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 2 / 33
Although very relevant, low-end devices lack effective security features More threats on embedded devices Due to network connectivity and third-party extensibility No effective solutions exist It’s “a mess” (Viega and Thompson) Researchers are exploring this area E.g., SMART (El Defrawy et al.) Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 3 / 33
Goal: create a trustworthy hotel for secure lodging Isolation of guests Private rooms for the guests Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 4 / 33
Goal: create a trustworthy hotel for secure lodging Isolation of guests Private rooms for the guests Attestation of well-being Proof unharmed arrival Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 4 / 33
Goal: create a trustworthy hotel for secure lodging Isolation of guests Private rooms for the guests Attestation of well-being Proof unharmed arrival Secure communication Call home/with other guests Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 4 / 33
Goal: create a trustworthy hotel for secure lodging Isolation of guests Private rooms for the guests Attestation of well-being Proof unharmed arrival Secure communication Call home/with other guests Zero-people Trusted Lodging Base Less people to trust, less can go wrong Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 4 / 33
Goal: design and implement a low-cost, extensible security architecture Isolation of software modules Memory isolation for data and code Attestation of a module’s state Proof integrity and isolation Secure communication Both locally and remotely Zero-software Trusted Computing Base Counteracting attackers with full control over infrastructural software Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 5 / 33
Extended goals Confidentiality of communication and code Authenticity often not enough Guarantees for distributed applications On an infrastructure shared with the attacker Securing unaltered legacy code When changing code is impossible/too expensive Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 6 / 33
Target: a generic system model Infrastructure provider IP IP owns and administers nodes N i N 1 SM 1 , 1 SM 2 , 1 SP 1 · · · Software providers SP j wants to use the infrastructure N 2 SM 2 , 2 SM j , k SP 2 · · · Software modules . . . . . . SM j , k is deployed by SP j on N i Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 7 / 33
Example node configuration Node SM 1 SP 1 . . . . SM S S . IP . SM n SP n Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 8 / 33
Preview Module isolation 1 Key management 2 Remote attestation and secure communication 3 Secure linking 4 Results 5 Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 9 / 33
Overview Module isolation 1 Hotel analogy Module layout Access rights enforcement Key management 2 Remote attestation and secure communication 3 Secure linking 4 Results 5 Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 10 / 33
Safe lodging for guests by building rooms Walls to keep other guests and personnel out Safeguard possessions, prevent attacks Door with lock to allow controlled access We want room service, right? Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 11 / 33
Modules are bipartite with a text section and a private data section Immutable text section Containing code and constants Private data section Containing secret runtime data Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 12 / 33
Node with one software module loaded Node SM 1 protected data section SM 1 text section Entry point Memory Unprotected Code & constants Unprotected Unprotected Protected data Next ID K N , SP , SM 1 SM 1 metadata Protected Caller ID storage area K N Layout Keys Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 13 / 33
Node with one software module loaded Text and data sections Node SM 1 protected data section SM 1 text section Entry point Memory Unprotected Code & constants Unprotected Unprotected Protected data Next ID K N , SP , SM 1 SM 1 metadata Protected Caller ID storage area K N Layout Keys Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 13 / 33
Node with one software module loaded Module layout Node SM 1 protected data section SM 1 text section Entry point Memory Unprotected Code & constants Unprotected Unprotected Protected data Next ID K N , SP , SM 1 SM 1 metadata Protected Caller ID storage area K N Layout Keys Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 13 / 33
Node with one software module loaded Module identity Node SM 1 protected data section SM 1 text section Entry point Memory Unprotected Code & constants Unprotected Unprotected Protected data Next ID K N , SP , SM 1 SM 1 metadata Protected Caller ID storage area K N Layout Keys Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 13 / 33
Node with one software module loaded Module entry point Node SM 1 protected data section SM 1 text section Entry point Memory Unprotected Code & constants Unprotected Unprotected Protected data Next ID K N , SP , SM 1 SM 1 metadata Protected Caller ID storage area K N Layout Keys Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 13 / 33
Node with one software module loaded Module keys Node SM 1 protected data section SM 1 text section Entry point Memory Unprotected Code & constants Unprotected Unprotected Protected data Next ID K N , SP , SM 1 SM 1 metadata Protected Caller ID storage area K N Layout Keys Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 13 / 33
Node with one software module loaded ID registers Node SM 1 protected data section SM 1 text section Entry point Memory Unprotected Code & constants Unprotected Unprotected Protected data Next ID K N , SP , SM 1 SM 1 metadata Protected Caller ID storage area K N Layout Keys Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 13 / 33
Modules are isolated using program-counter based memory access control Variable access rights Depending on the current program counter Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 14 / 33
Modules are isolated using program-counter based memory access control Variable access rights Depending on the current program counter From/to Text Data Unprotected Text Other Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 14 / 33
Modules are isolated using program-counter based memory access control Variable access rights Depending on the current program counter From/to Text Data Unprotected Text Other Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 14 / 33
Modules are isolated using program-counter based memory access control Variable access rights Depending on the current program counter From/to Text Data Unprotected Text Other Job Noorman (Public PhD Defence) Sancus 19 Apr 2017 14 / 33
Recommend
More recommend