Upload
others
View
8
Download
0
Embed Size (px)
Citation preview
embedded systems security: virtualizationand beyond
Kolin Paulhttp://www.cse.iitd.ac.in/~kolin
Department of Computer Science and TechnologyIndian Institute of Technology Delhi
day one
me
• Associate Professor @CSE@IITD
• Research Area• Reconfigurable Computing
• Silicon Compilation• Custom Processor Design
• Embedded Systems• Runtime Systems
• Hardware Security.
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 3
introduction
• Security and Privacy are key challenges to IoT Growth1
• Security is often a BoltOn
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 4
iot architecture
• IoT is• Devices using Internet Protocol to
communicate
• Why the Buzz ...• 32 bit µControllers• Powerful yet low power• Can run the entire Stack
• Hence
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 5
iot architecture
• IoT is• Devices using Internet Protocol to
communicate
• Why the Buzz ...• 32 bit µControllers• Powerful yet low power• Can run the entire Stack
• Hence
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 6
so why should we be concerned?
• 20-50 Billion Devices• Unequal Capabilities• Security in the whole• Design time constraint
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 7
how real is the threat?
• Smart Grid
Source: Google
• Smart Meter• Physical Attack• Breach of metering databases• Remote connect/disconnect
Notice the significant increase in Attack Surface by becoming Smart
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 8
how real is the threat?
• Smart Grid
Source: Google
• Smart Meter• Physical Attack• Breach of metering databases• Remote connect/disconnect
Notice the significant increase in Attack Surface by becoming Smart
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 9
how real is the threat?
• Smart Grid
Source: Google
• Smart Meter• Physical Attack• Breach of metering databases• Remote connect/disconnect
Notice the significant increase in Attack Surface by becoming Smarthttp://www.cse.iitd.ac.in/~kolin Embedded Systems Security 10
how real is the threat?
• Connected Vehicles• V2V Communications• Mobile Integration• In car WiFi
• Risks• Install “unauthorized components”• Tamper ECU• Fake ADAS Messages• Leak Driver/owner behavior information• Electronic Attack
• Current Scenario• Very few “(Open) Gates”• ECUs are secured• Similar to a Bank vault
Notice the significant increase in Attack Surface by becoming Smart
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 11
how real is the threat?
• Connected Vehicles• V2V Communications• Mobile Integration• In car WiFi
• Risks• Install “unauthorized components”• Tamper ECU• Fake ADAS Messages• Leak Driver/owner behavior information• Electronic Attack
• Current Scenario• Very few “(Open) Gates”• ECUs are secured• Similar to a Bank vault
Notice the significant increase in Attack Surface by becoming Smarthttp://www.cse.iitd.ac.in/~kolin Embedded Systems Security 12
challenges and opportunities
• Opportunities• Healthcare• Homes• Smart Cities• (Connected) Vehicles
• Challenges• Potentially insecure code• Unauthenticated Devices• Device EveryWhere Syndrome• Absence of a System Level
Abstraction
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 13
the solution space
• Tamper-proofing the hardware• Implementing secure processing domains
• ARM TrustZone• Secure boot• Secure storage
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 14
hardware security
• Ensure Code at Boot is “authentic”• Root of Trust• Secure Boot• DPA Resistant• Protect IP
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 15
system virtualization
• Complexity of the Stack• Every linux based effort becomes a proprietary stack• Typical OS abstractions are mature
• New emerging requirements, IP issues can be frustrating to implement incurrent stack
• A new OS in market
New Level of Abstraction needed to handle sophisticated electronichardware is the OS
• Have the ability to run any operating system in the hardware
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 16
system virtualization
• Complexity of the Stack• Every linux based effort becomes a proprietary stack• Typical OS abstractions are mature
• New emerging requirements, IP issues can be frustrating to implement incurrent stack
• A new OS in marketNew Level of Abstraction needed to handle sophisticated electronichardware is the OS
• Have the ability to run any operating system in the hardware
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 17
embedded hypervisor
• System Virtualization• Enables hosting of multiple OS in
the same physical hardware
• Also known as Virtual Machines• Guest Operating systems
• Different from Enterprisehypervisors• Embedded hypervisor is designed
specifically for embedded andmobile systems
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 18
embedded hypervisor
• System Virtualization• Enables hosting of multiple OS in
the same physical hardware
• Also known as Virtual Machines• Guest Operating systems
• Different from Enterprisehypervisors• Embedded hypervisor is designed
specifically for embedded andmobile systems
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 19
applications of virtualization
• Time Sharing used in data centerserver consolidation
• Testing new (versions) of OSarchitectures
• Backward Compatibility
• Environment Sandboxing• Virtual Machine isolation• Robustness depends on the
underlying hypervisor architecture• Enterprise hypervisor flaws have
been exploited
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 20
applications of virtualization
• Time Sharing used in data centerserver consolidation
• Testing new (versions) of OSarchitectures
• Backward Compatibility
• Environment Sandboxing• Virtual Machine isolation• Robustness depends on the
underlying hypervisor architecture• Enterprise hypervisor flaws have
been exploited
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 21
arm trust zone
• Virtual Security Appliances• Isolate the trusted component
from the primary OS
Source:http://www.adac.co.jp/eng/products/multivisor/images/TrustZone.jpg
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 22
a solution
• A typical Embedded SystemImplementation using Hypervisors
• Hardware based security fornetworked embedded systems
• Prevent unauthorized networktransactions
• Anti-malware must run in aseparate space
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 23
a solution
• A typical Embedded SystemImplementation using Hypervisors • Hardware based security for
networked embedded systems• Prevent unauthorized network
transactions• Anti-malware must run in a
separate space
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 24
exploit trust zone
• Available in ARM1176, Cortex-A*• VMware introduced full system virtualization• Hardware security extensions
• Virtualizes a physical core as two virtual cores
• Processor state: set/reset NS (Non-Secure)bit of the SCR (Secure ConfigurationRegister) via CP15 interface
• Trustzone Software Architecture• Key Idea: Separate Execution
Domains• Low Cost Security Framework
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 25
system architecture
• System call trap• LKM in Hypervisor “redirects”
syscalls
• Security policy• Policy accesible to secure VM only• Encrypted Flash
• Hardware Policy based Passthru• Can selectively do PCI passthru
• Implementation• Solution implemented using KVM
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 26
system architecture
• System call trap• LKM in Hypervisor “redirects”
syscalls
• Security policy• Policy accesible to secure VM only• Encrypted Flash
• Hardware Policy based Passthru• Can selectively do PCI passthru
• Implementation• Solution implemented using KVM
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 27
system architecture
• System call trap• LKM in Hypervisor “redirects”
syscalls
• Security policy• Policy accesible to secure VM only• Encrypted Flash
• Hardware Policy based Passthru• Can selectively do PCI passthru
• Implementation• Solution implemented using KVM
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 28
system architecture
• System call trap• LKM in Hypervisor “redirects”
syscalls
• Security policy• Policy accesible to secure VM only• Encrypted Flash
• Hardware Policy based Passthru• Can selectively do PCI passthru
• Implementation• Solution implemented using KVM
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 29
using reconfigurable devices
• Reconfigurable Devices• Security policy decryption engine• Processor cache/RAM: No access to secure data• Reduced Overheads
• Driver only for the Decryption Engine
Transmission Rate (µs/Transmission)Without LKM 6217.38 196.170With LKM 5097.63 224.003
Configurable hardware defines the security policies and makes that visibleonly to the security VMJoint work with Anupam Joshi and Vivek Parmar
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 30
using reconfigurable devices
• Reconfigurable Devices• Security policy decryption engine• Processor cache/RAM: No access to secure data• Reduced Overheads
• Driver only for the Decryption Engine
Transmission Rate (µs/Transmission)Without LKM 6217.38 196.170With LKM 5097.63 224.003
Configurable hardware defines the security policies and makes that visibleonly to the security VMJoint work with Anupam Joshi and Vivek Parmar
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 31
using reconfigurable devices
• Reconfigurable Devices• Security policy decryption engine• Processor cache/RAM: No access to secure data• Reduced Overheads
• Driver only for the Decryption Engine
Transmission Rate (µs/Transmission)Without LKM 6217.38 196.170With LKM 5097.63 224.003
Configurable hardware defines the security policies and makes that visibleonly to the security VMJoint work with Anupam Joshi and Vivek Parmar
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 32
iot security
• Smart interconnected devicesoperate in swarms
• Nowadays most device attestationscheme assume a single proverdevice and don’t not scale toswarms
• Software integrity verification ofdevice swarms is essential
Source: SEDA: Scalable Embedded Device Attestation N. Asokan et
al
• Offline Phase : Training• Initialize• Registration
• Online Phase : Attest
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 33
iot security
• Smart interconnected devicesoperate in swarms
• Nowadays most device attestationscheme assume a single proverdevice and don’t not scale toswarms
• Software integrity verification ofdevice swarms is essential
Source: SEDA: Scalable Embedded Device Attestation N. Asokan et
al
• Offline Phase : Training• Initialize• Registration
• Online Phase : Attest
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 34
iot security
• Smart interconnected devicesoperate in swarms
• Nowadays most device attestationscheme assume a single proverdevice and don’t not scale toswarms
• Software integrity verification ofdevice swarms is essential
Source: SEDA: Scalable Embedded Device Attestation N. Asokan et
al
• Offline Phase : Training• Initialize• Registration
• Online Phase : Attest
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 35
conclusion
• Architectures must transcend Domains• Need for System Wide Design Patterns• Programming Language Support to ensure Security is a Design
Parameter• Create Testbeds, Simulators, Reference Code Bases and Benchmarks
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 36
Thank You
http://www.cse.iitd.ac.in/~kolin Embedded Systems Security 37