Download as PDF, PPTX
![7/21
Know who/what you trust
➢ Trusted Boot : a MUST Have Feature
➢ Leverage hardware capabilities
➢ Small series & developer key handling
➢ Application Installation
➢ Verify integrity
➢ Verify origin
➢ Request User Consent [privacy & permissions]
➢ Update
➢ Only signed updates with a trusted origin
➢ Secured updates on compromised devices are a no-go option
➢ Factory reset built-in from a trusted zone
➢ Do not let back doors opened via containers
➢ Strict control of custom drivers [in kernel mode everything is possible]](https://image.slidesharecdn.com/20161122-dominig-v1-161125095555/75/Implementing-a-Security-strategy-in-IoT-Practical-example-Automotive-Grade-Linux-LibreCon-2016-7-2048.jpg)
![8/21
Layered Architecture
➢ Client/UI (untrusted)
➢ Risk of code injection (HTML5/QML)
➢ UI on external devices (Mobiles, Tablets)
➢ Access to secure service APIs [REST/WS]
➢ Applications & Services (semi-trusted)
➢ Unknown developers & Multi-source
➢ High-grain protection by Linux DAC & MAC labels.
➢ Run under control of Application Framework: need to provide a
security manifest
➢ Platform & System services (trusted)
➢ Message Services started by systemd
➢ Service and API fine grain privilege protection
➢ Part of baseline distribution and certified services only](https://image.slidesharecdn.com/20161122-dominig-v1-161125095555/75/Implementing-a-Security-strategy-in-IoT-Practical-example-Automotive-Grade-Linux-LibreCon-2016-8-2048.jpg)
![12/21
Segregate Apps from OS
➢ Application Manager
➢ One system daemon for application live cycle installs, update, delete
➢ One user daemon per user for application start, stop, pause, resume
➢ Create initial share secret between UI and Binder
➢ Spawn and controls application processes: binder, UI, …
➢ Security Manager
➢ Responsible of privilege enforcement
➢ Based on Cynara + WebSocket and D-Bus for Legacy)
➢ Application & Services Binders
➢ Expose platform APIs to UI, Services, Applications
➢ Loads services/application plugins :Audio, Canbus, Media Server…
➢ One private binder per application/services [REST, WebSocket, Dbus]
➢ Authenticate UI by oAuth token type
➢ Secured by SMACK label + UID/GIDs
➢ AppBinders runs under user $HOME](https://image.slidesharecdn.com/20161122-dominig-v1-161125095555/75/Implementing-a-Security-strategy-in-IoT-Practical-example-Automotive-Grade-Linux-LibreCon-2016-12-2048.jpg)
Uploaded byLibreCon
Implementing a Security strategy in IoT, Practical example Automotive Grade Linux - LibreCon 2016
This document discusses implementing security strategies for IoT devices. It outlines some risks of attacks on IoT devices, such as ransomware attacks. It recommends fundamentals for security like minimizing surfaces of attack, controlling what code runs, and providing bulletproof update models. It provides an example of implementing security on Automotive Grade Linux and discusses concepts like trusted boot, isolation of services and applications, identity management, and secure updates.
More Related Content
Similar to Implementing a Security strategy in IoT, Practical example Automotive Grade Linux - LibreCon 2016
Implementing a Security strategy in IoT, Practical example Automotive Grade Linux - LibreCon 2016
- 1. 1/21 Dominig ar Foll SeniorSoftware Architect Intel Open Source LibreCon 2016, Bilbao, Es [email protected] Implementing a Security strategy in IoT, Practical example Automotive Grade Linux
- 2. Attacking IoT, aviable business ➢ Ransom model ➢ Stall manufacturing ➢ Immobilise expensive items (e.g. your car) ➢ … ➢ Competitive advantage ➢ Collecting R&D, manufacturing data ➢ Disturbing production line ➢ Indirect ➢ Cheap robot for DDoS ➢ Easy entry point
- 3. 3/21 Understanding the risks Developer Fixall possible weaknesses Deactivate possible users errors LTS assumed for free Back Hat Only need one security hole Can be help by careless users Good long term business opportunities Good international network
- 4. 4/21 Security fundamentals Minimise surfaceof attack Control the code which is run Provide a bullet proof update model Track security patches Use HW security helpers when available Limit lateral movement in the system Develop and QA with security turned on Do not rely on human but on platform and tools Security cannot be added after the fact
- 5. Do not relyon human ➢ Security experts are out of reach ➢ 9M Mobile Developers ➢ 8M Web Developers ➢ 0.5M Embedded Developers ➢ How many Embedded Security Developers ? ➢ Human are unreliable ➢ We do not have the time now ➢ Oups, it’s too late to change it ➢ No one is interested by our system ➢ We are too small ➢ ...
- 6. 6/21 Concepts are Known butwhat about implementation? EPID ID Management EPID ID Management TPM Private/Secure Store TPM Private/Secure Store UEFI Secured Boot UEFI Secured Boot Linux Kernel with up-to-date patchesLinux Kernel with up-to-date patches SoC Specific drivers Harden OS servicesHarden OS services Mandatory Access Control Integrity Name Space Firewall Safe update Encryption ID/Key protection APIAPI Untrusted Apps / MiddlewareUntrusted Apps / Middleware Full isolation Signing Repo create Debug Customize SoC Drivers Signing Repo create Debug Customize SoC Drivers Default policies Debug Sample code HowTo Default policies Debug Sample code HowTo AppFW App Debug App Packaging AppFW App Debug App Packaging Tools-DocTools-Doc Software running onTargetSoftware running onTarget
- 7. 7/21 Know who/what youtrust ➢ Trusted Boot : a MUST Have Feature ➢ Leverage hardware capabilities ➢ Small series & developer key handling ➢ Application Installation ➢ Verify integrity ➢ Verify origin ➢ Request User Consent [privacy & permissions] ➢ Update ➢ Only signed updates with a trusted origin ➢ Secured updates on compromised devices are a no-go option ➢ Factory reset built-in from a trusted zone ➢ Do not let back doors opened via containers ➢ Strict control of custom drivers [in kernel mode everything is possible]
- 8. 8/21 Layered Architecture ➢ Client/UI(untrusted) ➢ Risk of code injection (HTML5/QML) ➢ UI on external devices (Mobiles, Tablets) ➢ Access to secure service APIs [REST/WS] ➢ Applications & Services (semi-trusted) ➢ Unknown developers & Multi-source ➢ High-grain protection by Linux DAC & MAC labels. ➢ Run under control of Application Framework: need to provide a security manifest ➢ Platform & System services (trusted) ➢ Message Services started by systemd ➢ Service and API fine grain privilege protection ➢ Part of baseline distribution and certified services only
- 9. 9/21 Bullet proof updateand ID Update is the only possible correction l Must run safely on compromised devices l Cannot assume a know starting point Compromised ID / keys has no return l Per device unique ID l Per device symmetric keys l Use HW ID protection (e.g. EPID) Non reproducibility l Breaking in one device cannot be extended l Development I/O are disabled l Root password is unique (or better a key) l Password cannot be easily recalculated
- 10. 10/21 A practical example(AGL) Applicable to any Industrial IoT Linux
- 11. 11/21 Service isolation Run serviceswith UID<>0 SystemD is your friend l Create dedicated UID per service l Use Linux MAC and Smack DAC to minimise open Access Drop privileges l Posix privileges l MAC privileges C-goups l Reduce offending power l RAM/CPU/IO Name Space l Limit access to private data l Limit access to connectivity https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt https://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt http://man7.org/linux/man-pages/man7/namespaces.7.html https://en.wikipedia.org/wiki/Mandatory_access_control https://en.wikipedia.org/wiki/Discretionary_access_control
- 12. 12/21 Segregate Apps fromOS ➢ Application Manager ➢ One system daemon for application live cycle installs, update, delete ➢ One user daemon per user for application start, stop, pause, resume ➢ Create initial share secret between UI and Binder ➢ Spawn and controls application processes: binder, UI, … ➢ Security Manager ➢ Responsible of privilege enforcement ➢ Based on Cynara + WebSocket and D-Bus for Legacy) ➢ Application & Services Binders ➢ Expose platform APIs to UI, Services, Applications ➢ Loads services/application plugins :Audio, Canbus, Media Server… ➢ One private binder per application/services [REST, WebSocket, Dbus] ➢ Authenticate UI by oAuth token type ➢ Secured by SMACK label + UID/GIDs ➢ AppBinders runs under user $HOME
- 13. 13/21 AGL2 Application Security Agent-2 CarEnvironement Agent-3 Engine Agent-4 Remote Signal CAN Bus-A LIN Bus-A Audio CAN Bus-B Cluster-Unit ... Smart City RVI Cloud Transport + Acess Control Navigation Service Carte handling POI management etc... Log/Supervision Service Carte handling POI management etc... MultiMedia Service Media Player Radio Interface etc... Distributed Application Architecture MAC Enforcement Smack Cgroups NameSpace Containers Application Framwork Live Cycle Management Start,Stop,Pause,Install,Remove,...
- 14.
- 15. 15/21 To write anApp ➢ Write back-end binding ➢ Adds the specialised API to the system ➢ Accessible by Web Socket or slow legacy D-Bus ➢ Run in its own security domain ➢ Can be cascaded ➢ Write the Front end ➢ Typically in HTML5, QML but open to any ➢ Connect to back-end binding using REST with secured key (OAuth2) ➢ ➢ Package ➢ Based on W3C widget ➢ Feature allow to handle AGL specificities ➢ Install via the AppFW
- 16. 16/21 AGL2+ Distributed Architecture Cluster Cartehandling Localistion management POI CAN GPS Geopositioning Virtual Signal Multi ECU & Cloud Aware Architecture Entertainement CAN-BUS Virtual Signal Gyro, AcelerometerCAN-BUS LIN-BUS Engine-CAN-BUS ABS Transport & ACL Head Unix Direction Indication Cloud Log Analytics No-SQL Engine Statistics & Analytics Transport & ACL My Car Portal Paiement Subcriptions Preference Preferences & Custumisation MongoDB Engine Paiement Service Cluster Virtual Signal Transport & ACL Navigation Service Maintenance Portal Know Bugs Maintenances Service Packs
- 17. 17/21 AGL2++ Virtualised Architecture Hardware Trusted Zone Hypervisor MorePrivilegesLessPrivileges AGLLinux Kernel Guest Operating Linux-RT/Microkernel Guest Operating AGL Core Plateform Services AGL Extra Middleware AGLApp-1 AGLApp-2 AGLApp-3 DomU Entertainment App-1 App-2 AGL Mini Plateform Services DomU Cluster Trusted Apps AGL Linux Supervisor PKIsafeStore Integretycontrol Ressources Alloc/Porxy Emergency Services Trusted Boot DOM0 controller Virt GPU Virt Audio Virt GPU Virt Audio Diagnistics Virtualized Secure Architecture Container
- 18. 18/21 Conclusion ➢ Technologies areavailable ➢ Secure boot, Secure zone ➢ Update over the air ➢ Isolation and containment ➢ Tools and training ➢ Management is not ready ➢ Still perceived as a nice to have ➢ Too risky to commit ➢ Engineering sees security as a brake to innovation ➢ Requires a serious personal investment and paradigm shift ➢ Complexity imposes to select a “Ready Made” solution ➢ AGL, Tizen, Snappy, ... ➢ “Will add it later” attitude is common but a guaranteed model to failure
- 19. Questions LibreCon 2016, Bilbao,Es [email protected] Golfe Morbihan, South Brittany
- 20. 20/21 Container "A mixedblessing" Easy to use l Detach the App from the platform l Integrated App management l Well known Not very secure l Unreliable introspection l MAC has no power on the inside of a container l Updating the platform does not update the l middleware l Beside the Kernel each App provide its own version l of the OS l Each App restart requires a full passing of credential l RAM and Flash footprint are uncontrollable l Far more secured with Clear Container but not applicable to low end SoC. Only I/O via network l Well equipped for Rest API l All other I/O requires driver level access or bespoke framework. https://www.opencontainers.org/ https://lwn.net/Articles/644675/
- 21. 21/21 Security Check list Controlwhich code you run l Secure boot l Integrity l Secure update Isolate services l Drop root when possible l Drop privileges Isolate Apps l Apps are not the OS l Enforce – restrict access to standard API Identity l Enforce identity unicity l Use available HW protection Encryption l Network traffic l Local storage Control image creation l No debug tool in production l No default root password l No unrequired open port Continuous integration l Automate static analysis l QA on secured image Help developer l Integrate security in Devel image l Provide clear guide line l Isolate Apps from OS l Focus on standardised Middleware