WEBVTT 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:12.500 Hi, I'm Dina Truxius. 00:12.500 --> 00:16.480 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:29.940 I'm Julian. 00:29.940 --> 00:33.700 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:44.520 And hey, I'm Mike Christianen. 00:44.520 --> 00:48.000 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:48.160 Thank you. 01:48.160 --> 01:59.580 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:42.500 We fulfill all our legal obligations. 02:42.500 --> 02:43.960 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:12.780 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 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:21.880 The BFARM is comparable to FDA. 03:21.880 --> 03:25.340 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:02.220 We believe we can and we do care about it. 05:02.220 --> 05:12.980 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:16.120 We know that it is not a matter of getting hacked. 05:16.120 --> 05:19.680 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:18.890 These are the following. 08:19.250 --> 08:24.290 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:45.450 So, after picking the respective devices, we tried to get in contact with the top manufacturers found in our market research, explained our intention to pentest the respective devices, and ideally ended up with a signed testing contract. 08:45.450 --> 08:59.370 With this, the manufacturers provided us with the respective medical devices and lab environments, and in return, they received exclusive knowledge about their security state in the devices. 08:59.510 --> 09:09.290 After the security assessment, the manufacturers are provided with a detailed report about all findings, 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:24.670 The project aims to increase transparency and awareness. 09:24.670 --> 09:36.350 Additionally, the trust for communication and cooperation among all stakeholders, 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:51.150 We believe that the project results aimed to be published in December will allow for cyber security statements, 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:52.630 Medical devices are actually classified in three bins. 10:52.630 --> 10:54.370 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 --> 12:05.430 And sort of as the rigor in the submission, some of the steps, if I could elucidate them quickly, my team and the manufacturers look to specify all the cyber security threat models, understanding what threats are to their systems, laying bare and plain the architecture and data flow, 12:05.430 --> 12:17.530 enumerating harm and non-harm risk to patient safety, and then identifying, implementing, and analyzing any potential mitigations that the system can possibly implement 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:24.310 They exist now. 12:24.310 --> 12:29.850 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:09.250 So to get us started, I'm going to provide a brief background for insulin pump devices in general, 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:10.460 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, 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:18.520 There's a system on chip design. 14:18.520 --> 14:20.260 Typically, this is ARM based. 14:20.260 --> 14:22.820 It has a Bluetooth radio. 14:22.940 --> 14:28.140 The idea of the Bluetooth radio is such that we can pair two separate devices speaking the same protocol. 14:28.200 --> 14:33.720 It's typically uses low energy because the pump itself is worn on the patient. 14:33.720 --> 14:35.280 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:47.520 Different pairing connections are supported. 14:47.520 --> 14:49.800 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:15.940 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, 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:29.160 So just to be completely encompassing, another step that my team at Harper Labs really likes to take, 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:43.040 This is where security gets real, because we want manufacturers and the community to understand, well, what is the absolute goal of attacking an insulin pump, for example? 18:43.040 --> 18:44.560 Well, it's to cause patient harm. 18:44.560 --> 18:54.520 If that is really the focus, whenever we're looking at a medical device, 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:05.140 Mirai botnet would be a great example. 19:05.140 --> 19:07.180 That's just trying to pivot into the network. 19:07.180 --> 19:18.420 And so if we're not securing our medical devices that are essentially network endpoints, we may allow a pivot into the network, and then any other unexpected behavior that might come of that, 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:38.860 I also wanted to point out, too, in terms of capabilities, since this is BLE, 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 --> 20:04.400 We have our wireless interface, which is communication that's happening over Bluetooth, 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:09.140 So what can the application tell you? 20:09.140 --> 20:10.540 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:25.220 Thanks. 20:25.320 --> 20:35.860 In the following minutes, I will explain the communication protocol of the Dana Diabica RS insulin pump, which is sold by the Korean manufacturer Soil Developments, as well as vulnerabilities we identified. 20:35.860 --> 20:49.840 I want to state that the presentation of the vulnerabilities shall not be understood as finger-pointing towards the manufacturer, but may shed light on design problems more manufacturers are facing with building interconnected medical devices. 20:50.080 --> 20:58.700 The manufacturer intends patients to use the pump as a central component of an open-loop system in combination with the respective mobile applications. 20:58.820 --> 21:07.920 With these mobile apps' safety-critical functionality of the pump, such as manual administration of boluses or changing the basal rates of profiles is possible. 21:07.980 --> 21:19.320 Besides, patients are creating less restrictive ways in controlling their therapy devices, 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:47.570 The security assessment of medical devices is highly specialized and is dependent on the device's medical use case, present interfaces, users and their backgrounds, use technologies, but also assumptions, for example, to its environment. 21:47.930 --> 21:56.550 In scope of the test was the proprietary communication protocol between the insulin pump and its mobile applications, 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:11.710 In a special, the assessment focused on the used and implemented cryptography, as well as on the authentication and pairing process between the pump and its mobile apps. 22:11.850 --> 22:24.270 The testing methodology was a black-box test without source code inside, and we were voluntarily provided with two insulin pumps by the manufacturers 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:53.160 We will talk about the names of the keys that are used on the following slides, 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:18.360 And red color is showing that user interaction is needed, 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:40.640 The pump immediately answers the request and shows a pairing prompt on its display, 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:57.440 After having a user confirming the pairing, the pump sends the pairing key to the mobile application, 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:21.200 The next time the pump and the app are communicating, no user interaction is needed, 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:59.380 We omitted the respective formula not to give some more insights on the protocol, because we do not want to have you building exploits for this. 24:59.380 --> 25:12.040 This enables adhocs to extract the lock key PIN, 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:43.020 Having these three occurrences of doubtful calculations of secrets, 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:57.280 Though we wrote a script that requested pairing multiple times a second, and saw that the same key will be returned in a second. 25:57.340 --> 26:07.220 Therefore, we tried multiple combinations of calculations, 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:35.520 How realistic this is with Bluetooth Low Energy is up to you, 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:12.760 This pairing key is the only key that is needed to issue higher privileged commands, 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:20.800 Wow, Julian, thank you for the stunning video. 29:20.800 --> 29:22.960 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:36.900 The manufacturer collaborated at all time with us. 29:36.900 --> 29:43.620 He prepared and provided an update, as Julian already said, and that was rolled out in April 2020. 29:43.620 --> 29:50.700 So the whole process was accompanied by an FSN, which was published on our regulatory's website. 29:50.700 --> 29:57.100 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:02.280 Awesome work, guys. 32:02.420 --> 32:04.400 Especially, I like to see the ink on the napkin. 32:04.400 --> 32:06.280 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:21.340 So I commend the team for great, great effort there. 32:21.340 --> 32:21.880 Great work. 32:21.880 --> 32:22.820 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 --> 32:54.020 And so let me define that first. 32:54.020 --> 32:58.920 Android APS is just open source application that's used to create an artificial pancreas system. 32:58.920 --> 33:01.540 That's where the APS acronym comes from. 33:02.300 --> 33:07.020 And an APS system just delivers insulin injections on the patient's behalf. 33:07.020 --> 33:08.340 So it's completely automated. 33:08.340 --> 33:11.980 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:24.200 And they were integrating and working. 33:24.200 --> 33:29.000 So the manufacturers, Dana RS, actually worked with Android APS. 33:29.000 --> 33:31.840 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 --> 33:52.580 And so I have some thoughts about this. 33:52.580 --> 34:01.120 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:04.220 Before I do that, I just want to make a public service announcement. 34:04.440 --> 34:11.720 Everyone in this panel supports the DIY diabetics community, their hard work, their dedication, and just advancing the technology. 34:11.720 --> 34:18.740 I mean, wow, these artificial systems, like regulatory barriers, have really caused this to not be a thing. 34:18.740 --> 34:21.760 And I think the DIY community just pushed so hard to make it happen. 34:21.760 --> 34:22.680 So that's great. 34:22.680 --> 34:30.200 To give everyone else that's listening an idea, I've cribbed some data from the OpenAPS website. 34:30.340 --> 34:37.900 And as of May of 2020, there's at least almost 12,000 people reporting to use these DIY systems. 34:37.900 --> 34:40.540 And these are just people that actually report that they're using the system. 34:40.540 --> 34:43.600 It doesn't cover people that are not reporting, for example. 34:43.600 --> 34:57.720 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. 34:57.720 --> 35:02.400 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:44.900 And so this is worrying from a cybersecurity professional's perspective because its foundation is built on antiquated hardware. 35:44.900 --> 35:47.520 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 --> 36:58.720 So, as I alluded to, this is not late-breaking news. 36:58.720 --> 37:03.080 The DIY community knows about these issues, and we can actually see it pretty easily. 37:03.080 --> 37:23.880 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, 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, 37:23.880 --> 37:26.780 the 512, 515, and 522 models. 37:26.780 --> 37:42.000 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, and therefore, 37:42.000 --> 37:47.900 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:01.380 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. 38:01.380 --> 38:05.760 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:34.800 So, I wanted to take an additional step. 38:34.800 --> 38:45.420 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:12.400 And in particular, they're using a Raspberry Pi. 40:12.460 --> 40:16.900 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 --> 40:49.920 And it requires remote access or root remote access just to function. 40:49.920 --> 40:55.820 And so this is usually the security 101 things that we'll talk about and say, well, you should never allow root remote access. 40:55.820 --> 41:00.460 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:18.180 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. 41:18.180 --> 41:19.140 And that's fantastic. 41:19.140 --> 41:20.440 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:55.280 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. 41:55.280 --> 41:57.440 And I'm really hopeful that going forward. 41:57.440 --> 41:59.660 There's just a better answer and a better solution. 42:01.280 --> 42:01.600 All right. 42:01.600 --> 42:07.680 With that, I will leave some concluding remarks to Dina for the MoneyMed release. 42:07.680 --> 42:09.560 Yeah, thank you very much. 42:09.560 --> 42:19.740 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:27.900 And I hope you're all waiting for this. 42:27.900 --> 42:31.700 So our final report will include the findings presented here. 42:31.700 --> 42:37.340 And as I said, those from the remaining devices, but not on a technically deep level. 42:37.340 --> 42:37.940 Why? 42:37.940 --> 42:43.400 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:10.640 And this report will provide and probably inspire you with our lessons learned. 43:10.780 --> 43:18.620 And the overall intention, as I already said, is to improve cybersecurity without finger pointing at anyone or anything. 43:18.840 --> 43:28.360 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. 43:28.380 --> 43:32.520 And we are willing to do more research in that field. 43:32.520 --> 43:33.620 Thank you. 43:36.070 --> 43:39.430 And I'll conclude with some future research. 43:39.630 --> 43:48.010 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 --> 43:54.370 Also just understanding threat modeling those devices in the DIY community as well. 43:54.370 --> 43:56.930 And pursuing additional medical device research. 43:56.930 --> 44:01.410 So it may not be just diabetes technology, as Dina pointed out. 44:01.410 --> 44:07.710 But just holistically all medical devices, especially ones that are connected or network connected. 44:07.710 --> 44:10.330 And with that, we would like to take some questions.