 In this talk, DIY Diabetics and a Million Bolses, we are three panelists that are going to discuss a common topic related to insulin pump hacking and its global impact. Hi, I'm Dina Troxios. I'm working for the Federal Office for Information Security in Germany. And my work mainly focuses on medical device cyber security on all cyber security related health on project management standardization and a lot of comedy work. I'm Julian. I'm a security analyst and researcher at E&W Research in Germany. And I perform cyber security assessments of medical devices, medical environments, and I'm having a deep dive into medical communication standards. And hey, I'm Mike Ruschanen. I'm the director of medical security at Harbor Labs. I perform cyber security assessments of medical devices for a number of manufacturers and a number of different medical devices. And I focus on software, medical firmware, and device communication protocols, especially cryptography. So for our agenda today, our panel will introduce medical device cyber security practices and projects are in Germany and the US. We'll provide a background for insulin pump technology and we'll define a formal threat model for insulin pumps. Here we will demonstrate an insulin pump attack and describe the response remediation effort. 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. Lastly, we'll conclude with some remarks from the team. So to kick us off first, we'll have Dina covering the global medical device cyber security. 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 cyber security. The schematic drawing intends to show a very simplified version of the complete German federal government. In Germany, you see below the gray field, we have various ministries. The two important ones are for now folded out. On the left, you see the federal ministry of the interior building and community. And on the right, you see the Ministry of Health. My employer, the federal office for information security is the authority under the ministry of the interior on the left. We are the German cyber security authority and fulfill comparable tasks like DHS and CISA. We fulfill all our legal obligations. We have our own cert. We are experienced in coordinated vulnerability disclosures and in projects. Our legal mandate allows us to assess basically any IT device. 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 office, by the Federal Institute for Drugs and Medical Devices, the Bayfarm. This authority carries out all regulation with regards to medical devices. The Bayfarm is comparable to FDA. They deal with safety and vigilance issues. Whenever any incident is reported in medical devices, the Bayfarm gets active and uses its established processes. We are working closely together with Bayfarm and our health ministry, and for sure our authority in all terms of medical device cyber security. So the Federal Office for Information Security, the BSI, which stands for Bundesamt für Sicherheit in Informationstechnik, it's a German abbreviation, is a thought leader in cyber security. We were already founded in 1991 and we enormously expanded within the last year, and today we have more than 1,300 employees in total, mostly IT specialists and natural scientists. The federal government in Germany realizes and still sees the need to have a functional national cyber security authority. So we are covering all fields of work with respect to cyber security from A to Z, from autonomous vehicles over medical devices to the Zoom app. We are cooperating with national, EU, international authorities and stakeholders, and our budget is invested in various cyber security projects, and I'm really keen to give you some more insights during this talk. So our overall mission is to cover all issues related to cyber security and to make the world more secure. 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. We know that it is not a matter of getting hacked, it will happen anyway and everywhere at one point, 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. In order to fill some of our legal obligations and to increase the awareness towards cyber security, we regularly publish technical guidelines and recommendations. In the field of medical device cyber security, we publish a recommendation about cyber security requirements for network connected medical devices in 2018. This is available in German and English and it is defining best security practices. This publication is in accordance with national and EU-wide regulation requirements and cyber security is seen as a continuous process throughout the product lifecycle. Apart from this, this document can assist in terms of risk analysis. So my cyber security requirements to go for you. When we look at cyber security and discovered vulnerabilities in medical devices, we definitely have to consider and have to discriminate between the modes of action. There is a huge difference between the medical operation and the technical maintenance mode, for example in terms of privileges and authentication. My cyber security to go message for you is that the required security updates and measures must not have a negative impact on safety. And not every vulnerability has an impact on patient safety, but it is possible. Now I'm talking about our project Money Meets. 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. So I asked myself what can be done and what has been done so far. And the idea of a medical device hacking project came into my mind. I made use of our budget, entertained myself with paperwork and tendered the project Money Meets, which stands for manipulation of medical devices. The project started in 2019 and will end in December this year. The project aims to assess the current cyber security state of medical devices and it aims to bring cyber security researchers like Mike and Julian, manufacturers and authorities like me to a table. I chose five different device categories, namely ventilators, patient monitors, ICTs and their environment, infusion pumps, and last but not least, insulin pumps. Out of each category, we aim to assess two devices, so in total 10 devices within the scope. To further restrict our market research, I asked for additional requirements when picking the devices. These are the following. First, the devices had to be no longer than five years on the German market. Second, and should be highly connected, having as many interfaces as possible for an appropriate attack surface. 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 pen test the respective devices and ideally ended up with a signed testing contract. 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 and the devices. After the security assessment, the manufacturers are provided with a detailed report about all findings and a subsequent coordinated vulnerability process is initiated. All findings are published as soon as the vulnerabilities are fixed. We recommend to use ICS-MAs and closely collaborate with CISA and we recommend to assign CVEs. The project aims to increase transparency and awareness. 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. We believe that the project results aimed to be published in December will allow for cybersecurity statements, as well as addressing certain questions and problems. Basically, everyone is facing in the field of smart medical devices. 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. When we will demonstrate these findings. Please be aware that I make use of my legal mandate to inform about important security updates. My intention is to improve cybersecurity without finger pointing at anyone or anything. I want people to get a feeling or better to say a six sense of cybersecurity sense for vulnerabilities. I think that's really helpful to understand BSI and serve your goal and your project and your aims. From the US side, we have FDA cybersecurity guidance that's in place. In particular, we have guidance for medical devices before they can be marketed. They have to have this pre market evaluation. The strictness of controls that are a part of this evaluation are determined by the risk to patient safety. Medical devices are classified in three bins. In terms of risk, this is the lowest to highest, three being the highest. With respect to cybersecurity analysis, my team focuses on class two and class three. These devices have network interfaces to communicate with other end points. They are communication patient data and furthermore, they are actuating which might be to deliver a medicine. Depending on the classification of the device, the pre market process, there's two specific processes that are taken. If it's a class two, you would submit a 510K pre market notification. If it's a class three, you would submit a PMA or pre market approval. Both of these submissions have cybersecurity requirements. I've actually worked with a number of clients to create these submissions and sort of as the rigor in the submission, some of the steps, if I could elucidate them quickly by team and the manufacturers look to specify all the cybersecurity threat models, understanding what threats are to their systems, laying bare and plain the architecture and data flow, enumerating harm and non harm risk to patient safety, and then identifying and implementing and analyzing any potential mitigations of the system can possibly implement to reduce the risks and vulnerabilities in the systems overall. And what's nice, the really nice takeaway here is that the FDA does have post market management recommendations. They exist now. I think that we could definitely learn from BSI approach, especially since we're in the recommendation phase. I'm not a regulator and just a security person, but I think this is a really great conversation to have. And that's where I see the crossover. So for today, that all that said, our major focus is going to be on insulin pumps. And so for for hacking and some of the community efforts and regulatory efforts, we will specifically focus on this type of medical device. As I 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. So, to best describe this Bob's going to help me out. So Bob has type one diabetes. And Bob uses an open loop insulin delivery system to manage this condition. So it's open loop in that Bob is the person actually presses the button. The system is comprised of continuous glucose monitor typically CGM. That's the acronym for that insulin pump and smartphone. So what's unique and interesting here is that we have a communication interface that's wireless between the insulin pump and the smartphone so they pair and that's over BLE. In terms of data flow, the common architecture is that logs can be sent from the insulin pop to the phone. Demands can be sent from the phone to the insulin. 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. So this is it looks, it's a very common architecture that computer security professionals are familiar with. The system on chip design, typically is arm based. It has a Bluetooth radio. The idea of the Bluetooth radio is such that we compare two separate devices speaking the same protocol. It's typically uses low energy because the pump itself is worn on the patient, we can't just connect it to a wall so we don't have, I don't know 240 volts keep it powered. And so it's, you know, that's what motivates our selection of the communication protocol. So we're comparing connections are supported. So we have legacy connections or secure connections. Hopefully most of our manufacturers are leaning towards secure connections. Furthermore, there is no it's bare metal, no operating system. So there's a you typically might have a bootloader but the rest of it is just instructions such that the pump can actually and also receive data and send data. So connecting into the other components are understanding what the other assets are the system of course we have our patient. There's a catheter that connects to the patient that delivers the insulin. And then of interest from security perspective we have the smartphone and the pump and as I've just said that connections over BLE. So let's start thinking about this in the terms of cybersecurity. Let's think about the threat model right. So, first, when we're thinking insulin pumps, we have to understand what the patient harm and non harms are. A patient harm is that the pump delivers too much insulin or maybe not enough insulin. And this could be detrimental to the overall health of the patient. And that's considered a patient's harm safety risk. Non harm would be the pump insulin pump leaks some private information about the user to an unauthorized user say maybe it's this passive ease dropper that's listening on the Bluetooth communication. And that would be considered a non harm risk to the patient. But what security researchers do when we're looking at medical devices is that we always apply a threat model approach to understanding what all of the risks are to, you know, the particular device. And so what I'm using or what I'll detail here is something called Microsoft stride, and it's a way to categorize risks, and I've applied it to the general insulin pump case. So first we have spoofing, which is to impersonate a system and a smartphone to a or excuse me, and an insulin pump case, the attacker can masquerade as a valid smartphone that would be a spoofing based attack that we would want to consider. We also have tampering which is modifying data or code. And this particular case and attacker man in the middle is the pump to smartphone communication. And so we have impudiation claiming to not have performed in action. And so imagine the scenario where an attacker has successfully meant middle communication between smartphone and insulin pump, and they're able to say inject commands. Well the pump is unaware because these are unauthorized unauthenticated commands that they can't distinguish between if it was valid or not. And so the, 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 sense. And in stride we have information disclosure. This is exposing information to unauthorized users. So in this particular case we can imagine an attacker that use drops on pump to smartphone communication. They're not looking to inject commands simply see what information they can see going across the wire. Next we have denial of service which is to deny or degrade access I would say this is a bane of cyber security professionals. This is really hard to protect against expected if it's directed. And then the insulin pump case this is where the attacker overruns the pump with requests, which would deny the valid or authenticated user from using the pump as it's intended. Lastly we have elevation privileges, which is to gain access to unauthorized capabilities. 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, that application interface, and then directly impacting the pump operation itself. 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. And the idea here is to understand the attackers goals and capabilities this is where this is where security gets real. Because we want to, we want manufacturers and the community to understand well what is the, what is the absolute goal of attacking an insulin pump for example. And patient harm, if that is really the focus it's you know when we whenever we're looking at medical device, we're trying to find vulnerabilities that could actually impact the patient and their safety. Now, also, an attacker could be say just this arbitrary software execution like malware, mirai botnet would be a great example that's just trying to pivot into the network. And then 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. Of course we have to consider things like the position of the attacker in the system, are they an insider manufacturer that knows all the glory details, are they simply just a personally outside with a high gain antenna and some equipment. And I wanted to point out to you in terms of capabilities and since this is BLE, we're looking at maybe 300 us dollars in terms of the le hacking equipment. And I'll summarize quickly because that visuals are the best way to depict this, there are a number of attack surfaces that exist and our general insulin pump model. We have our physical interface being able to connect to serial or press buttons. We have our wireless interface which is you know communication that's happening over Bluetooth, which Julian will talk in depth about as the attack surface that he focused on. And he also focus a bit on the app interface so what can the application tell you what can you learn from it, you know this is another attack surface that an attacker could leverage to compromise and excuse me, an insulin pump. And so with that, I'll turn it over to Julian to talk about insulin pump hacking. Thanks. In the following minutes, I will explain the communication protocol of the Donna and I be care RS insulin pump which is sold by the Korean manufacturer soil developments as well as vulnerabilities we identified. 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 these problems more manufacturers are facing with building interconnected interconnected medical devices. The manufacturer intends patients to use the pump as a central component of an open loop system in combination with the respective mobile applications. With these mobile app safety critical functionality of the pumps such as such as manual administration of boluses or changing the basal rates or profiles is possible. Besides, patients are creating less restrictive ways in controlling the three or P devices as for example that we are not waiting initiative demonstrated in the past by building close to systems on their own. We will come back to this later in the talk I think, and further the Donna beer. Diabica RS insulin pump is supported by publicly aware that looping apps such as Android APS. The security assessment of medical devices is highly specialized and is dependent on the devices medical use case present interfaces users and their backgrounds using use technologies but also assumptions for example to its environment. In scope of the test was the proprietary communication protocol between the insulin pump and its mobile applications, which was built on top of blue to flow energy and so the blue to flow energy capabilities were just used to implement some application layer protocol. 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. 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. I will first demonstrate the normal communication flow we observed between the pump and its mobile applications. We will start with the application layer pairing process. The first by it demonstrates whether the message is a request with zero one or a response with zero two. We will talk about the names of the keys that are used on the following slides so don't hesitate to to identify all the keys and understand a usage so we will come to this. In similar figures with presented different encryption layers with different colors. So yellow colors dates that this information is transmitted in plain blue color shows that the message it's need to be encrypted using the device key and red color showing that user interaction as as needed, as well as green color indicates that messages need to be encrypted using free keys. Every communication starts with the mobile app sending a zero one zero zero message. To the pump together with zero number. The pump indicates that the series matching and afterwards the parent is requested. 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. A photo of this is pairing prompt can be seen here. By using a user confirmation confirming the pairing, the pump sends the parent key to the mobile application, which then they use the key to encrypt messages after requesting a session key with these three keys higher privileged requests such as for now the three keys may be a bit confusing. I believe that it comes way more clear when seeing the post pairing communication flow. The next time the pump and the app are communicating no user interaction is needed as the app only needs to send the parent key to show that both entities are already already paired. After requesting a new session key high privileged requests can be sent. Here we see the three keys again. The device keys used to encode all messages, the parent key and the session key are used to authenticate the session, which is showing green. An interesting find words that the communicating party does not need to be paired to extract the pin. This is shown in the next slide. The pin is not directly transmitted but can be calculated with the information transmitted. 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. This enables attackers to extract the lock key pin and every Dana RS pump in the attacker's range, Bluetooth range, is possible to be read out. The next finding we want to elicit data about is about weekly generated encryption keys. The device keys derived from the pump serial number does not contain any randomizing element and will never change. The serial number can be obtained from Bluetooth energy advertisements. The session key can be calculated from the pumps lock pin as well as configured time. We saw the respective requests on the previous slide with the pin disclosure. Having these three occurrences of doubtful calculations of secrets we further investigated all the other keys and recognized that also the parent key is not random. This key is calculated on the pump so we have no ability to reverse this calculation. Though we wrote a script that requested pairing multiple times a second and saw that the key will be returned, that the same key will be returned in a second. 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. So it's fixed as the key is calculated from the time of the pairing. As a result, any secret of the data arrest system is generated insecurely. In addition to the lock pin disclosure and active verification of the pump's identity is present. Therefore, attackers can spoof both communication partners and therefore get in the middle position. How realistic this is with Bluetooth energy is up to you because I want to present a more easy attack later. Another example is the missing replay protection. High checking the Bluetooth flow energy session, attackers may replace sniffed messages. But still the most easy way to issue trusted commands is to capture a single communication flow between the pump and an app. We will get into this on the next slide. As we already have seen, the whole authentication mechanism relies on encryption using multiple keys. 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. 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. This encryption is completely deterministic and everyone sniffing the communication is able to extract this key. We will not show what encryption works in detail. 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. The communication of the vulnerabilities in the communication protocol empowers attackers to high check the pump and use all functionalities that are offered via Bluetooth flow energy. 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. This attack can be performed automatically in productive environments and we want to demonstrate this. The manufacturer prepared an update for the pump fixing the vulnerabilities, but let us first have the demo. Now I'd like to present you the attack of in a short video demonstrating the criticality of the automated attack. A few words I needed to explain the video. In the following video, an attacker captures messages between an insulin pump and mobile app and extracts the key from this communication. The 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. I was just clicking on a pump to reactivate the display so there's no need to have this interaction at this point. The patient may notice the administration and is able to cancel the single administration on the pump. But as you can see in the following, more boluses are following. I filled the whole tubing system with blue inks so you can see this that in real life, this would have been insulin. And as you can see, the patient is trying to cancel all the administrations one after another, but just another administrations will follow this until the ethical stops. Wow, Julian, thank you for the stunning video. I'm always impressed when I see it. So when we now draw a conclusion from what we just heard, we can state that most of the vulnerabilities found our design defects. The manufacturer collaborated at all time with RC prepared and provided an update as Julian already said, and that was rolled out in April 2020. So the whole process was accompanied by an FSN which was published on our regulatory's website and example of this from a UK regulatory authority in English is shown on the right. 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. As mentioned in the FSN, the device can be securely operated when the airplane mode is enabled thereby preventing its functionality. Moreover, the device has several safety features already implemented preventing from misuse. In summary, the pump could be used when the airplane mode was enabled to prevent potential risk when we discovered these vulnerabilities. But I guess you're not only interested in the disclosure itself, but in the timeline. So as stated before, we aim to live cyber security and act accordingly. In our opinion, coordinated vulnerability disclosure process is desired whenever findings are reported. We use usually 90 days and give an extension upon a justified reason. Julian, me and our team colleagues managed and coordinated the whole disclosure process. We believe that it's essential to identify vulnerabilities and medical devices in an ethical way to strengthen cyber security, consumer protection and patient safety. Thereby, we all maintain a basis of trust to allow for mutual exchange and efficient communication. As mentioned before, I have no intention to blame anyone here. As a project team, we believe that ethical publishing of vulnerabilities is possible. They have an increasing transparency and the willingness to update devices in time. However, it has to be ensured at all time that the publication does not pose serious harm to patients. In our case, shorter measures and workarounds exist and existed and an innovative device was not withdrawn from the market. I believe that security and safety are not contradicting each other and that secure connected devices are pioneering. Awesome work guys, especially like to see the ink on the napkin. Every time I see it so amazing. 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. So I commend the team for great, great effort there, great work, great job. With that, I'm going to segue the remainder of the talk into the impact of hacking on DIY diabetic community. 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. And that remediation effort had caused some issues with Android APS compatibility. So let's 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. And in our 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. Now there's an entire open source and DIY diabetic community that was well invested into creating these artificial pancreas systems. 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. And of course, if it went 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 there needs to be manufacturing community sitting down to understand well how could these two things still continue to work together. 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. Before I do that, I just want to make a public service announcement. Everyone in this panel supports DIY diabetics community, their hard work, their dedication, and just advancing the technology. I mean, wow, these artificial systems like regulatory barriers had 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. To give everyone else that's listening an idea. I've crib some some data from the open APS website. And as of May of 2020, there's at least almost 12,000 people reporting to use these DIY systems. And these are just people that actually report that they're using the system it doesn't cover people are not reporting for example. And if we take a look at the, the graph that have also crib from open APS, we see that there's this nice reduction in a one C's, which if you're a diabetic, your target a one C, you'd want it to be closer to six is indicative of just better overall health outcomes. Now, I pivot to the next point. The current DIY community has leveraged vulnerabilities, quite frankly, of medical or insulin pump devices to be able to construct their solutions. 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 in servers and communication protocol to make their systems function. So this is worrying from a cyber security or professionals perspective because its foundation is built on antiquated hardware, that's no longer supported by the manufacturer 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. And this DIY solution, while, you know, it was, it was great when it first came out, you know, it lacks a formalized threat model. I haven't seen any anywhere in the community yet where someone went through the steps of providing say stride and understanding all the risks. And let me also put a caption on that. I have talked to the community before and a one of the colleagues or people in the community said well, we do understand the risks, and that's fine. But at the same time, I want to just kind of elevate that so that way we can understand okay. There are security risks, what's the best way forward. And I think the best way forward is definitely to work with manufacturers like the manufacturer of the data RS, and not to continue to rely on these insecure foundations and antiquated systems. So as I alluded to this is not late breaking news. The IOI community knows about these issues, and we can actually see it pretty easily so if you go to open APS's website and you pull their architecture diagram. Well, this is more of a data flow but you pull this particular diagram. The first thing we know, which I have denoted in the red that rectangle is that the models of metronic devices that they require are old hardware that's no longer metronic no longer supports the 512 515 and 522 models. Furthermore, if you have their newer equivalents, you actually have to rely on outdated firmware, because what happens metronic patch the vulnerabilities that allowed the device communication to happen unauthenticated in the first place. And therefore you can only have the older version of the software and the device to be able to integrate it into this this open solution. So as it's sort of a sad point there's also look on craigslist to find medical devices which always kind of makes me worried eBay and Craig list medical devices. But I'll leave that there. I'm cybersecurity person not a medical person so I have no advice for that. Kind of furthering the point on you might if you're not well aware of the metronic devices that I enumerated. I have a full advisory on these particular devices. And as you can see, you know this this was released what 2019 but it covers a large number of metronic pumps, of which open APS uses some of those devices to implement their system. So, another I wanted to take an additional step it's one thing to look at the architecture and the data that's already available. I wanted to understand the community but I also wanted to understand the source code was open and available. So I wanted to run a stack analysis against the source code to kind of understand what vulnerabilities may exist there. Now, you know, as a side, and it's still the security people. Yes, I, we all understand that stack analysis tools give false positives and false negatives. This really comes down to the security professional taking the time to follow up and understand if those are actual weaknesses and vulnerabilities. That being said, I was able to quickly use sonar cube, which is freely available to have a community edition scan the open APS source code that's also available and open on GitHub, and to be able to identify some security hotspots. 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. And these things are not being adequately validated or verified so there's no input sanitization. These scripts and code are executed as a root user. If you an attacker was to take advantage of this vulnerability this weakness, they could achieve root access on the devices that make up the open APS system. So to understand that a little bit better. Open APS just happens to be one of the systems that involves one of those shims or adapters that I talked about. 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 it has a wireless interface and Bluetooth so that it can communicate over the network to makes a great adapter to make an open APS type of system work. But it comes with additional properties that you know shouldn't really exist here as a full Linux operating system, which comes with all the complexities of managing the security of an operating system. For example, firewall configuration, or managing access and server service level accesses to files and data. 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 route remote access, and it just so happens is the system, you know, you need to leverage it to make it function. And to wrap up all of what I was saying about the DIY community and you know hacking and efforts from Julian's team, etc. 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. They were using manufacturing 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 ease dropping men in the middle, etc. And I think that I would like for there to be a larger conversation with regulators policymakers manufacturers and of course the community. It's not 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. All right, with that, I will leave some concluding remarks to Dina for the many med release. Thank you very much. So here comes a small teaser about our money made release because the insulin pump is actually not the only product that was assessed during the scope of the project. So our project results will be published in German and English in December 2020. 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. Because we want to allow basically everyone to read and understand our project results. All manufacturers have to review or can review their respective sections prior to our publication and decide whether to be named. In the final report we will demonstrate how we cooperated with different manufacturers and dealt with individual vulnerabilities and that is closure. 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. 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. We are willing to do more research in that field. Thank you. Yeah, and I'll conclude just some future research. You know, the entire team are panels interested in contributing to security as a software development lifecycle best practices to the DIY community. Also just understanding threat modeling those devices in the DIY community as well and pursuing additional medical device research. So you need not be just diabetes technology as Dina pointed out, but just holistically all medical devices, especially ones that are connected or network connected. And with that, we would like to take some questions.