start	end	text
0	11060	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.
11080	16480	Hi, I'm Dina Truxius. I'm working for the Federal Office for Information Security in Germany.
16520	28740	And my work mainly focuses on medical device cybersecurity, on all cybersecurity-related health, on project management, standardization, and a lot of comity work.
28740	33700	I'm Julian. I'm Security Analyst and Researcher at EMW Research in Germany.
33700	42200	And I perform cybersecurity assessments of medical devices, medical environments, and I'm having a deep dive into medical communication standards.
42200	48000	And hey, I'm Mike Christianen. I'm the Director of Medical Security at Harbor Labs.
48220	55380	I perform cybersecurity assessments of medical devices for a number of manufacturers and a number of different medical devices.
55380	62460	I tend to focus on software, medical firmware, and device communication protocols, especially cryptography.
62460	71520	So for our agenda today, our panel will introduce medical device cybersecurity practices and projects in Germany and the U.S.
71520	79160	We'll provide a background for insulin pump technology, and we'll define a formal threat model for insulin pumps.
80160	86620	Further, we will demonstrate an insulin pump attack and describe the response remediation effort.
86720	95440	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.
95880	98920	Lastly, we'll conclude with some remarks from the team.
100680	106120	So to kick us off first, we'll have Dina covering the global medical device cybersecurity.
106920	119580	Thank you. So let me introduce you to the German federal landscape to demonstrate our duties and responsibilities in terms of health and IT security or cybersecurity.
119880	126160	This schematic drawing intends to show a very simplified version of the complete German federal government.
126440	131320	In Germany, you see below the gray field, we have various ministries.
131320	136000	The two important ones are for now folded out.
136040	140800	On the left, you see the Federal Ministry of the Interior, Building and Community.
140860	143380	And on the right, you see the Ministry of Health.
143480	151740	My employer, the Federal Office for Information Security, is the authority under the Ministry of the Interior on the left.
152360	159700	We are the German cybersecurity authority and fulfill comparable tasks like DHS and CISA.
159700	163960	We fulfill all our legal obligations. We have our own cert.
163960	169480	We are experienced in coordinated vulnerability disclosures and in projects.
169720	174680	Our legal mandate allows us to assess basically any IT device.
175220	186960	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
186960	192780	by the Federal Institute for Drugs and Medical Devices, the BFARM.
192780	199040	This authority carries out all regulation with regards to medical devices.
199040	205340	The BFARM is comparable to FDA. They deal with safety and vigilance issues.
205420	212640	Whenever any incident is reported in medical devices, the BFARM gets active and uses its established processes.
212640	221740	We are working closely together with BFARM and our health ministry and for sure our authority in all terms of medical device cybersecurity.
224760	237900	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.
238530	253130	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.
253540	262240	The federal government in Germany realizes and still sees the need to have a functional national cybersecurity authority.
262240	272540	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.
272540	283440	We are cooperating with national, EU, international authorities and stakeholders and our budget is invested in various cybersecurity projects.
283440	287320	And I'm really keen to give you some more insights during this talk.
290520	299000	So our overall mission is to cover all issues related to cybersecurity and to make the world more secure.
299000	312980	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.
312980	319680	We know that it is not a matter of getting hacked. It will happen anyway and everywhere at one point.
319680	329720	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.
332810	344270	In order to fill some of our legal obligations and to increase the awareness towards cybersecurity, we regularly publish technical guidelines and recommendations.
344270	354390	In the field of medical device cybersecurity, we published a recommendation about cybersecurity requirements for network-connected medical devices in 2018.
354430	361090	This is available in German and English and it is defining best security practices.
361090	372430	This publication is in accordance with national and EU-wide regulation requirements and cybersecurity is seen as a continuous process throughout the product lifecycle.
372430	377850	Apart from this, this document can assist in terms of risk analysis.
380070	383690	So, my cybersecurity requirements to go for you.
383690	393190	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.
393190	397550	There is a huge difference between the medical operation and the technical maintenance mode.
397550	400650	For example, in terms of privileges and authentication.
400650	412090	My cybersecurity to go message for you is that the required security updates and measures must not have a negative impact on safety.
412190	417610	And not every vulnerability has an impact on patient safety, but it is possible.
417610	419710	Now, I'm talking about our project money made.
419710	432250	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.
432470	437190	So, I asked myself what can be done and what has been done so far.
437230	441250	And the idea of a medical device hacking project came into my mind.
441250	449930	I made use of our budget, entertained myself with paperwork and tended the project money made, which stands for manipulation of medical devices.
449930	454430	The project started in 2019 and will end in December this year.
454810	460490	The project aims to assess the current cybersecurity state of medical devices.
460910	469330	And it aims to bring cybersecurity researchers like Mike and Julian, manufacturers and authorities like me to a table.
469330	481730	I chose five different device categories, namely ventilators, patient monitors, ICDs and their environment, infusion pumps, and last but not least, insulin pumps.
481930	491210	Out of each category, we aim to assess two devices, so in total 10 devices within the scope.
491210	497450	To further restrict our market research, I asked for additional requirements when picking the devices.
497450	504290	These are the following. First, the devices had to be no longer than five years on the German market.
504590	511810	Second, and should be highly connected, having as many interfaces as possible for an appropriate attack surface.
512650	518730	So, after picking the respective devices, we tried to get in contact with the top manufacturers found in our market research,
518730	525450	explained our intention to pentest the respective devices, and ideally ended up with a signed testing contract.
525450	531630	With this, the manufacturers provided us with the respective medical devices and lab environments,
531630	539370	and in return, they received exclusive knowledge about their security state in the devices.
539510	544870	After the security assessment, the manufacturers are provided with a detailed report about all findings,
544870	549290	and a subsequent coordinated vulnerability process is initiated.
549650	553610	All findings are published as soon as the vulnerabilities are fixed.
553610	560810	We recommend to use ICSMAs and closely collaborate with CISA, and we recommend to assign CVEs.
561170	568850	The project aims to increase transparency and awareness. Additionally, the trust for communication and cooperation among all stakeholders,
568850	576350	which is seen as one of the highest goods in our whole process, and inspired by a classical coordinated vulnerability disclosure.
576350	583870	We believe that the project results aimed to be published in December will allow for cyber security statements,
583870	591150	as well as addressing certain questions and problems basically everyone is facing in the field of smart medical devices.
591150	600310	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.
600310	610090	When we will demonstrate these findings, please be aware that I make use of my legal mandate to inform about important security updates.
610090	616210	My intention is to improve cyber security without finger pointing at anyone or anything.
616210	623430	I want people to get a feeling, or better to say a sixth sense, a cyber security sense for vulnerabilities.
623430	629590	I think that's really helpful to understand BSI and sort of your goal and your project and your aims.
629790	634870	From the US side, we have FDA cyber security guidance that's in place.
634870	640110	In particular, we have guidance for medical devices before they can be marketed.
640290	643390	They have to have this pre-market evaluation.
643870	649350	The strictness of controls that are a part of this evaluation are determined by the risk to patient safety.
649350	654370	Medical devices are actually classified in three bins. We have one, two, and three.
654650	659630	In terms of risk, this is lowest to highest, three being the highest.
660810	667630	With respect to cyber security analysis that my team at Harvard Labs typically focuses on is class two and class three.
667670	673130	These devices have, for example, network interfaces to communicate with other endpoints.
673130	680310	They are communication patient data, and furthermore, they're actuating, which might be, say, to deliver a medicine.
680710	687830	Now, depending on the classification of the device, the pre-market process, there's two specific processes that are taken.
687950	691590	If it's a class two, you would submit a 510k pre-market notification.
691670	696550	If it's a class three, you would submit a PMA for pre-market approval.
697030	701050	Now, both of these submissions have cyber security requirements.
701050	706370	I've actually worked with a number of clients to create these submissions.
706770	713670	And sort of as the rigor in the submission, some of the steps, if I could elucidate them quickly,
713670	721250	my team and the manufacturers look to specify all the cyber security threat models, understanding what threats are to their systems,
722090	728310	laying bare and plain the architecture and data flow, enumerating harm and non-harm risk to patient safety,
728310	733870	and then identifying, implementing, and analyzing any potential mitigations that the system can possibly implement
733870	737530	to reduce the risks and vulnerabilities in the systems overall.
737530	743390	And what's nice, the really nice takeaway here is that the FDA does have post-market management recommendations.
743390	749850	They exist now. I think that we could definitely learn from BSI's approach, especially since we're in the recommendation phase.
749850	755270	I'm not a regulator, I'm just a security person, but I think this is a really great conversation to have.
755270	756890	And that's where I see that crossover.
758310	764090	So for today, all that said, our major focus is going to be on insulin pumps.
764090	776250	And so for hacking and some of the community efforts and regulatory efforts, we will specifically focus on this type of medical device.
778070	784570	So to get us started, I'm going to provide a brief background for insulin pump devices in general,
784570	789250	and also provide a threat model so that way we can start thinking with our security hats.
791090	794030	So to best describe this, Bob's going to help me out.
794030	800090	So Bob has type 1 diabetes, and Bob uses an open loop insulin delivery system to manage his condition.
800090	804010	So it's open loop in that Bob is the person that actually presses the button.
804270	812510	Now, this system is comprised of a continuous glucose monitor, typically CGM, that's the acronym for that, insulin pump, and smartphone.
812510	820950	So what's unique and interesting here is that we have a communication interface that's wireless between the insulin pump and the smartphone.
820950	823430	So they pair, and that's over BLE.
823450	834210	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.
836940	847080	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,
847080	850460	so we have to understand that it is an embedded system at the end of the day.
850540	856940	So this is, it looks, it's a very common architecture that computer security professionals are familiar with.
856940	860260	There's a system on chip design. Typically, this is ARM based.
860260	868140	It has a Bluetooth radio. The idea of the Bluetooth radio is such that we can pair two separate devices speaking the same protocol.
868200	875280	It's typically uses low energy because the pump itself is worn on the patient. We can't just connect it to a wall.
875280	879340	So we don't have, I don't know, 240 volts to keep it powered.
879820	884280	And so it's, you know, that's what motivates our selection of the communication protocol.
884280	889800	Different pairing connections are supported. So we have legacy connections or secure connections.
890000	893480	Hopefully, most of our manufacturers are leaning towards secure connections.
893660	896920	Furthermore, there is no, it's bare metal, no operating system.
896920	904680	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.
905320	911300	In terms of connecting to the other components or understanding what the other assets are in the system, of course, we have our patient.
911300	914540	There's a catheter that connects the patient that delivers the insulin.
914640	918840	And then of interest from a security perspective, we have the smartphone and the pump.
918840	921400	And as I've just said, that connection is over VLT.
924000	927520	So let's start thinking about this in the terms of cybersecurity.
927740	929300	Let's think about the threat model, right?
929300	935620	So first, when we're thinking insulin pumps, we have to understand what the patient harm and non harms are.
935640	940840	So a harm, a patient harm is that the pump delivers too much insulin or maybe not enough insulin.
940840	943940	And this could be detrimental to the overall health of the patient.
943940	947480	And that's considered a patient's harm safety risk.
947840	956280	Non-harm would be the pump, insulin pump leaks some private information about the user to an unauthorized user.
956280	960820	Say maybe it's this passive eavesdropper that's listening on the Bluetooth communication.
960820	963680	And that would be considered a non-harm risk to the patient.
963680	976540	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.
976540	980480	And so what I'm using or what I'll detail here is something called Microsoft Stripe.
980480	985380	And it's a way to categorize risks, and I've applied it to the general insulin pump case.
985380	988820	So first we have spoofing, which is to impersonate a system.
988820	994800	In an insulin pump case, the attacker can masquerade as a valid smartphone.
994800	998700	That would be a spoofing-based attack that we would want to consider.
998820	1002240	We also have tampering, which is modifying data or code.
1002240	1006320	In this particular case, an attacker man-in-the-middle is the pump to smartphone communication.
1006700	1010380	We have repudiation, claiming to not have performed an action.
1010380	1019540	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.
1019540	1023520	Well, the pump is unaware because these are unauthorized, unauthenticated commands.
1023520	1026660	They can't distinguish between if it was valid or not.
1026660	1034060	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.
1036940	1039540	Continuing on in Stripe, we have information disclosure.
1039540	1042780	This is exposing information to unauthorized users.
1043240	1047920	So in this particular case, we can imagine an attacker that eavesdrops on pump-to-smartphone communication.
1047940	1053860	They're not looking to inject commands, simply see what information they can see going across the wire.
1054600	1057980	Next, we have denial of service, which is to deny or degrade access.
1057980	1064380	I always say this is the bane of cybersecurity professionals, because it's really hard to protect against, especially if it's directed.
1064700	1069020	And then the insulin pump case, this is where the attacker overruns the pump with requests.
1069020	1074080	Which would deny the valid or authenticated user from using the pump as it's intended.
1074480	1079960	Lastly, we have elevation privileges, which is to gain access to unauthorized capabilities.
1080280	1086360	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,
1086360	1095940	maybe by exploiting a smartphone OS vulnerability, and thus gaining unauthorized access to our insulin pump application,
1095940	1099420	and then directly impacting the pump operation itself.
1100160	1106320	So just to be completely encompassing, another step that my team at Harper Labs really likes to take,
1106320	1109160	we have our threat model, but we also have an attacker model.
1109160	1112160	And the idea here is to understand the attacker's goals and capabilities.
1112160	1119200	This is where security gets real, because we want manufacturers and the community to understand,
1119200	1123040	well, what is the absolute goal of attacking an insulin pump, for example?
1123040	1129500	Well, it's to cause patient harm. If that is really the focus, whenever we're looking at a medical device,
1129500	1134520	we're trying to find vulnerabilities that could actually impact the patient and their safety.
1134800	1142680	Now, also, an attacker could be, say, just this arbitrary software execution, like malware.
1143300	1147180	Mirai botnet would be a great example. That's just trying to pivot into the network.
1147180	1151700	And so if we're not securing our medical devices that are essentially network endpoints,
1151700	1156440	we may allow a pivot into the network, and then any other unexpected behavior that might come of that,
1156440	1158420	which could still impact patient safety.
1158860	1162360	And, of course, we have to consider things like the position of the attacker in the system.
1162460	1165660	Are they an insider manufacturer that knows all the gory details?
1165740	1170060	Are they simply just a person on the outside with a high-gain antenna and some equipment?
1170400	1173740	I also wanted to point out, too, in terms of capabilities, since this is BLE,
1173740	1178860	we're looking at maybe 300 US dollars in terms of BLE hacking equipment.
1181000	1185120	And I'll summarize quickly, because visuals are the best way to depict this.
1185120	1190280	There are a number of attack surfaces that exist in our general insulin pump model.
1190280	1194280	We have our physical interface, being able to connect to serial or press buttons.
1194480	1199040	We have our wireless interface, which is communication that's happening over Bluetooth,
1199040	1204400	which Julian will talk in depth about as the attack surface that he focused on.
1204660	1207140	And he also focused a bit on the app interface.
1207140	1210540	So what can the application tell you? What can you learn from it?
1210540	1217960	You know, this is another attack surface that an attacker could leverage to compromise an insulin pump.
1219080	1223540	And so with that, I'll turn it over to Julian to talk about insulin pump hacking.
1224260	1230840	Thanks. In the following minutes, I will explain the communication protocol of the Dana Diabica RS insulin pump,
1230840	1235860	which is sold by the Korean manufacturer Soil Developments, as well as vulnerabilities we identified.
1235860	1242160	I want to state that the presentation of the vulnerabilities shall not be understood as finger-pointing towards the manufacturer,
1242160	1249840	but may shed light on design problems more manufacturers are facing with building interconnected medical devices.
1250080	1255460	The manufacturer intends patients to use the pump as a central component of an open-loop system
1255460	1258700	in combination with the respective mobile applications.
1258820	1261840	With these mobile apps' safety-critical functionality of the pump,
1261840	1267920	such as manual administration of boluses or changing the basal rates of profiles is possible.
1267980	1272800	Besides, patients are creating less restrictive ways in controlling their therapy devices,
1272800	1279320	as, for example, the We Are Not Waiting initiative demonstrated in the past by building closed-loop systems on their own.
1279320	1282320	We will come back to this later in the talk, I think.
1282320	1290540	And further, the Dana Diabica RS insulin pump is supported by publicly-awaited looping apps such as Android APS.
1293190	1299630	The security assessment of medical devices is highly specialized and is dependent on the device's medical use case,
1299630	1307570	present interfaces, users and their backgrounds, use technologies, but also assumptions, for example, to its environment.
1307930	1313950	In scope of the test was the proprietary communication protocol between the insulin pump and its mobile applications,
1313950	1316550	which was built on top of Bluetooth Low Energy.
1316550	1322070	So the Bluetooth Low Energy capabilities were just used to implement some application-related protocol.
1322070	1327170	In a special, the assessment focused on the used and implemented cryptography,
1327170	1331710	as well as on the authentication and pairing process between the pump and its mobile apps.
1331850	1336330	The testing methodology was a black-box test without source code inside,
1336330	1339410	and we were voluntarily provided with two insulin pumps by the manufacturers
1339910	1344270	and downloaded the mobile applications from the App Store and the Google Play Store.
1347860	1353760	I will first demonstrate the normal communication flow we observed between the pump and its mobile applications.
1353760	1357160	We will start with the application layer pairing process.
1357320	1364620	The first byte demonstrates whether the message is a request with 0.1 or a response with 0.2.
1364700	1368440	We will talk about the names of the keys that are used on the following slides,
1368440	1373160	so don't hesitate to identify all the keys and understand their usage.
1373160	1374600	So we will come to this.
1375140	1380620	This and similar figures will present the different encryption layers with different colors.
1380620	1384980	Yellow color states that this information is transmitted in plain.
1384980	1389620	Blue color shows that the messages need to be encrypted using the device key.
1389620	1393260	And red color is showing that user interaction is needed,
1393260	1398360	as well as green color indicates that messages need to be encrypted using free keys.
1398580	1406900	Every communication starts with the mobile app sending a 0100 message to the pump together with its serial number.
1406900	1412480	The pump indicates that the serial is matching and afterwards the pairing is requested.
1412840	1417080	The pump immediately answers the request and shows a pairing prompt on its display,
1417080	1420640	which needs to be confirmed manually by pressing a key on the pump.
1420760	1423580	A photo of this pairing prompt can be seen here.
1426320	1433040	After having a user confirming the pairing, the pump sends the pairing key to the mobile application,
1433040	1437440	which then may use the key to encrypt messages after requesting a session key.
1437440	1442900	With these free keys, higher-privileged requests, such as ballast administration, may be performed.
1443140	1446420	For now, the free keys may be a bit confusing.
1446420	1452120	I believe that it becomes way more clear when seeing the post-pairing communication flow.
1452120	1455920	The next time the pump and the app are communicating, no user interaction is needed,
1455920	1461200	as the app only needs to send a pairing key to show that both entities are already paired.
1461440	1466140	After requesting a new session key, high-privileged requests can be sent.
1466140	1468540	Here we see the free keys again.
1468600	1470960	The device key is used to encode all messages.
1470960	1475940	The pairing key and the session key are used to authenticate the session, which is shown in green.
1476840	1483120	An interesting find works that the communicating party does not need to be paired to extract the PIN.
1483260	1484880	This is shown in the next slide.
1485920	1490860	The PIN is not directly transmitted, but can be calculated with the information transmitted.
1490860	1495560	We omitted the respective formula not to give some more insights on the protocol,
1495560	1499380	because we do not want to have you building exploits for this.
1499380	1503240	This enables adhocs to extract the lock key PIN,
1503240	1512040	and every Dana RS pump in the adhocs range, Bluetooth range, is possible to be read out.
1512040	1516860	The next finding we want to elucidate is about weakly generated encryption keys.
1516860	1523080	The device key is derived from the pump's serial number, does not contain any randomizing element, and will never change.
1523200	1526660	The serial number can be obtained from BLE advertisements.
1527100	1531320	The session key can be calculated from the pump's lock PIN as well as configured time.
1531340	1534660	We saw the respective request on the previous slide with the PIN disclosure.
1534940	1538320	Having these three occurrences of doubtful calculations of secrets,
1538320	1543020	we further investigated all the other keys and recognized that also the pairing key is not random.
1543020	1548340	This key is calculated on the pump, so we had no ability to reverse this calculation.
1548380	1552440	Though we wrote a script that requested pairing multiple times a second,
1552440	1557280	and saw that the same key will be returned in a second.
1557340	1560800	Therefore, we tried multiple combinations of calculations,
1560800	1567220	and finally found the formula to calculate the pairing key being derived from the pump's time during pairing.
1567220	1571680	So it's fixed, as the key is calculated from the time of the pairing.
1571680	1576520	As a result, any secret of the Dana-RS system is generated insecurely.
1576520	1581460	In addition to the lock PIN disclosure, no active verification of the pump's identity is present.
1581460	1586960	Therefore, attackers can spoof both communication partners and therefore get in many the middle position.
1586960	1590620	How realistic this is with Bluetooth Low Energy is up to you,
1590620	1595520	because I want to present a more easy attack for later.
1595520	1597960	Another example is the missing replay protection.
1597960	1602200	By checking the Bluetooth Low Energy session, attackers may replay sniffed messages.
1602480	1608640	But still, the most easy way to issue trusted commands is to capture a single communication flow between the pump and an app.
1608640	1611240	We will get into this on the next slide.
1614120	1621340	As we already have seen, the whole authentication mechanism relies on encryption using multiple keys.
1621460	1626000	This pairing key is the only key that is needed to issue higher privileged commands,
1626000	1632760	as the session key can be requested by anyone and as the device key is known to everyone without even connecting to the pump.
1633120	1640080	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.
1640180	1645920	This encryption is completely deterministic and everyone sniffing the communication is able to extract this key.
1646000	1648720	We will not show how the encryption works in detail.
1651700	1660440	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.
1660440	1669100	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.
1669240	1676900	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.
1676900	1682000	This attack can be performed automatically in productive environments and we want to demonstrate this.
1682000	1687480	The manufacturer prepared an update for the pump fixing the vulnerabilities, but let us first have the demo.
1689400	1695340	Now I'd like to present you the attack in a short video demonstrating the criticality of the automated attack.
1695340	1697640	A few words I needed to explain the video.
1697680	1705320	In the following video, an attacker captures messages between an insulin pump, a mobile app, and extracts the key from this communication.
1705320	1715700	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.
1716180	1723980	I was just clicking on a pump to reactivate the display, so there's no need to have this interaction at this point.
1724120	1730420	The patient may notice the administration and is able to cancel the single administration on the pump.
1730420	1735120	But as you can see in the following, more boluses are following.
1737560	1744960	I filled the whole tubing system with blue ink so you can see that in real life this would have been insulin.
1746580	1757300	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.
1757440	1762960	Wow, Julian, thank you for the stunning video. I'm always impressed when I see it.
1762960	1772460	When we now draw a conclusion from what we just heard, we can say that most of the vulnerabilities found are design defects.
1773160	1783620	The manufacturer collaborated at all time with us. He prepared and provided an update, as Julian already said, and that was rolled out in April 2020.
1783620	1797100	So the whole process was accompanied by an FSN, which was published on our regulatory's website. An example of this from a UK regulatory authority in English is shown on the right.
1797380	1812340	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.
1812340	1821560	As mentioned in the FSN, the device can be securely operated when the airplane mode is enabled, thereby preventing its functionality.
1821980	1828100	Moreover, the device has several safety features already implemented preventing from a misuse.
1828420	1837280	In summary, the pump could be used when the airplane mode was enabled to prevent potential risk when we discovered these vulnerabilities.
1837280	1842740	But I guess you're not only interested in the disclosure itself, but in the timeline.
1842740	1848640	So, as stated before, we aim to lift cybersecurity and act accordingly.
1848660	1855160	In our opinion, a coordinated vulnerability disclosure process is desired whenever findings are reported.
1855160	1860520	We use usually 90 days and give an extension upon a justified reason.
1860740	1865940	Julian, me and our team colleagues managed and coordinated the whole disclosure process.
1865940	1877260	We believe that it's essential to identify vulnerabilities in medical devices in an ethical way to strengthen cybersecurity, consumer protection, and patient safety.
1877320	1883220	Thereby, we all maintain a basis of trust to allow for mutual exchange and efficient communication.
1883600	1887920	As mentioned before, I have no intention to blame anyone here.
1887920	1897740	As a project team, we believe that ethical publishing of vulnerabilities is possible, thereby increasing transparency and the willingness to update devices in time.
1897860	1905260	However, it has to be ensured at all time that the publication does not pose serious harm to patients.
1905320	1912780	In our case, short-term measures and workarounds exist and existed, and an innovative device was not withdrawn from the market.
1912780	1921180	I believe that security and safety are not contradicting each other and that secure connected devices are pioneering.
1921260	1926280	Awesome work, guys. Especially, I like to see the ink on the napkin. Every time I see it, it's so amazing.
1926380	1938540	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.
1938540	1942820	So I commend the team for great, great effort there. Great work. Great job.
1943320	1950660	With that, I'm going to segue the remainder of the talk into the impact of hacking on DIY diabetic community.
1951260	1964560	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.
1964560	1970480	And that remediation effort had caused some issues with Android APS compatibility.
1971420	1981540	And so let me define that first. Android APS is just open source application that's used to create an artificial pancreas system. That's where the APS acronym comes from.
1982300	1991980	And an APS system just delivers insulin injections on the patient's behalf. So it's completely automated. It's also called a closed loop system in case anyone's interested.
1991980	2000920	Now, there's an entire open source and DIY diabetics community that was well invested into creating these artificial pancreas systems.
2001060	2011840	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.
2011840	2023300	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?
2023300	2029580	There needs to be a manufacturing community sitting down to understand, well, how could these two things still continue to work together?
2029920	2041120	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.
2041120	2051720	Before I do that, I just want to make a public service announcement. Everyone in this panel supports the DIY diabetics community, their hard work, their dedication, and just advancing the technology.
2051720	2062680	I mean, wow, these artificial systems, like regulatory barriers, have really caused this to not be a thing. And I think the DIY community just pushed so hard to make it happen. So that's great.
2062680	2077900	To give everyone else that's listening an idea, I've cribbed some data from the OpenAPS website. And as of May of 2020, there's at least almost 12,000 people reporting to use these DIY systems.
2077900	2083600	And these are just people that actually report that they're using the system. It doesn't cover people that are not reporting, for example.
2083600	2102400	And if we take a look at the graph that I've also cribbed from OpenAPS, we see that there's this nice reduction in A1Cs, which if you're a diabetic, your target A1C, you'd want it to be closer to six. It's indicative of just better overall health outcomes.
2103860	2106740	So now I pivot to the next point.
2106740	2119460	The current DIY community has leveraged vulnerabilities, quite frankly, of insulin pump devices to be able to construct their solutions.
2119460	2138200	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.
2138200	2147520	And so this is worrying from a cybersecurity professional's perspective because its foundation is built on antiquated hardware. It's no longer supported by the manufacturer.
2147520	2161140	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.
2161140	2169980	And so this DIY solution, while it was great when it first came out, it lacks a formalized threat model.
2170000	2178720	I haven't seen anywhere in the community yet where someone went through the steps of providing, say, Stride and understanding all the risks.
2178900	2181940	And let me also put a caption on that.
2181940	2191120	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.
2191120	2200260	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?
2201020	2213320	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.
2215160	2223080	So, as I alluded to, this is not late-breaking news. The DIY community knows about these issues, and we can actually see it pretty easily.
2223080	2231420	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,
2231420	2246780	the first thing we note, which I have denoted in the red thatched rectangle, is that the models of Medtronic devices that they require are old hardware that Medtronic no longer supports, the 512, 515, and 522 models.
2246780	2260820	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,
2260820	2267900	and therefore, you can only have the older version of the software in the device to be able to integrate it into this open solution.
2269160	2285760	Furthermore, as a sort of a side point, there's also a look on Craigslist to find medical devices, which always kind of makes me worried, eBay and Craigslist medical devices, but I'll leave that there. I'm a cybersecurity person, not a medical person, so I have no advice for that.
2287120	2296740	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.
2296740	2309620	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.
2312140	2325420	So, I wanted to take an additional step. It's one thing to look at the architecture and the data that's already available, provided by the community, but I also wanted to understand, the source code was open and available.
2325420	2333320	So, I wanted to run a stack analysis against the source code to kind of understand what vulnerabilities may exist there.
2333320	2342120	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.
2342120	2351240	It really comes down to the security professional taking the time to follow up and understand if those are actual weaknesses and vulnerabilities.
2351240	2357180	That being said, I was able to quickly use SonarQube, which is freely available, they have a community edition.
2357340	2365700	Scan the OpenAPS source code that's also available and open on GitHub, and to be able to identify some security hotspots.
2366240	2376040	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.
2376040	2381200	And these things are not being adequately validated or verified, so there's no input sanitization.
2381240	2398560	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.
2400460	2409040	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.
2409040	2416900	And in particular, they're using a Raspberry Pi. Now, the Raspberry Pi is this nice single board computer, but it has a lot of different interfaces.
2416900	2425280	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.
2425440	2430720	But it comes with additional properties that shouldn't really exist here.
2430720	2436480	It has a full Linux operating system, which comes with all the complexities of managing the security of an operating system.
2436480	2444320	For example, firewall configuration or managing access and server service level accesses to files and data.
2445180	2460460	And it requires remote access or root remote access just to function. And so this is usually the security 101 things that we'll talk about and say, well, you should never allow root remote access. And it just so happens it's a system, you know, you need to leverage it to make it function.
2461700	2469780	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.
2469960	2480440	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.
2480440	2495140	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.
2495140	2504500	And I think that I would like for there to be a larger conversation with regulators, policymakers, manufacturers, and of course the community.
2504500	2519660	I think this is already happening because, you know, I can't be well aware of all the conversations, but, you know, they're, they're just very straightforward foundational issues with the stuff in the past. And I'm really hopeful that going forward. There's just a better answer and a better solution.
2521280	2527680	All right. With that, I will leave some concluding remarks to Dina for the MoneyMed release.
2527680	2539740	Yeah, thank you very much. So here comes a small teaser about our MoneyMed release, because the insulin pump is actually not the only product that was assessed during the scope of the project.
2539760	2545520	So our project results will be published in German and English in December 2020.
2545520	2563400	And I hope you're all waiting for this. So our final report will include the findings presented here. And as I said, those from the remaining devices, but not on a technically deep level. Why? Because we want to allow basically everyone to read and understand our project results.
2563400	2573880	All manufacturers have to review or can review their respective sections prior to our publication and decide whether to be named.
2573880	2583820	In the final report, we will demonstrate how we cooperated with different manufacturers and dealt with individual vulnerabilities and their disclosure.
2583820	2598620	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.
2598840	2613620	We want people to get a feeling for vulnerabilities and to ideally have a sustainable effect on the cybersecurity of medical devices with our project. And we are willing to do more research in that field. Thank you.
2616070	2628010	And I'll conclude with some future research. The entire team, our panels, are interested in contributing to security as a software development lifecycle best practices to the DIY community.
2628010	2641410	Also just understanding threat modeling those devices in the DIY community as well. And pursuing additional medical device research. So it may not be just diabetes technology, as Dina pointed out.
2641410	2650330	But just holistically all medical devices, especially ones that are connected or network connected. And with that, we would like to take some questions.