Connected Cars & Security Challenges. Stéphane Desneux CTO at IoT.bzh

Transcription

1 Connected Cars & Security Challenges Stéphane Desneux CTO at IoT.bzh Printemps des Entreprises IUT Vannes 15 Mars 2016

2 Agenda IoT.bzh & AGL Project Connected Cars Security: Issues and Solutions Conclusion Q&A 2

3 IoT.bzh & AGL Project 3

4 IoT.bzh Specialized on Embedded & IoT systems Strong Open Source culture Expertise domains: System architecture Security Application Framework Graphics & Multimedia Middleware & Connectivity Linux Kernel Located in Vannes - Brittany, France 4

5 My definition of IoT IoT: acronym for Internet of Things Network of physical objects composed of: Electronics Software Sensors Connectivity Multiple data exchanges with: Operators and final users Object Manufacturer Other local or remote IoT devices Cloud services 5

6 IoT Revolution IoT is hype but the buzz is justified: 2020: 25 to 50 billion objects (Gartner) IoT market will generate around $2000 billion of economic benefits Strong impact in many human activities: Home automation, Domestic appliances Transportation, Storage, Energy Healthcare, Life science, Wearables Financial, Insurance & Legal services... Connected Cars are part of this revolution Many constraints, interactions and domains to cover 6

7 AGL Project Hosted by the Linux Foundation Goal: build a reference Automotive Linux Distribution Open Source project Specifications are open Source code is open Project management is public IoT.bzh works for Renesas (Platinum member of AGL) 7

8 IoT.bzh contributions to AGL Changes on Gerrit 4% 2% 4% 30% 6% 20% 27% Panasonic IoT.bzh Linux Foundation Jaguar Land Rover Denso Qt Company Renesas Microchip Konsulko Mentor Fujitsu-Ten Pioneer Wind River 8

9 Connected Cars 9

10 What is an Automotive system? Homescreen AM/FM radio HVAC control Geolocation Media Player Phone Rear cameras & radars Navigation helper Application manager Driver assistance Diagnostics 10

11 Connected Cars: sensors Many Sensors / Signals to handle Vehicle parameters: engine, transmission, energy, diagnostics as usual GPS IR/Visible spectrum Cameras Radar/Lidar/Microwave/IR/Ultrasound sensors Accelerometers, Gyroscope, Magnetometers (9 DOF chips) Weather sensors... ADAS (Advanced Driver Assistance System) example Toyota ADAS: 11

12 Toyota ADAS <Video Toyota> 12

13 Connected Cars: connectivity Multiple channels 3G/4G Wifi Bluetooth Low energy networks (6LowPAN, SIGFOX )... Example: interaction with passengers devices Ford SDL: 13

14 Ford SDL <Video Ford> 14

15 Connected Cars: services 15

16 Security: Issues and Solutions 16

17 Why Securing Connected Cars? Attacking cars is a viable business Expensive piece of equipment Huge Mass market Enough customers to steal from But attacking cars is complex & expensive, no? Yes, but hackers have both time & money! Betting on hackers lack of skills is a very risky bet One single small security hole might be enough Automotive industry has limited knowledge and return of experience on being connected Car will be Connected & Connected Car will be Attacked 17

18 Security Fundamentals (1) Minimize attack surface area (2) Control the code which is run (3) Provide a bullet-proof update model (4) Apply security patches within days rather than weeks (5) Leverage HW security helpers (6) Isolate & compartmentalize wherever possible (7) Analysis and report of incidents (8) Development and QA with security turned on (9) Provide adequate tools to develop with security enabled (10) Do not rely on humans but on platform 18

19 Security/Complexity Mitigation Security Mechanisms might be short circuit Lack of knowledge Performances Time-to-market Cost concerns Embedded Security Expert is a rare animal 9M Mobile Developers 8M Web Developers 0.5M Embedded Developers How many Embedded Security Developers? Security cannot be added after the fact Must consist in built-in APIs & be transparent to applications Developers SHOULD NOT be in charge of security Baked in from day one: Architecture, Dev, QA, Maintenance,etc. 19

20 Layered Architecture Client/UI (untrusted) Risk of code injection (HTML5/QML) UI on external devices (Mobiles, Tablets) Access to secure service APIs only [REST] Applications & Services (semi-trusted) Unknown developers & Multi-source High-grain protection by Linux UserIDs & SMACK labels Run under control of Application Framework: need to provide a security manifest Platform & System services (trusted) D-Bus Services started by systemd Fine grain privilege provided by Cynara (privileges manager) Part of baseline distribution and certified services only 20

21 Layer/Service Segregation Run services not as root - systemd is your friend Create a dedicated UID per service Use MAC & DAC to minimize open access Drop privileges POSIX privileges MAC privileges Use CGroups Control RAM/CPU/IO Reduce offending power Use Namespaces Limit access to private data Limit access to connectivity Allows containerization 21

22 Need for Resilient Architecture Smart Multi Layers Security Architecture Breaking an application should not break a full layer Breaking a layer should not break the full system Compromised ID/keys are lost for good Per-device unique ID Per-device symmetric keys Use HW ID protection Non-Reproductibility of breakages Breaking in one car should not extend to all models / all cars Dev/Debug I/O, Sockets, should be disabled No Root Password & No shared super-user RSA key Password, when used, should not be easy to compute 22

23 AGL : use SMACK for MAC! Simplified Mandatory Access Control Kernel implemented as a Linux Security Module (LSM) since Safe principle: NO RULE = NO ACCESS and as a consequence: WHAT IS NOT EXPLICITELY AUTHORIZED IS FORBIDDEN! Smack access rules are defined by triplets: Subject Object Permissions Example: The rule ( System User rwx) allows processes running with label System to read, write and execute files with label User 23

24 AGL : Application Framework Contains a Package manager Package Installation Package Uninstallation Package Upgrade Application Lifecycle: Start (Pause Resume) Stop Event & signals propagation Privileges granting & checking API for interaction with applications 24

25 AGL : Action! 25

26 Conclusion 26

27 AGL and IoT Connected Cars are IoT devices AGL can reuse/adopt some methods, mechanisms, protocols and source code coming from generic IoT systems Example: Ostro ( IoT systems may benefit from some base AGL components Security framework Application framework 27

28 Security aspects Strong isolation & compartmentalization are required Untrusted applications should never have direct accesses and should always use intermediate APIs Platform services must be protected with privileges Shortcuts remain possible Services not compatible with a full isolation model can still bypass the security framework while still benefiting partially of it Reduce costs of development Security must be baked into the platform, not added later Developpers shouldn't take care of security Application Framework is a mandatory feature and structuring component. 28

29 Q&A Gulf of Morbihan, south of Brittany, France 29

30 Links IoT.bzh: AGL: Linux Foundation: 30