Trust but verify: Why and how to establish trust in embedded devices Aurélien Francillon
This talk • Introduction • Economic aspects • Why make secure products? • Trust in embedded devices • Verifying trust • Conclusion Aurélien Francillon / Eurecom 2 Mar 17, 2016
Introduction • This talk: a “consequence” of about 10 years of working on the security of embedded systems software • Practical approach • Attacking systems • Analysing systems (real products) • Developing new security mechanisms to make software more secure • Unfortunately • A lot of this “systems security” knowledge is not public • Why is it so often so bad ? Aurélien Francillon / Eurecom 3 Mar 17, 2016
Problems found in a large scale analysis • Analysed ~30000 Firmware images • Hard-coded passwords, SSL keys… • SSL private keys which are used by 40,000 IP on the internet... • Same vulnerabilities across difgerent products • Code sharing, Vulnerability sharing • Several hundreds of vulnerable fjrmware images… tens of CVEs • Web analysis: Many basic problems Automated Dynamic Firmware Analysis at Scale: A Case Study on Embedded Web Interfaces A. Costin, , A. Zarras, A. Francillon AsiaCCS 2016 A Large Scale Analysis of the Security of Embedded Firmwares A. Costin, J. Zaddach, A. Francillon, D. Balzarotti, Usenix Security 2014
Security for the 99% • There are some very secure devices • Smartcards, HSMs, ... • Not fmawless but with a reasonable level of security • This is “1%” of the devices Aurélien Francillon / Eurecom 5 Mar 17, 2016
Security for the 99% • There are some very secure devices • Smartcards, HSMs, ... • Not fmawless but with a reasonable level of security • This is “1%” of the devices • The remaining 99% is not • Soho equipment • Computers peripherals • (Some) Industrial systems, etc. • Security for the 99% ? Aurélien Francillon / Eurecom 6 Mar 17, 2016
An economic problem • Intuitively security requires an extra efgort • Costs money • Customers may not want to pay for it A bit more complicated… • Anderson / Schneier “economics of security” • Security an externality: • Manufacturer often not responsible for operating the device • No direct loss in case of breach • So “why bother with security” Aurélien Francillon / Eurecom 7 Mar 17, 2016
Market for Lemons or silver bullets? • Markets with asymmetric information • Market for Lemons: Used car market (Akerlof) • When selling a product seller knows more, buyer less • This drives down the average price of an used car • Security products: Both seller and buyer lack information (Grigg) • Spafgord: how to test a unicorn detection device? • Market for silver bullets • Security products v.s. Product security • Product security is a lemons' market Aurélien Francillon / Eurecom 8 Mar 17, 2016
Motivations for trust/security on Manufacturers' side Security considered when: • There are active attacks on asset to protect • Conditional access for Pay TV • Actual goal is to resist to the attacks • Must not fail • E.g., critical military system • No need to be profjtable • Regulations, standards, certifjcations to pass • ID documents, payment processing • Actual goal is to get the certifjcation • For the 99% ? Aurélien Francillon / Eurecom 9 Mar 17, 2016
Economically speaking: Security or not? • In the short term, probably no... • Time to market, Cost • Users wants features Schneier: “Any smart software vendor will talk big about security, but do as little as possible, because that's what makes the most economic sense.” • In the long term • A big problem • Maintenance, legacy, users defjance • Costs can be higher than the initial development • Life Cycle (How long will the manufacturer support it?) Aurélien Francillon / Eurecom 10 Mar 17, 2016
Transparency v.s. security • Kerckhofgs 2nd design principle: • “... It should not require secrecy, and it should not be a problem if it falls into enemy hands” • Often interpreted as: • “if the system is not open and does not receive public scrutiny then it is not secure” • Or ”Security by obscurity is bad” • A wrong interpretation • Hiding the system details is actually making attacks much harder • Many more factors • However, this has other bad efgects... Aurélien Francillon / Eurecom 11 Mar 17, 2016
Small digression... • One day I was given old scope for free to play at home... • It worked 5 minutes and then the Magic Smoke escaped... Aurélien Francillon / Eurecom 12 Mar 17, 2016
Small digression... Tektronix 2445 Service manual 330 pages
Aurélien Francillon / Eurecom 14 Mar 17, 2016
In the “good old days”... • Before there was documentation for: • Mini computers, • Apple II • Today datasheets often not available, even for: • Raspberry PI • Intel Edison • Any secure device Aurélien Francillon / Eurecom 18 Mar 17, 2016
Trust and transparency • To trust something we need to • Blindly trust? • Verify it, inspect it? • Asymmetric market • Manufacturer knows • Customer cannot evaluate security • Lack of transparency damages market of secure devices, users cannot: • Educate themselves • Learn about security • Evaluate security • Compare devices • How could they want to pay more for security? Aurélien Francillon / Eurecom 19 Mar 17, 2016
Lack of transparency • Basic security measures often make them less transparent • Makes third party audit very hard • But does not mean the device is secure… • Secrecy leads to suspicion • What is the device doing with my data? • Trying to hide a poor level of security? • Something nasty to hide? Aurélien Francillon / Eurecom 20 Mar 17, 2016
From an actual smartphone chip • Dumped a bootloader in Mask ROM • No FBI, it's not an iPhone! Aurélien Francillon / Eurecom 21 Mar 17, 2016
Security or lock out • Who is in control of the device • Your Manufacturer? • Your government, another one? • Trusted Computing as “Treacherous Computing” (R. Stallman) • Users should eventually be in control Aurélien Francillon / Eurecom 22 Mar 17, 2016
Design problem We need systems to be designed for: • User Trust • Letting the choice to the user, owner of the device to which software is running on the device • Let the user know which software it is running • Security Analysis • We need to be able to independently inspect those systems Aurélien Francillon / Eurecom 23 Mar 17, 2016
Design for User Trust • To trust the systems, users needs to: • Know what is running • Chose what can be running • Be in control • Be able to verify • Currently there are devices which • We can control, but have zero security (e.g., unlocking android) • Are secure but under the control of someone else (iPhone) Aurélien Francillon / Eurecom 24 Mar 17, 2016
Design for User Trust: examples • My new laptop • Has an UEFI Firmware • Loaded with my own keys • Secure boot, only code I signed • Joanna Rutkowska proposal of a state- less laptop • Without R/W memories • All fjrmware loaded from an external, trusted, device Aurélien Francillon / Eurecom 25 Mar 17, 2016
Design for Security Testing • When do we really need to be able to analyse embedded devices? • Each fjrmware version Detect vulnerabilities • Each independent device Shipped with bad FW • Regularly Check for compromise • Exceptionally Forensics • Need for independent analysis • Requires some access to the device (DFUT) • But not reducing the security of the device… Authenticate users? Aurélien Francillon / Eurecom 26 Mar 17, 2016
Design for Security Testing • Currently fjrst security measures in an embedded system makes it harder to test: • Locking JTAG • Encrypt/Sign code • Testing embedded systems is diffjcult We developed a tool for security testing • Avatar http://s3.eurecom.fr/tools/avatar/ Aurélien Francillon / Eurecom 27 Mar 17, 2016
In Summary • We need more transparency • Datasheets! • Access to debug ports! • Not because it makes devices more secure but it makes: • Auditable • Trustworthy • Forensics possible • We need mechanisms that • Put users in control • Do not introduce new vulnerabilities • Are easy to integrate in products Aurélien Francillon / Eurecom 28 Mar 17, 2016
Questions?
Backup slides
Liability • Schneier argues for liability • Did not happen… will it one day? • Probably in some regulated / life threatening markets? • Toyota sudden unintended acceleration • 9 Million cars recalled • 37 deaths alleged • Will this occur for the 99%? • I guess not Aurélien Francillon / Eurecom 31 Mar 17, 2016
Hard disk drive security • A disk Drive runs a fjrmware • with its own OS • Can be updated • Could be compromised • what would be the consequences ? • The required efgort • To discover it we did it • Took a disk and reverse engineered it • designed a backdoor • So yes, feasible but diffjcult, but a few days later... Implementation and Implications of a Stealth Hard-Drive Backdoor J. Zaddach, A. Kurmus, D. Balzarotti, E. Blass, A. Francillon, T. Goodspeed, M. Gupta, I. Koltsidas, best student paper award, ACSAC 2013,
IRATEMONK (12/2013)
Recommend
More recommend
