Securing wireless neurostimulators Eduard Marin, Dave Singelée, Bohan Yang, Vladimir Volskiy, Guy Vandenbosch, Bart Nuttin and Bart Preneel imec-COSIC, KU Leuven, Belgium ESAT-TELEMIC, KU Leuven, Belgium Neurosurgery, UZ Leuven, Belgium 1 CODASPY 2018 March 19-21, Tempe, US
21
Embed
Securing wireless neurostimulatorsemarin/CODASPY2018.pdfSecuring wireless neurostimulators Eduard Marin, Dave Singelée, Bohan Yang, Vladimir Volskiy, Guy Vandenbosch, Bart Nuttin
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Securing wireless neurostimulators
Eduard Marin, Dave Singelée, Bohan Yang, Vladimir Volskiy, Guy Vandenbosch, Bart Nuttin and Bart Preneel
imec-COSIC, KU Leuven, Belgium
ESAT-TELEMIC, KU Leuven, Belgium
Neurosurgery, UZ Leuven, Belgium
1
CODASPY 2018
March 19-21, Tempe, US
2
Neurostimulation system
3
NeurostimulatorDevice
programmer
Commands
Medical data
Short-range channel (< 10 cm)
Laboratory setup
• Device programmers
• Neurostimulators
• NI DAQ USB-6341
• Antennas
• Standard laptop
• LabVIEW
4
Security analysis
• Proprietary protocol
• Reverse engineering
• Black-box approach
5
Device
programmer
Black-box reverse engineering
6
Change patient’s name to AAAA
Change patient’s name to AAAB
101010 101010 101010 101010
101010 101010 101010 101011
Black-box reverse engineering
• Discover the wireless communication parameters
• Transmission frequency
• Modulation and encoding schemes
• Symbol rate
• Capture and analyze messages sent by the devices
7
Security findings
• No cryptography
• Vulnerable to replay attacks
8
Attacks on neurostimulators
• Privacy attacks
• Replay attacks
• DoS attacks
• Spoofing attacks
9
NeurostimulatorDevice
programmer
Limitations:
- Adversary needs to be close to the patient
Attacks on neurostimulators
• Privacy attacks
• Replay attacks
• DoS attacks
• Spoofing attacks
10
NeurostimulatorDevice
programmer
Limitations:
- Adversary needs to be close to the
patient
- Adversary needs to wait until there is
an ongoing communication
- Adversary can only replay messages
that were already transmitted
Attacks on neurostimulators
• Privacy attacks
• Replay attacks
• DoS attacks
• Spoofing attacks
11
NeurostimulatorDevice
programmer
Limitations:
- Adversary needs to be close to
the patient
Attacks on neurostimulators
• Privacy attacks
• Replay attacks
• DoS attacks
• Spoofing attacks
12
Neurostimulator
Limitations:
- Adversary needs to be close to
the patient
- Adversary requires to know the
neurostimulator’s SN
Attacks on neurostimulators
• Privacy attacks
• Replay attacks
• DoS attacks
• Spoofing attacks
13
Neurostimulator
Limitations:
- Adversary requires to be close to the
patient
What if SN field is empty?
Distance could be extended up to 1 meter approximately
What makes security of IMDs unique?
• Resource-constrained devices
• Lack of input and output interfaces
• Cannot be physically accessed
• Several tensions between security goals and functional requirements• Security vs open-access in emergencies
• Key management is challenging!
14
How can these devices agree on a key?
• Pre-install symmetric keys
• Public-key cryptography
• Out-of-band channel (e.g. audio, vibration)
• External devices
Our solution: low-cost source of randomness + key transportationtechnique + necessary protocols to create a secure communication
channel
Adversarial model
• Adversaries can eavesdrop or jam the wireless channel, and modify, replay or forge messages
• Adversaries can be in close proximity with the patient and can possess any legitimate device programmer
• Adversaries CANNOT touch the patient’s skin long enough without the patient noticing it
16
Key generation
• Possible solutions:• TRNG => requires to add new extra harware components
• Local Field Potential (LFP)
• It can be measured by neurostimulators
• It cannot be measured remotely
• Efficient solution
Key generation
18
Key transportation
19
Properties of our solution
• Security vs permissive access in emergencies
• Requires only minor hardware changes
• Adds minimal computation and communication overhead
• Provides forward and backward security
20
Conclusions
• Responsible disclosure
• Security through obscurity is a dangerous approach
• Feasibility of reverse engineering the protocol by a weak adversary
• Novel low-cost source of randomness + key transportation technique
• Balance between security and other important functional requirements