The increasing connectivity of medical devices to wearables and medical applications or software has exposed devices to cybersecurity threats and attacks. Any vulnerabilities in medical devices allow unauthorized users to access and control devices, which can lead to a serious risk to patients, specifically in class B and C medical devices. Hence, healthcare organizations, regulators, and medical device manufacturers are concerned about the potential impact on clinical care and patient safety.
Why cybersecurity for medical devices is the need of the hour?
Critical functionality: Medical devices control the life of the patient. It has critical functions and sensitive data
- Replication: Medial devices are mass-produced in thousands or millions of identical devices. One successful attack may be replicated to multiple devices
- Long lifecycle: The life cycle of the medical device ranges from 15 to 20 years. So, developing a device that meets the security needs of the next two decades is a big challenge
- Siloed: End-user cannot monitor the device’s security or make changes easily
- Firmware clone
- Overview/Use-case: An attacker can clone medical device hardware using reverse engineering and can also clone firmware directly from flash media
- Risks:
- Duplication of device
- Reverse engineering of the firmware
- Resolutions:
- Design firmware licensing mechanism robust enough so that it’s hard to bypass
- Use data protection mechanisms and encrypted firmware
- Brute Forcing
- Overview/Use-case: The secure medical device asks for authentication before accessing device functionality for cloud services and/or human interface (HMI). The attacker systematically checks all possible passwords and passphrases until the correct one is found
- Risks:
- Access to device services and user data
- Resolutions:
- Limit the number of login trials
- Increase delay between an authentication trial
- Firmware update
- Overview/Use-case: Medical devices aftermarket launch are periodically updated by offline media (like USB, OTG cable) or over the internet. This allows the attacker to update custom or corrupted firmware(malware) on the device
- Risks:
- Full/Partial access to the device
- Device firmware corruption
- Resolutions:
- Design/implement a Secure firmware update mechanism using encryption and signature
- Communication stack (IoT based devices)
- Overview/Use-case: Medical devices use BLE, Wi-Fi, or any RF technology for communication over mobile applications or IoT-based software. Attackers may use technology loopholes and modify communication data
- Risks:
- Unexpected system behavior based on data modification
- Unauthorized sale and/or blackmail of personal data
- Resolutions:
- Use a firewall for internet access
- Use latest and secure technology; for example, in the case of Bluetooth, use v4.1 onwards
- Use strong pairing and authentication mechanisms for starting communication and thereafter use encrypted data for communication
- Sensitive firmware and data
- Overview/Use-case: Some parts of the firmware need special protection: for example the cryptographic algorithm or a third-party library. Besides, selected data may need enhanced protection if they are considered as valuable assets (cryptographic keys). The internal memory content must be protected against external accesses (such as communication interfaces) and internal accesses (other software processes). The memory attributes like read and write access for different memory segments and the firewall are the main protections for process and data isolation
- Risks:
- Sensitive firmware copy or data theft
- Resolutions:
- Use Execute-only access right (XO)
- Use Memory protection unit
- Use Secure area
- Use Encryption of external memory
2) Hardware Non-invasive attack: This type of attack mainly focuses on device interfaces and environment information. It does not damage/distract device hardware layers at the silicon level.
- Debug port (JTAG or SWD interface)
- Overview/Use-case: Debug port provides access to bootloader, registers, DRAM, etc. Attackers may use debug ports to access and control devices fully
- Risks:
- Full access to devices
- Resolutions:
- Disable device debug capabilities from hardware after prototype/developer release
- Bootloader
- Overview/Use-case: Most medical devices boot using a bootloader that is based on boot mode, boot address, and/or boot pin configuration. The attack aims at modifying boot mode or address to load custom applications in RAM and access devices
- Risks:
- Full access to the device
- Resolutions:
- Unique boot entry
- Implement a secure bootloader and disable debug options
- Communication interface access like UART/I2C/SPI/USB
- Overview/Use-case: Applications or bootloaders use communication interfaces like UART, I2C, SPI, USB, etc. for communication with the device. Interception of this communication allows the attacker to access device content and/or modify communication. Malware can also be injected using some media like USB
- Risks:
- Access to device content
- Resolutions:
- Use cryptography for communication. For example, using TLS for data communication. TLS provides features that protect the confidentiality and integrity of data
- Disable unrequired input ports/communication
- Make a physical bus hard to reach
- Clock and power disturbance/glitch
- Overview/Use-case: Fault can be injected using the device outside of parameters defined in the datasheet. Threats involve changing clock and/or power parameters. A successful attack may change program behavior
- Risks:
- Unexpected device behavior
- Resolutions:
- Use a clock security system (CSS)
- Use an internal clock if available
- Use internal voltage regulators
- Side-channel attacks (SCA)
- Overview/Use-case: When the device is running, an attacker may observe power consumption, electromagnetic radiation, temperature, etc. to retrieve secret assets like data values and/or algorithm implementation. SPA (simple power analysis) and DPA (Differential power analysis) is a typical example of this
- Risks:
- Access to device data
- Resolutions:
- Use session random number keys
- Use protected cryptographic libraries
- Reverse engineering
- Overview/Use-case: An attacker may understand the inner structure of the device and its functionality. It may create a map of the device/microcontroller using an optical microscope to produce a high-resolution image of the device surface. Further steps may include analyzing deeper layers of the hardware device
- Risks:
- Cloning of devices
- Resolutions:
- Use a multi-layer PCB which is difficult to analyze/debug
About VOLANSYS
VOLANSYS as a trusted healthcare solution partner for leading medical device manufacturers and healthcare system providers, has capabilities in device miniaturization, designing low power customized wearables, invasive and non-invasive devices, security compliance, and more. Read our success stories to know more about smart healthcare solutions.
