[00:00.000 --> 00:11.060]  In this talk, DIY Diabetics and a Million Boluses, we are three panelists that are going to discuss a common topic related to insulin pump hacking and its global impact.
[00:11.080 --> 00:16.480]  Hi, I'm Dina Truxius. I'm working for the Federal Office for Information Security in Germany.
[00:16.520 --> 00:28.740]  And my work mainly focuses on medical device cybersecurity, on all cybersecurity-related health, on project management, standardization, and a lot of comity work.
[00:28.740 --> 00:33.700]  I'm Julian. I'm Security Analyst and Researcher at EMW Research in Germany.
[00:33.700 --> 00:42.200]  And I perform cybersecurity assessments of medical devices, medical environments, and I'm having a deep dive into medical communication standards.
[00:42.200 --> 00:48.000]  And hey, I'm Mike Christianen. I'm the Director of Medical Security at Harbor Labs.
[00:48.220 --> 00:55.380]  I perform cybersecurity assessments of medical devices for a number of manufacturers and a number of different medical devices.
[00:55.380 --> 01:02.460]  I tend to focus on software, medical firmware, and device communication protocols, especially cryptography.
[01:02.460 --> 01:11.520]  So for our agenda today, our panel will introduce medical device cybersecurity practices and projects in Germany and the U.S.
[01:11.520 --> 01:19.160]  We'll provide a background for insulin pump technology, and we'll define a formal threat model for insulin pumps.
[01:20.160 --> 01:26.620]  Further, we will demonstrate an insulin pump attack and describe the response remediation effort.
[01:26.720 --> 01:35.440]  And then we'll discuss how this impacts the DIY diabetics community, something that if you have not heard of before, you will during this talk.
[01:35.880 --> 01:38.920]  Lastly, we'll conclude with some remarks from the team.
[01:40.680 --> 01:46.120]  So to kick us off first, we'll have Dina covering the global medical device cybersecurity.
[01:46.920 --> 01:59.580]  Thank you. So let me introduce you to the German federal landscape to demonstrate our duties and responsibilities in terms of health and IT security or cybersecurity.
[01:59.880 --> 02:06.160]  This schematic drawing intends to show a very simplified version of the complete German federal government.
[02:06.440 --> 02:11.320]  In Germany, you see below the gray field, we have various ministries.
[02:11.320 --> 02:16.000]  The two important ones are for now folded out.
[02:16.040 --> 02:20.800]  On the left, you see the Federal Ministry of the Interior, Building and Community.
[02:20.860 --> 02:23.380]  And on the right, you see the Ministry of Health.
[02:23.480 --> 02:31.740]  My employer, the Federal Office for Information Security, is the authority under the Ministry of the Interior on the left.
[02:32.360 --> 02:39.700]  We are the German cybersecurity authority and fulfill comparable tasks like DHS and CISA.
[02:39.700 --> 02:43.960]  We fulfill all our legal obligations. We have our own cert.
[02:43.960 --> 02:49.480]  We are experienced in coordinated vulnerability disclosures and in projects.
[02:49.720 --> 02:54.680]  Our legal mandate allows us to assess basically any IT device.
[02:55.220 --> 03:06.960]  In terms of medical devices, we have no direct legal mandate yet, except the fact that we can be included in the risk assessment of medical devices in terms of IT security
[03:06.960 --> 03:12.780]  by the Federal Institute for Drugs and Medical Devices, the BFARM.
[03:12.780 --> 03:19.040]  This authority carries out all regulation with regards to medical devices.
[03:19.040 --> 03:25.340]  The BFARM is comparable to FDA. They deal with safety and vigilance issues.
[03:25.420 --> 03:32.640]  Whenever any incident is reported in medical devices, the BFARM gets active and uses its established processes.
[03:32.640 --> 03:41.740]  We are working closely together with BFARM and our health ministry and for sure our authority in all terms of medical device cybersecurity.
[03:44.760 --> 03:57.900]  So the Federal Office for Information Security, the BSI, which stands for Bundesamt für Sicherheit in der Informationstechnik, it's a German abbreviation, is a thought leader in cybersecurity.
[03:58.530 --> 04:13.130]  We were already founded in 1991 and we enormously expanded within the last years and today we have more than 1,300 employees in total, mostly IT specialists and natural scientists.
[04:13.540 --> 04:22.240]  The federal government in Germany realizes and still sees the need to have a functional national cybersecurity authority.
[04:22.240 --> 04:32.540]  So we are covering all fields of work with respect to cybersecurity, from A to Z, from autonomous vehicles over medical devices to the Zoom app.
[04:32.540 --> 04:43.440]  We are cooperating with national, EU, international authorities and stakeholders and our budget is invested in various cybersecurity projects.
[04:43.440 --> 04:47.320]  And I'm really keen to give you some more insights during this talk.
[04:50.520 --> 04:59.000]  So our overall mission is to cover all issues related to cybersecurity and to make the world more secure.
[04:59.000 --> 05:12.980]  We believe we can and we do care about it. As a BSI employee, the following statement is somehow implanted into my brain and I know that every IT system is potentially vulnerable at any given time point.
[05:12.980 --> 05:19.680]  We know that it is not a matter of getting hacked. It will happen anyway and everywhere at one point.
[05:19.680 --> 05:29.720]  But for us, it's essential to keep in mind that it's important to be prepared and to know how to deal with vulnerabilities in a coordinated and responsible manner.
[05:32.810 --> 05:44.270]  In order to fill some of our legal obligations and to increase the awareness towards cybersecurity, we regularly publish technical guidelines and recommendations.
[05:44.270 --> 05:54.390]  In the field of medical device cybersecurity, we published a recommendation about cybersecurity requirements for network-connected medical devices in 2018.
[05:54.430 --> 06:01.090]  This is available in German and English and it is defining best security practices.
[06:01.090 --> 06:12.430]  This publication is in accordance with national and EU-wide regulation requirements and cybersecurity is seen as a continuous process throughout the product lifecycle.
[06:12.430 --> 06:17.850]  Apart from this, this document can assist in terms of risk analysis.
[06:20.070 --> 06:23.690]  So, my cybersecurity requirements to go for you.
[06:23.690 --> 06:33.190]  When we look at cybersecurity and discover vulnerabilities in medical devices, we definitely have to consider and have to discriminate between the modes of action.
[06:33.190 --> 06:37.550]  There is a huge difference between the medical operation and the technical maintenance mode.
[06:37.550 --> 06:40.650]  For example, in terms of privileges and authentication.
[06:40.650 --> 06:52.090]  My cybersecurity to go message for you is that the required security updates and measures must not have a negative impact on safety.
[06:52.190 --> 06:57.610]  And not every vulnerability has an impact on patient safety, but it is possible.
[06:57.610 --> 06:59.710]  Now, I'm talking about our project money made.
[06:59.710 --> 07:12.250]  So, when I joined the BSI in 2018, there was a lot of rumor and discussion about medical devices, not only in press, especially about pacemakers and insulin pumps and potential or possible patient harm.
[07:12.470 --> 07:17.190]  So, I asked myself what can be done and what has been done so far.
[07:17.230 --> 07:21.250]  And the idea of a medical device hacking project came into my mind.
[07:21.250 --> 07:29.930]  I made use of our budget, entertained myself with paperwork and tended the project money made, which stands for manipulation of medical devices.
[07:29.930 --> 07:34.430]  The project started in 2019 and will end in December this year.
[07:34.810 --> 07:40.490]  The project aims to assess the current cybersecurity state of medical devices.
[07:40.910 --> 07:49.330]  And it aims to bring cybersecurity researchers like Mike and Julian, manufacturers and authorities like me to a table.
[07:49.330 --> 08:01.730]  I chose five different device categories, namely ventilators, patient monitors, ICDs and their environment, infusion pumps, and last but not least, insulin pumps.
[08:01.930 --> 08:11.210]  Out of each category, we aim to assess two devices, so in total 10 devices within the scope.
[08:11.210 --> 08:17.450]  To further restrict our market research, I asked for additional requirements when picking the devices.
[08:17.450 --> 08:24.290]  These are the following. First, the devices had to be no longer than five years on the German market.
[08:24.590 --> 08:31.810]  Second, and should be highly connected, having as many interfaces as possible for an appropriate attack surface.
[08:32.650 --> 08:38.730]  So, after picking the respective devices, we tried to get in contact with the top manufacturers found in our market research,
[08:38.730 --> 08:45.450]  explained our intention to pentest the respective devices, and ideally ended up with a signed testing contract.
[08:45.450 --> 08:51.630]  With this, the manufacturers provided us with the respective medical devices and lab environments,
[08:51.630 --> 08:59.370]  and in return, they received exclusive knowledge about their security state in the devices.
[08:59.510 --> 09:04.870]  After the security assessment, the manufacturers are provided with a detailed report about all findings,
[09:04.870 --> 09:09.290]  and a subsequent coordinated vulnerability process is initiated.
[09:09.650 --> 09:13.610]  All findings are published as soon as the vulnerabilities are fixed.
[09:13.610 --> 09:20.810]  We recommend to use ICSMAs and closely collaborate with CISA, and we recommend to assign CVEs.
[09:21.170 --> 09:28.850]  The project aims to increase transparency and awareness. Additionally, the trust for communication and cooperation among all stakeholders,
[09:28.850 --> 09:36.350]  which is seen as one of the highest goods in our whole process, and inspired by a classical coordinated vulnerability disclosure.
[09:36.350 --> 09:43.870]  We believe that the project results aimed to be published in December will allow for cyber security statements,
[09:43.870 --> 09:51.150]  as well as addressing certain questions and problems basically everyone is facing in the field of smart medical devices.
[09:51.150 --> 10:00.310]  This project that I'm leading is the basis for the security research on a smart insulin pump that will be shown by Julian, our technical project lead.
[10:00.310 --> 10:10.090]  When we will demonstrate these findings, please be aware that I make use of my legal mandate to inform about important security updates.
[10:10.090 --> 10:16.210]  My intention is to improve cyber security without finger pointing at anyone or anything.
[10:16.210 --> 10:23.430]  I want people to get a feeling, or better to say a sixth sense, a cyber security sense for vulnerabilities.
[10:23.430 --> 10:29.590]  I think that's really helpful to understand BSI and sort of your goal and your project and your aims.
[10:29.790 --> 10:34.870]  From the US side, we have FDA cyber security guidance that's in place.
[10:34.870 --> 10:40.110]  In particular, we have guidance for medical devices before they can be marketed.
[10:40.290 --> 10:43.390]  They have to have this pre-market evaluation.
[10:43.870 --> 10:49.350]  The strictness of controls that are a part of this evaluation are determined by the risk to patient safety.
[10:49.350 --> 10:54.370]  Medical devices are actually classified in three bins. We have one, two, and three.
[10:54.650 --> 10:59.630]  In terms of risk, this is lowest to highest, three being the highest.
[11:00.810 --> 11:07.630]  With respect to cyber security analysis that my team at Harvard Labs typically focuses on is class two and class three.
[11:07.670 --> 11:13.130]  These devices have, for example, network interfaces to communicate with other endpoints.
[11:13.130 --> 11:20.310]  They are communication patient data, and furthermore, they're actuating, which might be, say, to deliver a medicine.
[11:20.710 --> 11:27.830]  Now, depending on the classification of the device, the pre-market process, there's two specific processes that are taken.
[11:27.950 --> 11:31.590]  If it's a class two, you would submit a 510k pre-market notification.
[11:31.670 --> 11:36.550]  If it's a class three, you would submit a PMA for pre-market approval.
[11:37.030 --> 11:41.050]  Now, both of these submissions have cyber security requirements.
[11:41.050 --> 11:46.370]  I've actually worked with a number of clients to create these submissions.
[11:46.770 --> 11:53.670]  And sort of as the rigor in the submission, some of the steps, if I could elucidate them quickly,
[11:53.670 --> 12:01.250]  my team and the manufacturers look to specify all the cyber security threat models, understanding what threats are to their systems,
[12:02.090 --> 12:08.310]  laying bare and plain the architecture and data flow, enumerating harm and non-harm risk to patient safety,
[12:08.310 --> 12:13.870]  and then identifying, implementing, and analyzing any potential mitigations that the system can possibly implement
[12:13.870 --> 12:17.530]  to reduce the risks and vulnerabilities in the systems overall.
[12:17.530 --> 12:23.390]  And what's nice, the really nice takeaway here is that the FDA does have post-market management recommendations.
[12:23.390 --> 12:29.850]  They exist now. I think that we could definitely learn from BSI's approach, especially since we're in the recommendation phase.
[12:29.850 --> 12:35.270]  I'm not a regulator, I'm just a security person, but I think this is a really great conversation to have.
[12:35.270 --> 12:36.890]  And that's where I see that crossover.
[12:38.310 --> 12:44.090]  So for today, all that said, our major focus is going to be on insulin pumps.
[12:44.090 --> 12:56.250]  And so for hacking and some of the community efforts and regulatory efforts, we will specifically focus on this type of medical device.
[12:58.070 --> 13:04.570]  So to get us started, I'm going to provide a brief background for insulin pump devices in general,
[13:04.570 --> 13:09.250]  and also provide a threat model so that way we can start thinking with our security hats.
[13:11.090 --> 13:14.030]  So to best describe this, Bob's going to help me out.
[13:14.030 --> 13:20.090]  So Bob has type 1 diabetes, and Bob uses an open loop insulin delivery system to manage his condition.
[13:20.090 --> 13:24.010]  So it's open loop in that Bob is the person that actually presses the button.
[13:24.270 --> 13:32.510]  Now, this system is comprised of a continuous glucose monitor, typically CGM, that's the acronym for that, insulin pump, and smartphone.
[13:32.510 --> 13:40.950]  So what's unique and interesting here is that we have a communication interface that's wireless between the insulin pump and the smartphone.
[13:40.950 --> 13:43.430]  So they pair, and that's over BLE.
[13:43.450 --> 13:54.210]  In terms of data flow, the common architecture is that logs can be sent from the insulin pump to the phone, and then commands can be sent from the phone to the insulin pump.
[13:56.940 --> 14:07.080]  Now, in terms of getting into the exact particulars of the insulin pump composition, as I think it will help understand Julian's part later when he talks about hacking insulin pumps,
[14:07.080 --> 14:10.460]  so we have to understand that it is an embedded system at the end of the day.
[14:10.540 --> 14:16.940]  So this is, it looks, it's a very common architecture that computer security professionals are familiar with.
[14:16.940 --> 14:20.260]  There's a system on chip design. Typically, this is ARM based.
[14:20.260 --> 14:28.140]  It has a Bluetooth radio. The idea of the Bluetooth radio is such that we can pair two separate devices speaking the same protocol.
[14:28.200 --> 14:35.280]  It's typically uses low energy because the pump itself is worn on the patient. We can't just connect it to a wall.
[14:35.280 --> 14:39.340]  So we don't have, I don't know, 240 volts to keep it powered.
[14:39.820 --> 14:44.280]  And so it's, you know, that's what motivates our selection of the communication protocol.
[14:44.280 --> 14:49.800]  Different pairing connections are supported. So we have legacy connections or secure connections.
[14:50.000 --> 14:53.480]  Hopefully, most of our manufacturers are leaning towards secure connections.
[14:53.660 --> 14:56.920]  Furthermore, there is no, it's bare metal, no operating system.
[14:56.920 --> 15:04.680]  So there's a, you typically might have a bootloader, but the rest of it is just instructions such that the pump can actuate and also receive data and send data.
[15:05.320 --> 15:11.300]  In terms of connecting to the other components or understanding what the other assets are in the system, of course, we have our patient.
[15:11.300 --> 15:14.540]  There's a catheter that connects the patient that delivers the insulin.
[15:14.640 --> 15:18.840]  And then of interest from a security perspective, we have the smartphone and the pump.
[15:18.840 --> 15:21.400]  And as I've just said, that connection is over VLT.
[15:24.000 --> 15:27.520]  So let's start thinking about this in the terms of cybersecurity.
[15:27.740 --> 15:29.300]  Let's think about the threat model, right?
[15:29.300 --> 15:35.620]  So first, when we're thinking insulin pumps, we have to understand what the patient harm and non harms are.
[15:35.640 --> 15:40.840]  So a harm, a patient harm is that the pump delivers too much insulin or maybe not enough insulin.
[15:40.840 --> 15:43.940]  And this could be detrimental to the overall health of the patient.
[15:43.940 --> 15:47.480]  And that's considered a patient's harm safety risk.
[15:47.840 --> 15:56.280]  Non-harm would be the pump, insulin pump leaks some private information about the user to an unauthorized user.
[15:56.280 --> 16:00.820]  Say maybe it's this passive eavesdropper that's listening on the Bluetooth communication.
[16:00.820 --> 16:03.680]  And that would be considered a non-harm risk to the patient.
[16:03.680 --> 16:16.540]  Now, what security researchers do when we're looking at medical devices is that we always apply a threat model approach to understanding what all the risks are to the particular device.
[16:16.540 --> 16:20.480]  And so what I'm using or what I'll detail here is something called Microsoft Stripe.
[16:20.480 --> 16:25.380]  And it's a way to categorize risks, and I've applied it to the general insulin pump case.
[16:25.380 --> 16:28.820]  So first we have spoofing, which is to impersonate a system.
[16:28.820 --> 16:34.800]  In an insulin pump case, the attacker can masquerade as a valid smartphone.
[16:34.800 --> 16:38.700]  That would be a spoofing-based attack that we would want to consider.
[16:38.820 --> 16:42.240]  We also have tampering, which is modifying data or code.
[16:42.240 --> 16:46.320]  In this particular case, an attacker man-in-the-middle is the pump to smartphone communication.
[16:46.700 --> 16:50.380]  We have repudiation, claiming to not have performed an action.
[16:50.380 --> 16:59.540]  And so imagine the scenario where an attacker has successfully man-in-the-middle communication between smartphone and insulin pump, and they're able to, say, inject commands.
[16:59.540 --> 17:03.520]  Well, the pump is unaware because these are unauthorized, unauthenticated commands.
[17:03.520 --> 17:06.660]  They can't distinguish between if it was valid or not.
[17:06.660 --> 17:14.060]  And so if the pump even has a log, it's not going to say, well, this definitely came from Mike's phone, because it has no notion of the sentence.
[17:16.940 --> 17:19.540]  Continuing on in Stripe, we have information disclosure.
[17:19.540 --> 17:22.780]  This is exposing information to unauthorized users.
[17:23.240 --> 17:27.920]  So in this particular case, we can imagine an attacker that eavesdrops on pump-to-smartphone communication.
[17:27.940 --> 17:33.860]  They're not looking to inject commands, simply see what information they can see going across the wire.
[17:34.600 --> 17:37.980]  Next, we have denial of service, which is to deny or degrade access.
[17:37.980 --> 17:44.380]  I always say this is the bane of cybersecurity professionals, because it's really hard to protect against, especially if it's directed.
[17:44.700 --> 17:49.020]  And then the insulin pump case, this is where the attacker overruns the pump with requests.
[17:49.020 --> 17:54.080]  Which would deny the valid or authenticated user from using the pump as it's intended.
[17:54.480 --> 17:59.960]  Lastly, we have elevation privileges, which is to gain access to unauthorized capabilities.
[18:00.280 --> 18:06.360]  And so when we're thinking about this in terms of insulin pump, we would like to consider an attacker that gains access to the smartphone app,
[18:06.360 --> 18:15.940]  maybe by exploiting a smartphone OS vulnerability, and thus gaining unauthorized access to our insulin pump application,
[18:15.940 --> 18:19.420]  and then directly impacting the pump operation itself.
[18:20.160 --> 18:26.320]  So just to be completely encompassing, another step that my team at Harper Labs really likes to take,
[18:26.320 --> 18:29.160]  we have our threat model, but we also have an attacker model.
[18:29.160 --> 18:32.160]  And the idea here is to understand the attacker's goals and capabilities.
[18:32.160 --> 18:39.200]  This is where security gets real, because we want manufacturers and the community to understand,
[18:39.200 --> 18:43.040]  well, what is the absolute goal of attacking an insulin pump, for example?
[18:43.040 --> 18:49.500]  Well, it's to cause patient harm. If that is really the focus, whenever we're looking at a medical device,
[18:49.500 --> 18:54.520]  we're trying to find vulnerabilities that could actually impact the patient and their safety.
[18:54.800 --> 19:02.680]  Now, also, an attacker could be, say, just this arbitrary software execution, like malware.
[19:03.300 --> 19:07.180]  Mirai botnet would be a great example. That's just trying to pivot into the network.
[19:07.180 --> 19:11.700]  And so if we're not securing our medical devices that are essentially network endpoints,
[19:11.700 --> 19:16.440]  we may allow a pivot into the network, and then any other unexpected behavior that might come of that,
[19:16.440 --> 19:18.420]  which could still impact patient safety.
[19:18.860 --> 19:22.360]  And, of course, we have to consider things like the position of the attacker in the system.
[19:22.460 --> 19:25.660]  Are they an insider manufacturer that knows all the gory details?
[19:25.740 --> 19:30.060]  Are they simply just a person on the outside with a high-gain antenna and some equipment?
[19:30.400 --> 19:33.740]  I also wanted to point out, too, in terms of capabilities, since this is BLE,
[19:33.740 --> 19:38.860]  we're looking at maybe 300 US dollars in terms of BLE hacking equipment.
[19:41.000 --> 19:45.120]  And I'll summarize quickly, because visuals are the best way to depict this.
[19:45.120 --> 19:50.280]  There are a number of attack surfaces that exist in our general insulin pump model.
[19:50.280 --> 19:54.280]  We have our physical interface, being able to connect to serial or press buttons.
[19:54.480 --> 19:59.040]  We have our wireless interface, which is communication that's happening over Bluetooth,
[19:59.040 --> 20:04.400]  which Julian will talk in depth about as the attack surface that he focused on.
[20:04.660 --> 20:07.140]  And he also focused a bit on the app interface.
[20:07.140 --> 20:10.540]  So what can the application tell you? What can you learn from it?
[20:10.540 --> 20:17.960]  You know, this is another attack surface that an attacker could leverage to compromise an insulin pump.
[20:19.080 --> 20:23.540]  And so with that, I'll turn it over to Julian to talk about insulin pump hacking.
[20:24.260 --> 20:30.840]  Thanks. In the following minutes, I will explain the communication protocol of the Dana Diabica RS insulin pump,
[20:30.840 --> 20:35.860]  which is sold by the Korean manufacturer Soil Developments, as well as vulnerabilities we identified.
[20:35.860 --> 20:42.160]  I want to state that the presentation of the vulnerabilities shall not be understood as finger-pointing towards the manufacturer,
[20:42.160 --> 20:49.840]  but may shed light on design problems more manufacturers are facing with building interconnected medical devices.
[20:50.080 --> 20:55.460]  The manufacturer intends patients to use the pump as a central component of an open-loop system
[20:55.460 --> 20:58.700]  in combination with the respective mobile applications.
[20:58.820 --> 21:01.840]  With these mobile apps' safety-critical functionality of the pump,
[21:01.840 --> 21:07.920]  such as manual administration of boluses or changing the basal rates of profiles is possible.
[21:07.980 --> 21:12.800]  Besides, patients are creating less restrictive ways in controlling their therapy devices,
[21:12.800 --> 21:19.320]  as, for example, the We Are Not Waiting initiative demonstrated in the past by building closed-loop systems on their own.
[21:19.320 --> 21:22.320]  We will come back to this later in the talk, I think.
[21:22.320 --> 21:30.540]  And further, the Dana Diabica RS insulin pump is supported by publicly-awaited looping apps such as Android APS.
[21:33.190 --> 21:39.630]  The security assessment of medical devices is highly specialized and is dependent on the device's medical use case,
[21:39.630 --> 21:47.570]  present interfaces, users and their backgrounds, use technologies, but also assumptions, for example, to its environment.
[21:47.930 --> 21:53.950]  In scope of the test was the proprietary communication protocol between the insulin pump and its mobile applications,
[21:53.950 --> 21:56.550]  which was built on top of Bluetooth Low Energy.
[21:56.550 --> 22:02.070]  So the Bluetooth Low Energy capabilities were just used to implement some application-related protocol.
[22:02.070 --> 22:07.170]  In a special, the assessment focused on the used and implemented cryptography,
[22:07.170 --> 22:11.710]  as well as on the authentication and pairing process between the pump and its mobile apps.
[22:11.850 --> 22:16.330]  The testing methodology was a black-box test without source code inside,
[22:16.330 --> 22:19.410]  and we were voluntarily provided with two insulin pumps by the manufacturers
[22:19.910 --> 22:24.270]  and downloaded the mobile applications from the App Store and the Google Play Store.
[22:27.860 --> 22:33.760]  I will first demonstrate the normal communication flow we observed between the pump and its mobile applications.
[22:33.760 --> 22:37.160]  We will start with the application layer pairing process.
[22:37.320 --> 22:44.620]  The first byte demonstrates whether the message is a request with 0.1 or a response with 0.2.
[22:44.700 --> 22:48.440]  We will talk about the names of the keys that are used on the following slides,
[22:48.440 --> 22:53.160]  so don't hesitate to identify all the keys and understand their usage.
[22:53.160 --> 22:54.600]  So we will come to this.
[22:55.140 --> 23:00.620]  This and similar figures will present the different encryption layers with different colors.
[23:00.620 --> 23:04.980]  Yellow color states that this information is transmitted in plain.
[23:04.980 --> 23:09.620]  Blue color shows that the messages need to be encrypted using the device key.
[23:09.620 --> 23:13.260]  And red color is showing that user interaction is needed,
[23:13.260 --> 23:18.360]  as well as green color indicates that messages need to be encrypted using free keys.
[23:18.580 --> 23:26.900]  Every communication starts with the mobile app sending a 0100 message to the pump together with its serial number.
[23:26.900 --> 23:32.480]  The pump indicates that the serial is matching and afterwards the pairing is requested.
[23:32.840 --> 23:37.080]  The pump immediately answers the request and shows a pairing prompt on its display,
[23:37.080 --> 23:40.640]  which needs to be confirmed manually by pressing a key on the pump.
[23:40.760 --> 23:43.580]  A photo of this pairing prompt can be seen here.
[23:46.320 --> 23:53.040]  After having a user confirming the pairing, the pump sends the pairing key to the mobile application,
[23:53.040 --> 23:57.440]  which then may use the key to encrypt messages after requesting a session key.
[23:57.440 --> 24:02.900]  With these free keys, higher-privileged requests, such as ballast administration, may be performed.
[24:03.140 --> 24:06.420]  For now, the free keys may be a bit confusing.
[24:06.420 --> 24:12.120]  I believe that it becomes way more clear when seeing the post-pairing communication flow.
[24:12.120 --> 24:15.920]  The next time the pump and the app are communicating, no user interaction is needed,
[24:15.920 --> 24:21.200]  as the app only needs to send a pairing key to show that both entities are already paired.
[24:21.440 --> 24:26.140]  After requesting a new session key, high-privileged requests can be sent.
[24:26.140 --> 24:28.540]  Here we see the free keys again.
[24:28.600 --> 24:30.960]  The device key is used to encode all messages.
[24:30.960 --> 24:35.940]  The pairing key and the session key are used to authenticate the session, which is shown in green.
[24:36.840 --> 24:43.120]  An interesting find works that the communicating party does not need to be paired to extract the PIN.
[24:43.260 --> 24:44.880]  This is shown in the next slide.
[24:45.920 --> 24:50.860]  The PIN is not directly transmitted, but can be calculated with the information transmitted.
[24:50.860 --> 24:55.560]  We omitted the respective formula not to give some more insights on the protocol,
[24:55.560 --> 24:59.380]  because we do not want to have you building exploits for this.
[24:59.380 --> 25:03.240]  This enables adhocs to extract the lock key PIN,
[25:03.240 --> 25:12.040]  and every Dana RS pump in the adhocs range, Bluetooth range, is possible to be read out.
[25:12.040 --> 25:16.860]  The next finding we want to elucidate is about weakly generated encryption keys.
[25:16.860 --> 25:23.080]  The device key is derived from the pump's serial number, does not contain any randomizing element, and will never change.
[25:23.200 --> 25:26.660]  The serial number can be obtained from BLE advertisements.
[25:27.100 --> 25:31.320]  The session key can be calculated from the pump's lock PIN as well as configured time.
[25:31.340 --> 25:34.660]  We saw the respective request on the previous slide with the PIN disclosure.
[25:34.940 --> 25:38.320]  Having these three occurrences of doubtful calculations of secrets,
[25:38.320 --> 25:43.020]  we further investigated all the other keys and recognized that also the pairing key is not random.
[25:43.020 --> 25:48.340]  This key is calculated on the pump, so we had no ability to reverse this calculation.
[25:48.380 --> 25:52.440]  Though we wrote a script that requested pairing multiple times a second,
[25:52.440 --> 25:57.280]  and saw that the same key will be returned in a second.
[25:57.340 --> 26:00.800]  Therefore, we tried multiple combinations of calculations,
[26:00.800 --> 26:07.220]  and finally found the formula to calculate the pairing key being derived from the pump's time during pairing.
[26:07.220 --> 26:11.680]  So it's fixed, as the key is calculated from the time of the pairing.
[26:11.680 --> 26:16.520]  As a result, any secret of the Dana-RS system is generated insecurely.
[26:16.520 --> 26:21.460]  In addition to the lock PIN disclosure, no active verification of the pump's identity is present.
[26:21.460 --> 26:26.960]  Therefore, attackers can spoof both communication partners and therefore get in many the middle position.
[26:26.960 --> 26:30.620]  How realistic this is with Bluetooth Low Energy is up to you,
[26:30.620 --> 26:35.520]  because I want to present a more easy attack for later.
[26:35.520 --> 26:37.960]  Another example is the missing replay protection.
[26:37.960 --> 26:42.200]  By checking the Bluetooth Low Energy session, attackers may replay sniffed messages.
[26:42.480 --> 26:48.640]  But still, the most easy way to issue trusted commands is to capture a single communication flow between the pump and an app.
[26:48.640 --> 26:51.240]  We will get into this on the next slide.
[26:54.120 --> 27:01.340]  As we already have seen, the whole authentication mechanism relies on encryption using multiple keys.
[27:01.460 --> 27:06.000]  This pairing key is the only key that is needed to issue higher privileged commands,
[27:06.000 --> 27:12.760]  as the session key can be requested by anyone and as the device key is known to everyone without even connecting to the pump.
[27:13.120 --> 27:20.080]  When having a look at the authentication flow, the pairing key is transmitted being encrypted with the device key as marked in the red box.
[27:20.180 --> 27:25.920]  This encryption is completely deterministic and everyone sniffing the communication is able to extract this key.
[27:26.000 --> 27:28.720]  We will not show how the encryption works in detail.
[27:31.700 --> 27:40.440]  The weak pins are low-hanging fruit and only pose a risk for attackers with physical access to the pump, as our threat model already showed that Mike presented.
[27:40.440 --> 27:49.100]  The communication of the vulnerabilities in the communication protocol empowers attackers to hijack the pump and use all functionalities that are offered via Bluetooth Low Energy.
[27:49.240 --> 27:56.900]  To exploit this, an attacker needs to be in proximity to the pump, sniffing a single communication between the insulin pump and the paired mobile application.
[27:56.900 --> 28:02.000]  This attack can be performed automatically in productive environments and we want to demonstrate this.
[28:02.000 --> 28:07.480]  The manufacturer prepared an update for the pump fixing the vulnerabilities, but let us first have the demo.
[28:09.400 --> 28:15.340]  Now I'd like to present you the attack in a short video demonstrating the criticality of the automated attack.
[28:15.340 --> 28:17.640]  A few words I needed to explain the video.
[28:17.680 --> 28:25.320]  In the following video, an attacker captures messages between an insulin pump, a mobile app, and extracts the key from this communication.
[28:25.320 --> 28:35.700]  He hijacks and terminates the session between the pump and its paired app, creates a new session impersonating the app using the parent key and administers multiple insulin boluses.
[28:36.180 --> 28:43.980]  I was just clicking on a pump to reactivate the display, so there's no need to have this interaction at this point.
[28:44.120 --> 28:50.420]  The patient may notice the administration and is able to cancel the single administration on the pump.
[28:50.420 --> 28:55.120]  But as you can see in the following, more boluses are following.
[28:57.560 --> 29:04.960]  I filled the whole tubing system with blue ink so you can see that in real life this would have been insulin.
[29:06.580 --> 29:17.300]  As you can see, the patient is trying to cancel all the administrations one after another, but just another administration will follow this until the attacker stops.
[29:17.440 --> 29:22.960]  Wow, Julian, thank you for the stunning video. I'm always impressed when I see it.
[29:22.960 --> 29:32.460]  When we now draw a conclusion from what we just heard, we can say that most of the vulnerabilities found are design defects.
[29:33.160 --> 29:43.620]  The manufacturer collaborated at all time with us. He prepared and provided an update, as Julian already said, and that was rolled out in April 2020.
[29:43.620 --> 29:57.100]  So the whole process was accompanied by an FSN, which was published on our regulatory's website. An example of this from a UK regulatory authority in English is shown on the right.
[29:57.380 --> 30:12.340]  Although we found vulnerabilities that are affecting the communication between the pump and the app, the device could still be operated when disabling Bluetooth functionality as a temporary fix.
[30:12.340 --> 30:21.560]  As mentioned in the FSN, the device can be securely operated when the airplane mode is enabled, thereby preventing its functionality.
[30:21.980 --> 30:28.100]  Moreover, the device has several safety features already implemented preventing from a misuse.
[30:28.420 --> 30:37.280]  In summary, the pump could be used when the airplane mode was enabled to prevent potential risk when we discovered these vulnerabilities.
[30:37.280 --> 30:42.740]  But I guess you're not only interested in the disclosure itself, but in the timeline.
[30:42.740 --> 30:48.640]  So, as stated before, we aim to lift cybersecurity and act accordingly.
[30:48.660 --> 30:55.160]  In our opinion, a coordinated vulnerability disclosure process is desired whenever findings are reported.
[30:55.160 --> 31:00.520]  We use usually 90 days and give an extension upon a justified reason.
[31:00.740 --> 31:05.940]  Julian, me and our team colleagues managed and coordinated the whole disclosure process.
[31:05.940 --> 31:17.260]  We believe that it's essential to identify vulnerabilities in medical devices in an ethical way to strengthen cybersecurity, consumer protection, and patient safety.
[31:17.320 --> 31:23.220]  Thereby, we all maintain a basis of trust to allow for mutual exchange and efficient communication.
[31:23.600 --> 31:27.920]  As mentioned before, I have no intention to blame anyone here.
[31:27.920 --> 31:37.740]  As a project team, we believe that ethical publishing of vulnerabilities is possible, thereby increasing transparency and the willingness to update devices in time.
[31:37.860 --> 31:45.260]  However, it has to be ensured at all time that the publication does not pose serious harm to patients.
[31:45.320 --> 31:52.780]  In our case, short-term measures and workarounds exist and existed, and an innovative device was not withdrawn from the market.
[31:52.780 --> 32:01.180]  I believe that security and safety are not contradicting each other and that secure connected devices are pioneering.
[32:01.260 --> 32:06.280]  Awesome work, guys. Especially, I like to see the ink on the napkin. Every time I see it, it's so amazing.
[32:06.380 --> 32:18.540]  But then to follow it up with the process of, you know, patient safety being paramount, not pulling the device, but working directly with the manufacturer and having a great story about it is all the more compelling for the work that we do.
[32:18.540 --> 32:22.820]  So I commend the team for great, great effort there. Great work. Great job.
[32:23.320 --> 32:30.660]  With that, I'm going to segue the remainder of the talk into the impact of hacking on DIY diabetic community.
[32:31.260 --> 32:44.560]  Now, the way that we've tied this together, because Julian and Dina had disclosed, as an anecdote to me, their process with Dana RS, the pump, and then the remediation effort.
[32:44.560 --> 32:50.480]  And that remediation effort had caused some issues with Android APS compatibility.
[32:51.420 --> 33:01.540]  And so let me define that first. Android APS is just open source application that's used to create an artificial pancreas system. That's where the APS acronym comes from.
[33:02.300 --> 33:11.980]  And an APS system just delivers insulin injections on the patient's behalf. So it's completely automated. It's also called a closed loop system in case anyone's interested.
[33:11.980 --> 33:20.920]  Now, there's an entire open source and DIY diabetics community that was well invested into creating these artificial pancreas systems.
[33:21.060 --> 33:31.840]  And they were integrating and working. So the manufacturers, Dana RS, actually worked with Android APS. So there was that nice sort of community overlap.
[33:31.840 --> 33:43.300]  And of course, when the hack happened, and there's some remediation processes and steps, this caused a disconnect with the community, because there needs to be a rework, right?
[33:43.300 --> 33:49.580]  There needs to be a manufacturing community sitting down to understand, well, how could these two things still continue to work together?
[33:49.920 --> 34:01.120]  And so I have some thoughts about this. I'm going to put them forward for everyone watching our panel to also formulate their own opinions and hopefully come up with some stuff in the Q&A.
[34:01.120 --> 34:11.720]  Before I do that, I just want to make a public service announcement. Everyone in this panel supports the DIY diabetics community, their hard work, their dedication, and just advancing the technology.
[34:11.720 --> 34:22.680]  I mean, wow, these artificial systems, like regulatory barriers, have really caused this to not be a thing. And I think the DIY community just pushed so hard to make it happen. So that's great.
[34:22.680 --> 34:37.900]  To give everyone else that's listening an idea, I've cribbed some data from the OpenAPS website. And as of May of 2020, there's at least almost 12,000 people reporting to use these DIY systems.
[34:37.900 --> 34:43.600]  And these are just people that actually report that they're using the system. It doesn't cover people that are not reporting, for example.
[34:43.600 --> 35:02.400]  And if we take a look at the graph that I've also cribbed from OpenAPS, we see that there's this nice reduction in A1Cs, which if you're a diabetic, your target A1C, you'd want it to be closer to six. It's indicative of just better overall health outcomes.
[35:03.860 --> 35:06.740]  So now I pivot to the next point.
[35:06.740 --> 35:19.460]  The current DIY community has leveraged vulnerabilities, quite frankly, of insulin pump devices to be able to construct their solutions.
[35:19.460 --> 35:38.200]  Simply to say, they've used insulin pumps that have open and known vulnerabilities that have been well known, such that they could use that system and bootstrap on some applications and some back-end servers and a communication protocol to make their systems function.
[35:38.200 --> 35:47.520]  And so this is worrying from a cybersecurity professional's perspective because its foundation is built on antiquated hardware. It's no longer supported by the manufacturer.
[35:47.520 --> 36:01.140]  Outdated firmware, insecure reverse-engineered device communications, and in some cases even requires hardware adapters or shims, so another device, to be able to send and receive communication.
[36:01.140 --> 36:09.980]  And so this DIY solution, while it was great when it first came out, it lacks a formalized threat model.
[36:10.000 --> 36:18.720]  I haven't seen anywhere in the community yet where someone went through the steps of providing, say, Stride and understanding all the risks.
[36:18.900 --> 36:21.940]  And let me also put a caption on that.
[36:21.940 --> 36:31.120]  I have talked to the community before, and one of the colleagues or people in the community said, well, we do understand the risks, and that's fine.
[36:31.120 --> 36:40.260]  But at the same time, I want to just kind of elevate that, so that way we can understand, okay, we get it, there are security risks, what's the best way forward?
[36:41.020 --> 36:53.320]  And I think the best way forward is definitely to work with manufacturers, like the manufacturer of the Dana-RS, and not to continue to rely on these insecure foundations and antiquated systems.
[36:55.160 --> 37:03.080]  So, as I alluded to, this is not late-breaking news. The DIY community knows about these issues, and we can actually see it pretty easily.
[37:03.080 --> 37:11.420]  So, if you go to OpenAVS's website and you pull their architecture diagram, well, this is more of a data flow, but if you pull this particular diagram,
[37:11.420 --> 37:26.780]  the first thing we note, which I have denoted in the red thatched rectangle, is that the models of Medtronic devices that they require are old hardware that Medtronic no longer supports, the 512, 515, and 522 models.
[37:26.780 --> 37:40.820]  Furthermore, if you have their newer equivalents, you actually have to rely on outdated firmware, because what happens, Medtronic patched the vulnerabilities that allowed the device communication to happen unauthenticated in the first place,
[37:40.820 --> 37:47.900]  and therefore, you can only have the older version of the software in the device to be able to integrate it into this open solution.
[37:49.160 --> 38:05.760]  Furthermore, as a sort of a side point, there's also a look on Craigslist to find medical devices, which always kind of makes me worried, eBay and Craigslist medical devices, but I'll leave that there. I'm a cybersecurity person, not a medical person, so I have no advice for that.
[38:07.120 --> 38:16.740]  Kind of furthering the point on, if you're not well aware of the Medtronic devices that I enumerated, there's an ICS medical advisory on these particular devices.
[38:16.740 --> 38:29.620]  And as you can see, this was released, what, 2019, but it covers a large number of Medtronic pumps, of which OpenAPS uses some of those devices to implement their system.
[38:32.140 --> 38:45.420]  So, I wanted to take an additional step. It's one thing to look at the architecture and the data that's already available, provided by the community, but I also wanted to understand, the source code was open and available.
[38:45.420 --> 38:53.320]  So, I wanted to run a stack analysis against the source code to kind of understand what vulnerabilities may exist there.
[38:53.320 --> 39:02.120]  Now, as an aside, and it's to all the security people, yes, we all understand that stack analysis tools give false positives and false negatives.
[39:02.120 --> 39:11.240]  It really comes down to the security professional taking the time to follow up and understand if those are actual weaknesses and vulnerabilities.
[39:11.240 --> 39:17.180]  That being said, I was able to quickly use SonarQube, which is freely available, they have a community edition.
[39:17.340 --> 39:25.700]  Scan the OpenAPS source code that's also available and open on GitHub, and to be able to identify some security hotspots.
[39:26.240 --> 39:36.040]  And in particular, there are a number of high vulnerabilities with respect to command injection, because there's a large number of Python and shell scripts that take inputs from the command line.
[39:36.040 --> 39:41.200]  And these things are not being adequately validated or verified, so there's no input sanitization.
[39:41.240 --> 39:58.560]  And because these scripts and code are executed as a root user, if an attacker was to take advantage of this vulnerability, this weakness, they could achieve root access on the devices that make up the OpenAPS system.
[40:00.460 --> 40:09.040]  So to understand that a little bit better, OpenAPS just happens to be one of the systems that involves one of those shims or adapters that I talked about.
[40:09.040 --> 40:16.900]  And in particular, they're using a Raspberry Pi. Now, the Raspberry Pi is this nice single board computer, but it has a lot of different interfaces.
[40:16.900 --> 40:25.280]  It has a wireless interface and Bluetooth so that it can communicate over the network, which makes a great adapter to make an OpenAPS type of system work.
[40:25.440 --> 40:30.720]  But it comes with additional properties that shouldn't really exist here.
[40:30.720 --> 40:36.480]  It has a full Linux operating system, which comes with all the complexities of managing the security of an operating system.
[40:36.480 --> 40:44.320]  For example, firewall configuration or managing access and server service level accesses to files and data.
[40:45.180 --> 41:00.460]  And it requires remote access or root remote access just to function. And so this is usually the security 101 things that we'll talk about and say, well, you should never allow root remote access. And it just so happens it's a system, you know, you need to leverage it to make it function.
[41:01.700 --> 41:09.780]  So to wrap up all of what I was saying about the DIY community and, you know, hacking and efforts from Julian's team, etc.
[41:09.960 --> 41:20.440]  Is that what's nice is that DIY started it and they had these solutions and they were using pumps and whatever they could to meet their ends. And that's fantastic. They really pushed the envelope.
[41:20.440 --> 41:35.140]  But now we're seeing manufacturer involvement, where they want to be able to expose secure interfaces to help leverage this communication to do it in a way that's going to mitigate, say, remote attacks or eavesdropping, man in the middle, etc.
[41:35.140 --> 41:44.500]  And I think that I would like for there to be a larger conversation with regulators, policymakers, manufacturers, and of course the community.
[41:44.500 --> 41:59.660]  I think this is already happening because, you know, I can't be well aware of all the conversations, but, you know, they're, they're just very straightforward foundational issues with the stuff in the past. And I'm really hopeful that going forward. There's just a better answer and a better solution.
[42:01.280 --> 42:07.680]  All right. With that, I will leave some concluding remarks to Dina for the MoneyMed release.
[42:07.680 --> 42:19.740]  Yeah, thank you very much. So here comes a small teaser about our MoneyMed release, because the insulin pump is actually not the only product that was assessed during the scope of the project.
[42:19.760 --> 42:25.520]  So our project results will be published in German and English in December 2020.
[42:25.520 --> 42:43.400]  And I hope you're all waiting for this. So our final report will include the findings presented here. And as I said, those from the remaining devices, but not on a technically deep level. Why? Because we want to allow basically everyone to read and understand our project results.
[42:43.400 --> 42:53.880]  All manufacturers have to review or can review their respective sections prior to our publication and decide whether to be named.
[42:53.880 --> 43:03.820]  In the final report, we will demonstrate how we cooperated with different manufacturers and dealt with individual vulnerabilities and their disclosure.
[43:03.820 --> 43:18.620]  And this report will provide and probably inspire you with our lessons learned. And the overall intention, as I already said, is to improve cybersecurity without finger pointing at anyone or anything.
[43:18.840 --> 43:33.620]  We want people to get a feeling for vulnerabilities and to ideally have a sustainable effect on the cybersecurity of medical devices with our project. And we are willing to do more research in that field. Thank you.
[43:36.070 --> 43:48.010]  And I'll conclude with some future research. The entire team, our panels, are interested in contributing to security as a software development lifecycle best practices to the DIY community.
[43:48.010 --> 44:01.410]  Also just understanding threat modeling those devices in the DIY community as well. And pursuing additional medical device research. So it may not be just diabetes technology, as Dina pointed out.
[44:01.410 --> 44:10.330]  But just holistically all medical devices, especially ones that are connected or network connected. And with that, we would like to take some questions.