SECURITY OF SMART METERS.
ETSI Security workshop. IoT thematic stream
Olivier ROCHON ITRON CTO SECURITY TEAM
24th June 2015
Presentation lay-out
• The threats landscape in smart grid/smart metering
• Attacks against smart meters
• Attack techniques and tools applicable to smart meters
• Mitigation strategy: applying the SDL methodology throughout the development and testing process
• Lessons learned and best security by design practices
3
THE THREATS LANDSCAPE
FOR THE SMART GRID & METERING
© 2010 ITRON INC.
Evolution of threats
• Key findings:
– Surge in point-of-sale (POS) malware and attacks;
– Dramatic increase in Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encrypted Internet traffic;
– And twice the attacks on supervisory control and data acquisition (SCADA) systems
• Buffer overflow vulnerabilities continue to be the primary attack method, accounting for 25% ofthe attacks.
Source Dell Security Annual Threat Report 2015
The energy sector is targetted
• Hacking knowledge of electronic devicesembedding firmware is widely available
– TV boxes, video game consoles, Oyster cards, votingmachines, ATMs… have been hacked and are continuously attacked
• New sophisticated threats are emerging and targetthe Smart Grid, Critical Infrastructures and Industrial Systems at a large scale
– StuxNet, Gauss, Flame …
5
Attacks against Smart Meters are likely to spread
ATTACKER TACTICS AND TOOLS
General attacker’s strategy1. Reconnaissance
2. Scanning
3. Exploit
– Gaining access
– Denial of service
4. Keeping access
– Backdoor, Rootkit, RAT
5. Covering the tracks
8
Common hardware attacks• Device tear down
– Identify main chips and peripherals
– Search for datasheets
– Trace PCB and connections betweendevices
– Identify purpose of chips
– Find serial and debug i/f:
• JTAG, SWB, UART, I²C
• Try to obtain firmware image
from internet
• Dump memories (serial flash)
Extracting data from memory
• Firmware images can be reverse engineered
– To figure out how the deviceworks
– To finds secrets such as keys and passwds
– To discover vulnerabilities in the code• Buffer overflows
• Integrer overflows
• Session problems
• Crash Dumps can disclose
– Sensitive data on the application
– Keys and passwords
Dumping internal memories
Equipement used:
• An unlocked smart meter• A BUS Pirate board(http://dangerousprototypes.com/docs/Bus_Pirate)
• openocd on chip debugger (http://openocd.org/)
• Kali pen test distro (https://www.kali.org/)
• The memory contents isdumped
• Keys can be identified after an entropy analysis
• Any binary code can bedecompiled, and reverse-engineered
Reverse engineering codeIDA-PRO and binwalk are magic tools!
• An entropy analysis finds
secrets such as keys and
passwds
• Ida-Pro allows to discover
vulnerabilities in code
– Buffer overflows
– Integrer overflows
– …
WHAT CAN WE DO ABOUT THIS?
What to do about it?
• Keep aware of APTs and security incidents
• Apply security by design rules
– Security Development Lifecycle (SDL)
– Hardening devices
• Run security pen testing
– Use tools and techniques for improving securityevaluation at affordable cost
APPLYING SDL
SDL at Itron
• Corporate initiative started in 2011
• Chosen from Microsoft but taylored for embedded
• Adopted tools for code scanning/review
– Fortify 360 (.NET)
– Coverity
– CodeSonar
• Integrated SDL phases into development process
– Common development process
– Tried to minimize disruption
• SDL in hardware development
17
SDL Methodology
Analyse device architecture, access points and data flows
Apply all possible attacks to all access points
Evaluate and rank the effects of the attacks
Define defensive counter measures for all major security issues
Implement the counter measures in the design
Perform security pen tests
Iterate from top – things evolve!
(Security development lifecycle)
“Whenever you build a new system you should consider how an intruder might
go about attacking it and then build in appropriate defences at design time.”
Microsoft.
The Process - 1
• First, threats must be identified (who):– Hacktivist
– Insiders
– Organised crime
• Then potential vulnerabilities (what)– Physical meter
– Switch
– Metrology parameters
– Firmware
• Then possible attacks (how)– Break meter
– Turn switch off
– Modify metrology
– Change f/w
A quick reminder...
Organised crime
Petty theft
Extortion
Terrorism
Virus/Trojan/Root-Kit
Hacking
By-passing
Magnetic
Comms break
MotivationFundingResources
Equipment / ToolsExpertise / SkillKnowledge
Equipment / ToolsExpertise / SkillKnowledge
The Process – 2
• Rating / Ranking
– How to rate/rank vulnerabilities?
– Vulnerabilities have to be:
• Quantifiable
• Scorable
• Objective
– DREAD Model (as was used at Microsoft)
Risk = Vulnerability * Probability
Damage potentialReproducabilityExploitabilityAffected usersDiscoverability
The DREAD Model
D = damage
R = reliability
E = exploitability
A = affected users
D = discoverability
D
R
E
A
D
Example
Threat Rating Stride Property
Attacker learns passwords by monitoring network traffic
7 High Information Disclosure Confidentiality
Attacker injects SQLcommands injected into application
9 High Spoofing Authentication
Attacker learns keys by examining meter memory
5 Medium
Information Disclosure-> Elevation of Privilege
Confidentiality -> Authorisation
Attacker changes tariffs by editing memory
7 High Tampering Integrity
Attacker changes firmware todisable remote disconnect
7 High Denial of Service Availability
Quantifying furtherthe security risk with ‘FAIR’*
• FAIR: Factor Analysis of Information Risk
– Complements DREAD
– Framework for measuring and analysing information risk
– What direct / indirect min./.max monetary losses an organisation will incur if a capable threat successfully attacks an asset exploiting vulnerabilities?
*A FAIR Approach. J Freund | J Jones ISBN978-0-12-420231-3
HARDENING SMART METERS
General rules for hardening
• Bury important PCB tracks into layers
• Use BGA if possible (harder to tap and desolder)
• Put epoxy on top of chip
• Don't connect JTAG, serial or debug ports
• Use chips with internal memories whenever possible
• Obfuscate labels
BEST SECURITY PRACTICES
Best security practices –Design of products
• Don’t trust seals!
• Don’t ship devices with unlocked JTAG
• Encrypt sensitive data at rest
• Protect the integrity of critical data / parameters. – A CRC or a Hash is not sufficient
• Remove any Factory mode, Test Mode or Debug mode
• Don’t hard code security keys
• Don’t design your home grown crypto-algorithms
• Use unique keys per device
• Encrypt and sign binary code used for OTA upgrade
• Implement a secure bootloader