IOT SECURITY SOFTWARE SOLUTIONS DANNY DE COCK 22 September 2015 - PowerPoint PPT Presentation

IOT SECURITY SOFTWARE SOLUTIONS DANNY DE COCK 22 September 2015 SENIOR RESEARCHER HTTP://GODOT.BE/SLIDES

STANDARD CRYPTO-TECHNICAL CONSIDERATIONS  IOT = big data, focused on functionality, not security  Security is afterthought  Each family of devices works in its own silo, aggregation rather than integration  User data, preferences, behavior stored in the cloud  Who manages the cloud, who is it and where can you find them?  Devices push data out automatically to meet user expectations and convenience  Location privacy, behavior patterns, backups, contact lists  No transparency to end-user wrt access to company/private data  Authentication, confidentiality and authorization problems  Low power = lightweight communications and security protocols  Silo- based management of keys, preferences, access control settings… 22/09/2015 2

SO, WHAT IS THE PROBLEM?   IoT device not different from any other IT device  Communicates with its surroundings  Firmware, operating system, applications, application data, user data, configurations  What makes IoT different  Restrained resources  Not continuously online  Many different versions in the field  Very short time-to-market  Users are Guiney pigs rather than users of well tested devices  High number of devices compete for limited network resources  Wifi, Bluetooth, ZigBee, Z- Wave…  Operation conditions are complex and fragile  Just too many devices and more are coming  22/09/2015 3

‘‘OUR SYSTEM IS SECURE: WE USE THE AES’’  What about  Key management & life cycle  ‘‘Random’’ keys?  Authenticated (?) key agreement  Implementation  Modes of encryption, initialization vectors,…  Attacking the implementation  Who holds the keys?  Who can use the keys?  Stored in the clear?  Key archives? 22/09/2015 Slide 4

HIGH-LEVEL RISKS (1/2)  Focus on  Functionality – better & earlier than the competition  Commercial interest – user is no longer owner of its data  Struggle with  Reliability of the devices  Stability of the applications  Interoperability with other devices 22/09/2015 5

HIGH-LEVEL RISKS (2/2)  Forget/ignore/neglect  Privacy related issues  Collecting all possible data without informing users correctly and beforehand  Inappropriate use of information `it is available anyhow, so why not use it?`  Integrity protection of data transferred and stored  Access control to IoT device, online services, user data, configuration data…  Happy when it works  Do not touch/reconfigure a working system   Limited management of keys, algorithms, protocols, credentials…  Backward compatibility constricts deployment of secure environments 22/09/2015 6

IT’S ALIVE! AND WE LOST IT!  Networked devices  Automated data push to the cloud – sensor states, control statuses, user data…  Frequent system updates and upgrades  Flooding off the shelve (home) wireless access points  Lower- power Bluetooth, ZigBee… hubs  Devices get controlled remotely – who controls what?  Botnet-inspired command and controlled push of commands from the Cloud  ET phones home: fetch instructions from mother station 22/09/2015 7

REAL DANGER – OPEN SESAME  Third party’s benefit  Hacking/infecting remote control points  Very similar to botnet activities  Compromised meta-controller, e.g.,  Can provide full access to critical control points  Enables perfect burglary  Break-in & entry without signs of break-in!  Compromised device manufacturer’s control points  Alien firmware, Trojan behavior of *all* devices  Self-benefit  Current state of the art allows fabrication of alibi   Fake presence at home  Mimic normal behavior remotely Disclaimer: not claiming the pictured items/service providers have been compromised already  22/09/2015 8 Images: http://www.sevenoaksart.co.uk

WHAT TO DO ABOUT IT? (DESIGN/DEVELOP VIEW)  During design of IoT devices and services:  Enable & use robust version and update control from the initial start:  Firmware, operating system, application, application modules, device drivers  Key material, set of trusted references: keys, certificates  Avoid transporting and saving plaintext data to the cloud  Enable decent user and system authentication & authorization  Special focus on user friendliness & user convenience  Similar to TPM initialization: master and normal user  Good system design relies on embedded security  Simplifies security issues: no add-on  During use:  Guarantee interoperability with older versions  Discard support of older versions when *ALL* older versions have upgraded  Inform users correctly and completely when changing data collection policy 22/09/2015 9

WHAT TO DO ABOUT IT? (USER VIEW)  Apply well known network segregation:  Demilitarized zones & self-controlled security gateways!  During configuration of intelligent devices  Prepare separate networks from normal network with Internet access  Use different settings to initialize/configure devices/services and to use devices/services  After configuration  Disable Internet access of critical intelligent devices – power consumers, physical & logical entry points  Disable automated update functionality to avoid unwanted/uncontrolled service disruption 22/09/2015 10

CLOSING REMARKS  Use of Today’s IoT devices provide  No privacy guarantees whatsoever  Fake belief you are in control  New business opportunities for  IoT system aggregators  IoT system installers and configurators  About home automation  Not to be used for safety and security critical systems  22/09/2015 11

QUESTIONS?  Contact details:  Email: Danny.DeCock@esat.kuleuven.be  Slides: http://godot.be/slides 22/09/2015 12

GOOD PRACTICES  Centralize security knowledge in software architects and application designers  Implementers should not have to make delicate security decisions  Cryptographic algorithms and protocols should be considered as modular building blocks  Consistent deployment of a security vision saves time and money  Security expertise concentrated in a few of the most trusted members of the development organization  Allows for better depth of knowledge  Results in more effective and secure results  Good initial security design avoids hard to solve security issues  Security patches do not deal with inherent design flaws  Simple design is easily understandable/testable/auditable 22/09/2015 Slide 13

TH@NK YOU! ANY QUESTIONS? 22/09/2015 Slide 14