Security for io t apr 29th mentor embedded hangout
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Security for io t apr 29th mentor embedded hangout

  • 485 views
Uploaded on

Security Strategies for Internet of Things From Devices to The Cloud -- these slides were presented during a live Google+ On-Air Hangout Panel on April 29th, 2014, presented by Mentor Graphics......

Security Strategies for Internet of Things From Devices to The Cloud -- these slides were presented during a live Google+ On-Air Hangout Panel on April 29th, 2014, presented by Mentor Graphics Embedded Software

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
485
On Slideshare
471
From Embeds
14
Number of Embeds
2

Actions

Shares
Downloads
40
Comments
0
Likes
3

Embeds 14

http://mangastorytelling.tistory.com 13
http://www.hanrss.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Security vs. ReliabilitySecurity is hard because it is a negative goal… negative goal is much harder than a positive goal.Computer Security - study of how to design systems behave as intended in the presence of determined, malicious 3rd party.Different than reliabilityMalicious 3rd party controls the probability distribution of malfunctions.. Reliability 1 % chance of something going wrong.. That is ok. If there is only a 1% of failure the adversary will focus on making that 1% happen all the time.
  • Key message: ARM TrustZone is one such hardware capability that can be leveraged to address issues of software integrity.
  • TrustZone does nothing to improve the safety or security of the Trusted software itself which must be explicitly tested and independently validated for exploits or bugs.
  • Key message: Directly Assigned DeviceUse “domains” / TZASC to assign devices to VMs1:1 mapping between a device and a VMNo device sharingDirect Hardware access -> highest performance, lowest latencyVirtual Device ModelVirtual device abstraction and driver lives in the VM Virtual driver routes IO to Hypervisor-resident driver Share physical devices between VMsSome performance reduction
  • TrustZone does nothing to improve the safety or security of the Trusted software itself which must be explicitly tested and independently validated for exploits or bugs.
  • Key message: Directly Assigned DeviceUse “domains” / TZASC to assign devices to VMs1:1 mapping between a device and a VMNo device sharingDirect Hardware access -> highest performance, lowest latencyVirtual Device ModelVirtual device abstraction and driver lives in the VM Virtual driver routes IO to Hypervisor-resident driver Share physical devices between VMsSome performance reduction
  • Key message: Directly Assigned DeviceUse “domains” / TZASC to assign devices to VMs1:1 mapping between a device and a VMNo device sharingDirect Hardware access -> highest performance, lowest latencyVirtual Device ModelVirtual device abstraction and driver lives in the VM Virtual driver routes IO to Hypervisor-resident driver Share physical devices between VMsSome performance reduction
  • Automation of testing into your monitoring frameworkTreat infrastructure as code, version control everythingUse security testing tools as part of your testing against your build candidates
  • Automation of testing into your monitoring frameworkTreat infrastructure as code, version control everythingUse security testing tools as part of your testing against your build candidates

Transcript

  • 1. mentor.com/embedded Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. A Live Google+ On-Air Hangout April 29th, 2014 Security Strategies for IoT Systems from Devices to the Cloud
  • 2. 2 mentor.com/embedded 22 The Internet of Things Spans Markets Smart Parking Monitoring of parking spaces availability in the city. Structural health Monitoring of vibrations and material conditions in buildings, bridges and historical monuments. Noise Urban Maps Sound monitoring in bar areas and centric zones in real time. Traffic Congestion Monitoring of vehicles and pedestrian levels to optimize driving and walking routes. Smart Lighting Intelligent and weather adaptive lighting in street lights. Waste management Detection of rubbish levels in containers to optimize the trash collection routes. Intelligent Transportation Systems Smart Roads and Intelligent Highways with warning messages and diversions according to climate conditions and unexpected events like accidents or traffic jams. Forest Fire Detection Monitoring of combustion gases and preemptive fire conditions to define alert zones. Air Pollution Control of CO2 emissions of factories, pollution emitted by cars and toxic gases generated in farms. Landslide and Avalanche Prevention Monitoring of soil moisture, vibrations and earth density to detect dangerous patterns in land conditions. Earthquake Early Detection Distributed control in specific places of tremors Smart Cities Smart Environment Smart Energy Smart Grid Energy consumption monitoring and management. M2M Applications Machine auto-diagnosis and assets control. Indoor Air Quality Toxic gas and oxygen levels gas levels in chemical plants.
  • 3. 3 mentor.com/embedded 33 SERVICES LAN WAN CLOUD PAN Open fridge – remind me to track food eaten
  • 4. 4 mentor.com/embedded 4 Secure Data, Applications and Services  Secure data storage and transmission — Encryption algorithmic — Cryptography — Network security with both IP Security (IPsec/IKE) and SSL  Enhanced security options through ARM TrustZone® — Secure boot — Secure data storage – secure data storage — Application download/updating — Secure event logging  Secure Lifecycle through US Computer Emergency Readiness Team (CERT) monitoring and patch support  Web service permissions, authorization and validation
  • 5. 5 mentor.com/embedded 5 Security Needs Vary by Application Acute Care Proactive Health Monitoring Fitness Healthy Lifestyle Clinic Hospital ICU Home Care Chronic Disease Management Doctor’s Office Community Clinic Residential Care Assisted Living Skilled Nursing Facility Diagnostics and Therapy Devices and Procedures moving away from Traditional Hospital
  • 6. 7 mentor.com/embedded 7 Security vs. Reliability Negative vs. Positive Goal
  • 7. 8 mentor.com/embedded 8 Threats Faced by IoT Devices  Boot-time Threats — Trust — Authentication  Run-time Threats — User space — Networking
  • 8. 9 mentor.com/embedded 9 Root of Trust Establishing SW / HW Trust 1. Hardware to BootROM 2. BootROM to Operating System 3. Operating System to Application Device Hardware to Boot Boot to OS OS to Application Execution Prevent untrusted OS from launching Prevent untrusted Application from executing Prevent attacks Authorized Access Prevent untrusted boot
  • 9. 10 mentor.com/embedded 10 Boot-Time Authentication  Binary OS image authentication — Did it originate from OEM? — Has it been modified? Memory Nucleus Image
  • 10. 11 mentor.com/embedded 11 Boot-Time Authentication Private Key Public Key SignatureSignature Generation Signature Verification Nucleus RTOS
  • 11. 12 mentor.com/embedded 12 Boot-Time Authentication  Binary OS image authentication — Did it originate from OEM? — Has it been modified? Memory Nucleus RTOS Signature MatchLoad Load
  • 12. 13 mentor.com/embedded First Stage Boot Loader Signature Crypto Key Establishing Root of Trust Second Stage Boot Loader Signature Crypto Key Operating System(s) Signature Crypto Key ARM TrustZone can be used for: • Crypto Key Storage • Signature Generation and Comparison • Signature Storage • Loading OS and Apps App 1 App 2 App NBefore loading any software, ask: • Did it come from the OEM? • Has it been tampered with?
  • 13. 14 mentor.com/embedded 14 Boot-Time Protection Freescale i.MX example  High Assurance Boot (HAB) — Services to ROM to authenticate software that executes immediately after ROM (typically Boot code) — Uses Digital Signatures  Used to authenticate boot code in external memory image prior to execution  Boot modes controlled by fuse setting — NAND, SD/MMC card, EEPROM, USB  HAB library contains functions to authenticate — Authentication based on public keys using RSA algorithm – Signed off line using private keys – Image verified using public keys — Encryption AES-128 Enable Features offered by silicon vendors to provide layered security
  • 14. 15 mentor.com/embedded 15 BootROM to Operating System and App Signature Generation • Hash using SHA-1 • RSA (Rivst-Shamir-Adelman) used for signature generation with manufacturer private key • Signature and product software downloaded into external flash memory SHA-1 ZQ*&@Q310 RSA – private key signature Signature Verification SHA-1 ZQ*&@Q310 RSA – Public Key signature ZQ*&@Q310 Product Software Compare
  • 15. 16 mentor.com/embedded 16 User Space Threats  Memory Protected Modules  Prevents sub-systems from bringing down the system  No virtual addressing  Multiple Types  Application, Libraries, Hybrids  Memory Protection for  Text  Data  Stack  Kernel Isolation Memory Protected Memory Protected Memory Protected Memory Protected File Systems Peripheral Bus Drives GUI Power-aware Kernel StorageLCD Ethernet/ Wireless Devices Memory Protected Application 1 Task 1 Task 2 … Task n Library 1 Function 1 Function 2 … Function n Hybrid 1 Task 1 Function 1 … Task n Function n Application 2 Task 1 Task 2 … Task n Networking
  • 16. 17 mentor.com/embedded 17 Networking Threats  Device Network testing — Tests Devices with millions of attack packets to flood and stress device — Monitor failures in protocol stack and process control functions — Determine the functional health of the device during attack  Types of Tests — Storms – Denial of Service tests that send packages at high rates — Fuzzers/grammars – Invalid packets that do not conform to protocols specifications – Fragmented packets – Overlapping packets or most but not all of packets — Known vulnerabilities – Packets that exploit particular vulnerabilities
  • 17. 18 mentor.com/embedded 1818 Nucleus RTOS for IoT Hypervisor Trusted Execution Environment
  • 18. 19 mentor.com/embedded 19 Security via ARM TrustZone  ARM TrustZone® can be thought of as a hardware-based solution that can be used to define a subset of the SoC for access by software.  Software that is designated as Secure World software has access to ALL of the SoC, while software that is designated as Normal World can access only those HW elements that are defined as ―Non-Secure‖.  Security can be further enhanced via – Trusted boot – Software security through separation
  • 19. 20 mentor.com/embedded 20 ARM TrustZone Worlds Software that runs in the Normal World is assumed to be flawed from a safety and security perspective. This software is expected to contain bugs, exploits, hacks, faults, or irregularities that could expose sensitive information or functions. Secure World applications have complete access to the hardware and resources that are associated with both worlds. TrustZone does nothing to improve the safety or security of the Trusted software itself which must be explicitly tested and independently validated. 1 2 3 4 5 6 7 8 9 * 0 # Secure Element (SecurCore)
  • 20. 21 mentor.com/embedded 21 Secure World Apps run on each core Secure World Apps run on dedicated core ARM TrustZone Configurations
  • 21. 22 mentor.com/embedded 22 ARM TrustZone deficiencies TrustZone includes features that may be helpful to Multi-Core and Multi- OS support, but it alone fails to provide some fundamental capabilities typically required by an embedded system: — No separation of Normal World resources from Secure World — No Separation of multiple, non-Secure Domains — Limited Device Register Data Save/Restore Function A full safe and secure solution needs a combination of hardware and software elements using virtualization!
  • 22. 23 mentor.com/embedded 23 A Solution Approach: Virtualization  Embedded hypervisors — High performance, e.g. runtime and boot time — Strong isolation — Highly robust  Hypervisor Security — Strong isolation and containment of guests — Secure critical information and software  Widespread use of open source software — Embedded Linux gaining widespread adoption — System robustness allowed by separation — IP protection provided through system partitioning RTOS SW Stack 1 SW Stack 2 CPU Core Memory Peripherals Hypervisor CPU Core CPU Core CPU Core RTOS RTOS Bare-Metal
  • 23. 24 mentor.com/embedded 24 ARM TrustZone Environment ARM TrustZone supported features CPU MemoryDevices CPU CPU CPU Hypervisor Mem Dev App RTOS DRM vCPU Device A Device B Memory Memory Normal World Secure World Encryption Secure Boot Key Mgmt Mem Dev App Linux vCPU CPU MemoryDevices CPU CPU CPU Hypervisor Mem Dev App RTOS DRM vCPU Device A Device B Memory Memory Encryption Secure Boot Key Mgmt Mem Dev App Linux vCPU
  • 24. 25 mentor.com/embedded 25 Hypervisor and TrustZone combined Apps Guest kernel & drivers Apps Guest kernel & drivers HypervisorHYP Mode Kernel Mode User Mode Normal World Secure Apps Cortex A15 core(s) TEE Secure World Hypervisor Apps Guest kernel & drivers Apps Guest kernel & drivers Secure Apps TEE Kernel Mode User Mode Normal World Secure World Hypervisor Secure Apps TEE Normal World Secure World User Mode Kernel Mode Cortex A9 core(s) Cortex A9 core(s) Guest kernel & drivers Apps Apps Guest kernel & drivers Combining Virtualization with ARM TrustZone hardware enabled capabilities present in Cortex A9 and A15 cores creates secure and robust application environment.
  • 25. 26 mentor.com/embedded 26 BACKUP SLIDES
  • 26. 27 mentor.com/embedded 27 Hypervisor Normal World Guest 1 Secure World Guest 0 Normal and Secure World interaction Linux App Linux App Requiring Secure World Support Multicore ARM® SOC with TrustZone® Technology MemoryDevices Device A Device B Memory Memory Scheduler Linux Kernel TrustZone Kernel Module TEE Internal API Secure App 1 Cores TrustZone Kernel Module Secure App 2 Secure App 3 Dispatcher Monitor Shared Memory Linux App Linux App Requiring Secure World Support TEE Client API Linux Kernel TEE Client API Kernel Space User Space Hypervisor Space FIQ IRQFIQ IRQ
  • 27. 28 mentor.com/embedded 28 Virtualization: Secure Consolidation CPU MemoryDevices CPU CPU CPU Hypervisor Mem vDev Apps Linux vCPU vCPU Mem vDev Apps Android vCPU vCPU CPU MemoryDevices CPU CPU CPU Hypervisor Mem vDev Apps Linux vCPU vCPU Mem vDev Apps Linux vCPU vCPU CPU MemoryDevices CPU CPU CPU Hypervisor Mem vDev Apps Linux vCPU vCPU Mem vDev Apps RTOS/BM vCPU vCPU Reliably run multiple of the same or different guests
  • 28. 29 mentor.com/embedded 29 List of attacks 29 1 Account lockout attack 2 Asymmetric resource consumption (amplification) 3 Binary planting 4 Blind SQL Injection 5 Blind XPath Injection 6 Brute force attack 7 Buffer overflow attack 8 Cache Poisoning 9 Cash Overflow 10 Code Injection 11 Command Injection 12 Comment Injection Attack 13 Content Security Policy 14 Content Spoofing 15 CORS OriginHeaderScrutiny 16 CORS RequestPreflighScrutiny 17 Cross Frame Scripting 18 Cross Site History Manipulation (XSHM) 19 Cross Site Tracing 20 Cross-Site Request Forgery (CSRF) 21 Cross-site Scripting (XSS) 22 Cross-User Defacement 23 Cryptanalysis 24 CSRF 25 Custom Special Character Injection 26 Denial of Service 27 Direct Dynamic Code Evaluation ('Eval Injection') 28 Direct Static Code Injection 29 Double Encoding 30 Execution After Redirect (EAR) 31 Forced browsing 32 Format string attack 33 Full Path Disclosure 34 HTTP Request Smuggling 35 HTTP Response Splitting 36 Inyección SQL 37 LDAP injection 38 Man-in-the-browser attack 39 Man-in-the-middle attack 40 Mobile code: invoking untrusted mobile code 41 Mobile code: non-final public field 42 Mobile code: object hijack 43 One-Click Attack 44 Overflow Binary Resource File 45 Page Hijacking 46 Parameter Delimiter 47 Path Manipulation 48 Path Traversal 49 Reflected DOM Injection 50 Regular expression Denial of Service - ReDoS 51 Relative Path Traversal 52 Repudiation Attack 53 Resource Injection 54 Server-Side Includes (SSI) Injection 55 Session fixation 56 Session hijacking attack 57 Session Prediction 58 Setting Manipulation 59 Special Element Injection 60 Spyware 61 SQL Injection 62 Traffic flood 63 Trojan Horse 64 Unicode Encoding 65 Web Parameter Tampering 66 Windows ::DATA alternate data stream 67 XPATH Injection 68 XPATH Injection Java 69 XSRF
  • 29. 30 mentor.com/embedded 30 More on Attacks Categories of Attacks 1 7Abuse of Functionality 2 3Data Structure Attacks 3 4Embedded Malicious Code 4 9Exploitation of Authentication 5 26Injection 6 1Path Traversal Attack 7 4Probabilistic Techniques 8 3Protocol Manipulation 9 3Resource Depletion 10 10Resource Manipulation 11 Sniffing Attacks 12 4Spoofing total 74 Types of Attacks 1Access Attacks 2Modification Attacks 3Repudiation Attacks 4Denial of Service Attacks 5Information Theft Embedded Device Attack Vectors Loading valid software on unauthorized device Hacking the boot process to load unauthorized OS + App Hacking the device by loading unautharised App Taking over the device to access data at rest Intercepting communications to access data in transit Uploading malware to prevent device from operating Subjecting device to denial of service attacks to affect its operation Preventing user, device or service authentication
  • 30. 31 mentor.com/embedded 31 Security Framework for End Device 1. Assured data-in-transit protection 2. Assured data-at-rest protection 3. Authentication: 1. User to device 2. User to service 3. Device to service 4. Secure boot 5. Platform integrity and application sandboxing 6. Application whitelisting 7. Malicious code detection and prevention 8. Security policy enforcement 9. External Interface protection 10. Device update policy 11. Event collection for analysis 12. Incident response CESG = UK Government's National Technical Authority Guidance document
  • 31. 32 mentor.com/embedded 32 Hardware Traits of Secure Platform 1. Processor Security Controls Limit Access and can not be Bypassed 2. Direct Memory Access (DMA) is Limited and Controlled 3. DMA from External Devices is Additionally Protected 4. Central Processor Access From Other Processing Elements is Minimized and Controlled 5. Tasks Consuming Platform Resources can be Identified and Controlled 6. Debug Functionality Does Not Compromise Security 7. I/O Control 8. Secure Device Identity 9. Secure Credential Storage 10. Measured/Verified Boot 11. Secure Update/Recovery 12. Control Flow Integrity 13. Security Primitives
  • 32. 33 mentor.com/embedded 33 Communicating with the cloud  Happens via web services.  Multiple protocols in use including HTTP(s), Socket Based, MQTT.  HTTP based Web Services: — Representational State Transfer (REST) — Simple Object Access Protocol (SOAP) — Remote Procedure Call (RPC)  Recommendation: use REST style services — Easy to consume — Easier to implement
  • 33. 34 mentor.com/embedded 34 Authentication versus Authorization  So you get a request from a device with some data in the cloud…  Need to know 3 things: — Identification: Who is sending the data? — Authentication: Are they actually who they say they are? — Authorization: What are they allowed to do?  Identification and authentication go hand in hand.  Authentication is typically necessary, authorization is optional.
  • 34. 35 mentor.com/embedded 35 Authentication Mechanisms  Step 1: Decide on what kind of authentication you will need. This depends on application, and data being stored — User based (example: OAuth login with Facebook) — Device based (API Keys)  Benefits of OAuth: — Better UX: Lesser accounts that the user has to create/ passwords to remember. — Reduced complexity: someone else handles authentication. — Reduced risk: Do not have to store usernames and passwords in your datastores.  API Keys: — API keys are created in the cloud and stored on the device. — API keys are sent with each request to authenticate device.
  • 35. 36 mentor.com/embedded 36 Authentication with API Keys Client Application Internet Cloud Web Service Data Client API Key
  • 36. 37 mentor.com/embedded 37 Authentication with API Keys Client Application Internet Cloud Web Service API Key in header Transmit via HTTPS Data Client transmits data to the cloud
  • 37. 38 mentor.com/embedded 38 Authentication with API Keys Client Application Internet Cloud Web Service API Key in header Transmit via HTTPS Data Client transmits data to the cloud 1. Validate API key sent in request 2. If validated, store data 3. Respond with success HTTP Response 200 OK Client response received
  • 38. 39 mentor.com/embedded 39 Best Practices from a cloud standpoint  Keep web services stateless — Each request from the client has all the necessary information to process the request and session state is held on the device. — Easy to scale and cache requests/responses  Decide on type of authentication up front (User/OAuth/Key based). — Depends on the usecase  Always use HTTPS. — You can encrypt your request with private keys that are understood by the cloud and client, but never sent over the wire.  Send API keys as an HTTP Header. — Put your API keys in the HTTP Headers. Putting these in the URL makes them cacheable and loggable
  • 39. 40 mentor.com/embedded Rugged Software Development  Rugged Software movement began in 2010 as a response to the proliferation of weak and insecure software  Rugged core values: — Repeatable — Limited attack surface — Automated configuration — Control instrumentation built-in  Applicable in cloud and web environments, but also in IoT backend services
  • 40. 41 mentor.com/embedded Generic Backend IoT Architecture Communication Layer Network (wifi, 3g, 4g) API Support Rules and Control Engine Visualization Logging Monitoring Device Mgmt Node A Node B Node n Alerting Applications Mobile Web Node
  • 41. 42 mentor.com/embedded Threats Faced by Cloud Services  The backend services that IoT devices consume can be spoofed  DDOS against cloud services can be used to make IoT devices inoperable  Weak security in multi-tenant environments can expose data and information  General web application security challenges (OWASP)
  • 42. 43 mentor.com/embedded Agile, DevOps and Rugged  Emphasis on testing and monitoring  Treat server infrastructure as code and version control it  Automate tests and integrate with monitoring  DevOps == CAMS (Culture, Automation, Measurement and Sharing)  Use security tools as part of build candidate validation BuildDev Test Deploy Security Testing ~12 mos later
  • 43. 44 mentor.com/embedded Agile, DevOps and Rugged  Emphasis on testing and monitoring  Treat server infrastructure as code and version control it  Automate tests and integrate with monitoring  DevOps == CAMS (Culture, Automation, Measurement and Sharing)  Use security tools as part of build candidate validation BuildDev Test Deploy Security Testing
  • 44. 45 mentor.com/embedded Expressive tooling for Security and Rugged Testing Scenario: Using arachni, look for cross site scripting and verify no issues are found Given "arachni" is installed And the following profile: | name | value | | url | http://localhost:80 | When I launch an "arachni-simple_xss" attack Then the output should contain "0 issues were detected.”
  • 45. 46 mentor.com/embedded 46 Security Strategies for IoT: From Devices to the Cloud Thank you for attending. The archived video of this hangout will be available on this event page shortly. For any questions email us at embedded_software@mentor.com or visit us at http://www.mentor.com/embedded .