AAMI fellow Axel Wirth says outdated certificate trust stores and difficult update processes could leave connected medical devices exposed long after other systems are secured.

By Alyx Arnett

An October security incident involving compromised digital certificate keys at eMudhra—a digital certificate provider whose certificates are used to verify the identity of websites and services—has raised concerns about the security of connected medical devices. While major browsers and operating systems moved quickly to address the vulnerability after it was reported on Oct 17, medical devices may remain exposed for considerably longer.

The incident involved eight intermediate certificate authorities whose cryptographic keys were improperly generated, potentially allowing attackers to impersonate trusted websites or services and forge software signatures. For medical devices, addressing the vulnerability presents particular challenges, according to Axel Wirth, chief cybersecurity strategist at MedCrypt and an AAMI Fellow.

Unlike browsers that receive frequent certificate updates, many medical devices rely on hardcoded trust stores that are updated manually or through firmware releases, Wirth says. Some devices also do not regularly check online certificate revocation lists.

“Fixes don’t reach devices automatically,” he says. “They may require manual updates or even software updates that include new certificates.”

The incident also exposes a longstanding visibility problem for healthcare technology management (HTM) departments, Wirth says. “Their view of what devices they have is often incomplete, let alone knowing what software runs on those devices and what the state of their certificates is,” he says.

Finding Devices That Trust eMudhra

Wirth says the greatest concern involves systems that contain their own copies of public certificate authority trust stores. Devices that use private trust stores containing only a manufacturer’s own roots would not be affected by the eMudhra compromise, he says.

Potentially exposed systems could include medical devices, point-of-care systems, middleware, legacy electronic health record integrations, and embedded clinical systems that are rarely updated, according to Wirth. Clinical applications that contain browser engines or runtimes such as Java, Node.js, or Python also may retain outdated trust stores after mainstream browsers have been updated.

“Many devices import a general-purpose operating system or browser trust store wholesale,” Wirth says. “The manufacturer then carries the same revocation burden as Chrome or Windows, but without their update capabilities.”

For HTM teams, determining exposure should begin with the asset inventory and available device documentation, Wirth says. Because hospitals may be unable to inspect certificates directly on a device, he recommends reviewing manufacturer disclosure statements for medical device security, software bills of materials, and other vendor documentation to identify which certificates devices rely on and what functions they support.

HTM teams should examine clinical communications as well as remote service connections, telemetry, and software update channels, he says. For each connection, they should identify which certificate authorities the device relies on, including the intermediate and root certificates involved in establishing trust.

“Don’t assume—verify,” Wirth says. Hospitals should ask manufacturers whether devices use eMudhra root or intermediate certificates, whether eMudhra-based code signing was used, which models and software versions are affected, and when updates will be available.

Interception and Malicious Updates

Wirth identifies two primary attack paths for devices that trust compromised certificates: interception or manipulation of encrypted traffic and acceptance of malicious software updates.

“Interception could mean altered or stolen patient data passing between devices, gateways, and EHRs,” he says. “A forged signed update could put unauthorized code on equipment involved in patient care.”

Exploiting these vulnerabilities would require additional steps, Wirth says. An attacker would need access to the device’s network path to use a forged transport layer security certificate, while a malicious software update would have to reach the device.

Those requirements give hospitals opportunities to reduce their exposure while permanent fixes are pending. Network segmentation can help limit access to devices, restrictions on outbound connections can reduce opportunities for unauthorized communications, and traffic monitoring can help identify suspicious activity.

However, those measures provide only temporary risk reduction. The certificate compromise could allow an attacker to impersonate an update server and sign the software it delivers. “Compensating controls buy time; they don’t replace the fix,” Wirth says.

For devices that cannot be patched immediately, Wirth recommends that HTM departments coordinate with IT teams that may already be conducting related remediation. Any changes to devices should also be coordinated with clinical owners to avoid disrupting care delivery, he says.

What Manufacturers Should Do

Manufacturers should first tell customers whether their products are affected and describe the expected response, even if a technical solution is not yet available, Wirth says.

From there, manufacturers may need to update device trust stores to remove trust in the compromised certificate authorities, recompile software, and audit code-signing processes, Wirth says. Depending on how certificates are embedded in a device, those changes could require firmware or software updates that hospitals must coordinate around clinical operations. Manufacturers also should recommend interim protections for customers awaiting updates.

Longer term, Wirth recommends that devices trust only the certificate authorities required for their intended functions. He points to National Institute of Standards and Technology certificate-management guidance, SP 1800-16, which recommends maintaining records of which systems trust particular authorities and establishing processes to remove or replace those authorities.

For medical devices, Wirth says manufacturers should consider private public key infrastructure for connections to their own services and for software-update signing. “A device that verifies updates only against its manufacturer’s own signing authority would not have accepted anything signed with the compromised eMudhra keys because it never trusted them,” he says.

Private certificate authorities still require strong key protection and queryable certificate records, Wirth says. He recommends hardware security modules or managed certificate authority services to protect keys and maintain records linking certificates to individual devices.

Making Certificate Management Routine

Wirth says the issue extends beyond installed medical devices. Development tools, build servers, container images, programming runtimes, and factory provisioning systems may contain their own outdated trust stores. A stale trust store in a build environment could allow an impersonated download server or unverified software dependency to enter a product’s supply chain, he says.

“For healthcare environments, none of this will be a quick fix,” Wirth says. “Dependencies and constraints require careful planning.”

Hospitals should establish expectations for how quickly manufacturers can replace a certificate authority, which authorities each device trusts, and how certificate updates will reach products already in the field, he says.

“Certificate and trust store management has to become a standard lifecycle management activity,” Wirth says, “supported by your vendors and enforced via the procurement process.”

ID 463854149 © Cookiecutter | Dreamstime.com