Life on the line breaking into a medical device by exploiting tee hsm- Tamil Mathi

to see so many zombies here on the Friday afternoon, especially with a long weekend. >> So, thank you again for staying around and thank you to our speakers who have kindly been shuffled into this last track for the day. Having been really nice to see a full um venue for the last three talks of of the day. So, to start off the session, um we've got Tamil Mafi. Tumel is has over seven years of industry experience. who specializes in securing a range of ecosystems including IoT, web, cloud, and mobile. He's a former red team member and a competitive CTF part participant and currently he's focused on revolutionizing medical device security and that's what he's going to be talking

about us today. Over to >> Thank you. >> Yeah. Good afternoon everyone. Thank you for being here. I cannot get any more excited. So today I'm going to be talking about life on the line breaking into medical device by squaring TE devices. So it's a technical debate. So brace yourself. Who am I? So I'm a senior product security engineer at Bectton Dickinson advanc special monitoring formerly known as Edwards life science. I have MS in cyber security from University of North Carolina USA. So right now I'm focusing on secure design making sure security is not an afterthought but a foundational element in how we build systems. So especially focusing on secure by design principles in high stake technologies

and products like medical device. I also do red teaming used to be a synak red teamer. So old habits die hard. So I still do bunkcb hunting and I have just started writing blogs. So they may not be good and getting better at it. So read at your own risk. So agenda. So today I'll start with why medical security matters. Um so it's not about data losses or financial or business reputation. It's about patient safety. So I'll also give quick intro on trust zone t overview of the device architecture and PKCS1 how it fits into this overall device architecture. Basically uh it's going to be making it's going to make it easier for you to

understand the exploitation techniques that will be followed after. I'll also touch on detection and monitoring strategies and what we can do about it to prevent these kind of attacks. I'll finally wrap up the presentation uh sorry about that. I'll finally wrap up the presentation with talking about challenges in enforcing strong security controls in medical devices. So what's stopping them from doing that? Okay, there's a start there. Uh more than 60% of connected medical device in hospital have known vulnerabilities according to CIS. So it means majority of the device in hospitals are going to be exploited easily. Having said that, why medical device security matters? So if the device that's connected with the patient um has security loopholes so or

the device is compromised because of poor security. So the consequences isn't just ding or financial losses. So it's much more than that it's about patient safety. For example, if the device for example the case of patient hot monitor so that if attacker could tamper the readings or values that's shown on the display then it could lead to patient home or such examp like delay in treatment or incorrect treatment or sometimes even death in case of pacemaker or implantable if those devices are capable of accepting unauthorized commandments. So that the result is catastrophic. So then comes typical uh data losses like page exposure. Then comes the typical regulatory consequences like FDA recalls, business reputation, damage. So

let's look at the real case here. In 2017 there was this pacemaker that were already implanting almost half a million people. So that device has got some vulnerability allow an attacker to remotely modify a hot pace. So of the patients that it was implanted on. So attacker could run the battery dry. So it means anybody with the laptop and with the knowledge of how to exploit this vulnerability could remotely trigger an hot attack. So the exact detail of this vulnerability were not disclosed but the fish was fix was released but uh that wasn't even the main problem. So the real challenge started after that. Um so since it is implantable so some patients would have

to go through the invasive surgery to get the implants removed and update the homework. So that's what makes it much more difficult because some people wouldn't have survived that implantable surgery. So even though fix was issued so it's not easy to fix these kind of attacks. So that's why we need to think from 360° view like what are the pros what are the cons? If the device al devices are ready to accept like remote firmware if they have capability of updating the firmware remotely what are the pros what are the cons? So do we have like good security controls? So these are the questions that we need to ask ourself before implementing security controls in high-stake technologies like

medical devices. Having said that, so the medical device can be classified based on invasiveness. That's just one type of classification. So it could be a non-invasive device means it could be just a simple cuff like finger cuff uh like where it's uh using the bladder to measure blood parameter or it can use light like Apple Watch. It can measure some other parameters from your body or it could be minimally invasive. So it means some like endoscopy. So something gets into your body through minor insertion or a cut or it could be invasive device. So the perfect example would be a pacemaker or implantable. So the invasiveness is a key factor in determining the risk profile of the device. So based on the

risk they have to have different kind of security controls. They have to go through different kind of submission strategy. They have to um have follow different kind of submission process. For example, in US we have three different classes like class one being low risk, class 3 being high risk. In EU we have such classes as well. So the invasiveness is a key factor in determining the risk profile. Let's talk about something what most people overlook. So platform and hardware security features. So these devices are going to be deployed in what we call uncontrolled or hostile environment where anybody could walk up to your device, take it and put it apart, try to extract the firmware and

try to reverse engineer that. For example, they could access the debug interfaces via Jar and try to modify the boot parameters to boot the Linux into like with the root privileges. Basically, they can bypass all the security controls you have on your software or OS layer. So that's why software security is not going to stop all kind of attacks. So that's why we need like platform security. So some of the counter measures or so the first one will be TE or TPM. Uh so these are your hardware root of trust where you can store your passwords or private keys, certificates or any other sensitive information. So it also enables secure boot where you are making sure you are

loading only trust modules form and only signed codes. Uh so unorthodox codes cannot be executed. It also enables you to have full disk encryption where you can protect all your data at rest. So it can protect against like offline attacks. Um and it should also have like anti- clone and anti-teamper properties. Some formers even zero out all the secure storage data if it tries any tampering attempt. So trusted execution environment. So what is it? It's a dedicated area within the host main processor. It's a built-in hardware security mechanism. So it's a very cost effective alternative to physical HSM. That's because you pay for the processor. So the security feature comes with it. You don't need to pay

anything extra like HSM and you don't need to worry about the engineering cost that goes with the integration with this module. So it's very cheaper. So IoT likes this. Who doesn't like cheaper security? So it's very cost effective. And one of the well-known implementation uh HN is like nom trone. It's it's a security feature in processor starting from V7. got fully adapted as it's a built-in hardware isolation mechanism. So hardware backed security feature. So how it's done? It literally splits the processor into two different worlds secure world and non-secure world. So codes in the non-secure world cannot access secure world. So all of them needs to go via proper standardized API calls. There is no direct memory access.

So it since uh it's going via proper APIs. So there are a lot of validations authorization checks going in there and I'll I'll explain that in the next upcoming slides. So it also provides secure memory and secure peripherals. So it means like you can configure some kind of NAN based storage uh and you can make it accessible only from the trusted side of the processor. So because TE specification does not talk about secure storage as it says it's a execution environment where you can run your uh code but it doesn't talk anything about the storage. So but if we you can tweak it little bit you can add your storage that way you can have your secure

application talk to the secure storage. So that's what makes it secure storage. So um ARM processor also comes with a trusted firmware. It's a low-level implementation basically C code to make it possible. So it uses a special instruction called secure monitor call. It's a CPU instruction. That's what's responsible for switching the mode to secure to non-secure and vice versa. So it's accessing gateway between these two worlds. So Intel has TXT and AMD has SPM. So it's not just OM. So both of them have some similar technology. But at the end all of them provides just secure execution environment for your trusted application. Let's look at some of the common use cases for this. So the first primary

function for this is secure key storage where you can store your keys, certificates like any other private information and it can also perform cryptographic operations. So it also supports like major cryptographic algorithms like AES, RSA. It also support like major crypto primitives like hashing function, digital signature verification. So one of the use case would be if your device is authenticated uh to any other third party device module then you can do this TLS verification right so you can offload this TLS verification path to TE that way you don't need to expose your private keys so the application doesn't need to access your private keys to do the to do the TLS verification because it's all happening in the TE so you are

decoupling the sensitive verification part and putting that in TE so that's how you should design the system so it You can also use this uh secure storage as a general purpose storage where you can store your PH information like any other sensitive information that you want to protect. So you can also safeguard your ML models like the ML models that predict some kind of disease before symptoms appear for example cancer or any kind of disease. So you can because that's the heart of the device. So attackers should not compromise this kind of models because this is very crucial for the device to function properly. So you can safeguard all these secure models from being reverse engineered by putting that in

the TE and authentication. So if your device has to do some kind of authentication like face ID, touch ID, then you can offload that part to TE. That's the other use case. And TE OS so you need some kind of OS to take advantage of the hardware security feature. So as I talked about trust zone, that's a hardware security feature. So you need some kind of OS to make it possible, right? to make it work. So that's why this TE OS comes into the picture. So it's very tiny OS. So they want to keep that that way. So because it's very intentional. So because uh smaller code base equals to less vulnerabilities and less attack

surface and more predictable. This has been tested thoroughly to they know how it functions. So that's why they want to keep this OS very small as possible. So it provides greater flexibility than TPM because TPM it's a separate hardware and it needs to be scoped to meet TCG specification. So it needs to check out some check box to be eligible called TP in TE like vendors can choose however they want and they can implement whatever they want to do with TE. So they can even implement all the TPM functionalities in TE. So vendor for example there are a lot of TEOS out there in the market. So trust opt it's a open source tus that's what we'll be

looking at today for this device and trusty by Google so most of the smartphones are running on processor so if it's using Android so trusty is behind that QC call and zos for Apple so again they are just different type of tos doing the same job so this is the architecture of the device so is a type of t so as you see here on the left side you you have rich OS Linux on the right side you have octi both of them are running on the same processor so but what you usually see is the what's on the left side so just Linux or any other Android or any other software but there is also another OS

that's running parally but that doesn't have like rich interfaces so whatever you whatever you're seeing in the red green box are your custom application that you build according to a use case of the product for example uh you have some PH records then you your application uh can send the PHA records to your trusted application where your trusted application can decrypt that information. So your trusted application can extract the keys from the hardware resource like secure storage or any other cryptographic object. Then it can extract the keys and uses that key to decrypt the PH records and send back to your application on Linux. This way your application doesn't need to know the private key to do the encryption or

decryption. That's how you are decoupling this entire process. So uh on the left hand side so it needs to go via global platform APIs. So on the right side you have it has to go via global platform APIs. I'll explain that in the next slide. So then it comes to TE driver. So it's basically sequence of function calls. So then T driver again trigger the SMC secure monitor call instruction which is responsible for switching the mode from non-secure to the secure and then it's going to the TA trust application. Trust application are isolated between each other. So even if they want to talk to each other they need to go via the function calls. Um so

SMC again here it's access a gateway and that's how it works. The global platform APIs what are what are they? So in order to enable secure and seamless also on the interoperable communication from your Linux application to the trust application global platform uh define some set of APIs in of uh so these APIs are going to make the job easier for developers to develop trusted application because we have lot of different trusted application uh t right like opy oqz trusty so if developer can write uh trusted application that can also work in other trust trust execution environment OS with very minimal code change. So that's the goal. So that's why they have standardized this whole

process to make this job easier. So there are two set of APIs here. So first one is T client APIs. These APIs are used by your application in Linux to talk to the um TE side for example invoke command initialize contacts. So these are responsible for establishing a session to your trusted application. they can uh identify the proper trust application then initiate the call and then second set is T core API uh these APIs are used by your trusted application to talk to the actual cryptographic service to this is what's used to generate the keys to talk to the secure storage and so this is the main set of APIs you need to develop this so

for example generate key function is used to generate the key directly all the key transient object then there are a lot of other uh core APIs So then introduction to PKCS1. So PKCS1 is a way to interact with any other any hardware security model that uses or stores or manipulate cryptographic objects like keys. So it's a it's a platform independent uh standard because it uses object based approach which means even if you have one HSM let's say you have one HSM from one manufacturer and you have another HSM from another manufacturer. So if a client's an application doesn't need to know the difference between them because it uses a concept called object. So according to

them it's just treated as a object. So there are a lot of objects like data key, certificate, public key, private key, secret key. There are a lot of different objects. So this is again to make it like technology independence and platform independence. So that's the goal. So libraries are available in common programming languages like C, Python, Go, Java. So your client side application can imports that library and uses that to talk to actual hardware security model. So this is the um so this diagram illustrates uh the the PKCS1 how it's used as a trusted application itself in this particular device. So on the left hand side block that's your rich application uh sorry rich execution environment where you

have your next running on on the right side you have your opt running on uh and both of them are running on the same OM A7 processor. So on the left hand side you have your client application like open SSL or PKCS1 tool. So they are your command line utility to talk to your test application. So when you initiate the command using PKCS1 front end application then that calls lip tec which implements global platform client API again as I said earlier it has to go through the proper API so that library is the one that's implementing the client API then it redirects a call to opt driver then that's switching the mode by SMC instruction then it goes to

core then core redirects the call to corresponding test application then it PKCS1 commands that you put in the first step will get unwrapped here and this TA will understand that command because it PKC is also implemented there. Then that does oneonone mapping to the internal core API. Then the core API is implemented in libut library. So then it redirects the call to the secure storage. So in this case this device uses Linux file system as a secure storage. uh but this is not a security issue because uh they even though it's stored in the common file system they stay encrypted and it also has integrity protection so it's a well-known implementation supported by global platform um so trust me when I say this

most of the devices don't even have this kind of TE or secure architecture I'm talking about like 10% top 10% sophisticated device yet it's vulnerable okay as I explained earlier in the step this uh blue color block TA uh that's PKCS1 TA. So this PKCS1 as a test application how it works. So this creates a emulated smart car. It creates emulated HSM. So it's not a physical HSM as you can see here. So there are three slots. If it were a physical HSM so each slot would refer to each physical device. So in this case you would have to have three physical device to come up with the three slots. So in this case there is no physical HSM. This trust

application emulates this concept. So your application sees this as a create physical device but all of them have same EU ID. This is TA trusted application unique ID. All of them have same UID. So this is emulation. This is the single application creating multiple emulator device. Uh so the there are three slots. So these slots are uh this there is authentication to these slots. So under these each slot you can store cryptographic objects like key, certificate, PHA anything under each slots. So these slot authentication are defined at the user level. It means if you have like five application running under some simple you know Unix or Linux user user uh so all these application will have access to this particular

slot. So it doesn't go any granular than that. So that's the key limitation that developer should keep in mind while designing this solution. So all the application under the same account will have access to a particular slot. So there are two authentication types. The first one is pin based. So there are two pins user pin uh and the secure officer pin. So user pin is the pin that application needs to know to access the slot. Without the pin you cannot access the object stored in the particular slot. Then security officer security officer is to manage these user pins. So basically administrative task to create or delete or change the user pins. Both of these pins should be kept and stored

securely. A second authentication type is identity based authentication. It means you are tying the Linux user account to the particular slot. If you if you want to eliminate the PIN concept completely, this is what you have to do because there is no PIN involved here. So it uses Linux EUID to do the mapping. So on the runtime if your application tries to access a particular slot, your Linux application will convert that uh user account to UID then does the mapping. If it passes then it will allow the user to access the slot. So that's the one thing to note in authentication type. The second one is the object access policy. So each object carries a

set of flags. These flags are basically nothing but the attributes like set of attributes. So these attributes define what operation you can do on the particular object. For example, if you mark such uh one object as exportable, you can export that object. So these you need to set this carefully because if your private key is set as exportable then they can export the private key. So there are a lot of access class you need to set those carefully and some of them are applicable to some kind of object some of them are not applicable to some kind of object. For example data object uh doesn't have any exportable by default it can be exportable. So this is

what you need to know. So this is the actual screenshot. Um here at the first diagram I use a PKCS 11 tool that already existed in the machine and the I am just an ND user. It's not a root account. Then I use the module lik command. So that module implements the client API. Then I'm getting into the slot zero. Then I'm extracting the type data object read object and I'm doing read operation. Then I'm extracting the data here extracted. So this is what I did here. As you can see, it's asking for a pin. Please enter your pin. If you look at fourth line, it's asking for a pin. So I tried to uh use different pin.

I tried to brute force my way in. I did lot of thing, but I couldn't do it. But I went back to basics. Then I tried just 1 2 3 4 5 6 7 8 9 0. It worked. So yeah, so sometimes you have to stick with the basics. Yeah, I think we trying to do that. Um then on the second diagram so as you can see I'm listing out all the objects like what are what all exist in this particular slot. I'm just putting uppercase O. It means I'm listing whatever objects that present in the slot zero. So I'm entering the pin again. So I as you can see it's a private key object that's stored that

that's marked as extractable as you can see. Then there's a public key object. Then there is a data object that's modified. That's actually PH record right there. uh what you have seen uh and yeah here um so um developers may think okay data object I'm not marking this as exportable but what they need to know is by default data objects are exportable they just don't know that so you can literally export the data from uh your slot zero that's exactly what I did on the first diagram okay let's talk about other common weaknesses I usually find in this kind of architecture so one is a weak weak or insecure management Sometimes as I said earlier we just have EC pins. Sometimes

whatever pins that are present in the default documentation they forget to change the pins and sometimes you need because you need to store these pins in the flat file because where your application should have access to otherwise your application cannot get to the pin and it cannot access the slot. So you have to design it such way. So if you store that pin in the flat file and you don't have proper ACL hardening on the file then it can lead to uh security vulnerability because even if let's see let's say if an authenticator user has access to the particular file where you store the pin they can get the pin and tries to access it. So and as I said

earlier say you sometimes the trusted application doesn't enforce like brute force protection. So it means you can brute brute force your way in. So and hardcoded pin. So application just stores this pin hardcoded in the source code. It means you can just without proper offiscation it means you can extract the former and tries to reverse engineer. You can just run strings command you'll get the pin and access the slot and access all the objects. And in the second type of authentication where I mentioned you literally map the user account to the slot. So in the type of authentication what you need to keep in mind is over the time you lose track of the application you are adding in

scope. So over the time you will add more application under the same user account you lose track of it then that leads to privilege swap like you it will have broad privileges. So your application will have like lot of application will have access to where they are not supposed to and then the second common weakness is improper configuration of the object access control flags like I explained earlier. So you need to set these flags very carefully. You need to for example if it's not exportable then it should not make it exportable. So these kind of access plans you need to set carefully otherwise it lead to it can lead to catastrophic incident particular incidents. Okay detection and

monitoring. So just because this uh opt hidden deep inside the layer and it lacks rich interface to like Linux to make it work with. So doesn't mean have to leave these trusted application unmonitored. Um so because so it's not possible for you to add like more features to opt. It's not possible for you to add like uh extend the work complex workflows. So but that's intentional. So doesn't mean you have to leave it unmonitored. So there is a way to do that. So the concept is called pseudo trust application. So think of it like a privileged container where your container is running with higher privileges than other containers. So that's what exactly it's so it's built

into the optic code. It's built into the kernel. It has same privilege as the kernel. So there is no out of the box solution for detection uh uh detection sudo ta provided by opi but you can build one according to your use case. So in order to do that you just need to your other trusted application operations like what it's accessing what are what's your baseline you need to set your baseline then you can easily find anomalies if you are able to come up with the list of operation performed on spe under a specific time frame during specific time frame you can literally set that as a baseline and build a pseudo trust application on top of that

to detect the anomaly if it goes above that limit after that if it's finding any detection if it's finding any anomalies is then you can have that pseudo TA report back to your Linux application where you have like fullfeatured monitoring strategies. So via TE supplicant. So you can have your pseudo TA report back to your Linux application via this TE supplicate. Okay, I have built this open source tool to make it uh uh easy easier to find these kind of vulnerabilities in this kind of architecture. So uh it's just open source. I just posted in GitHub. So there are a lot of cool features about that. That's where you can brute force like does all kind of enumeration like

uh and it also checks for object if it's authentication is successful it can extract that for you. It basically does all kind of automation. Then it also uh scans the scans for like sensitive log files across your Linux system to see if it's uh storing storing anything sensitive. And I'm also trying to build a wrapper around this PTCS level to enforce app based because as I said earlier it's it doesn't go any granular than user based so that authentication is at user level. So I'm trying to build a wrapper to enforce app based. Okay, let's I think we have reached the last slide. Um so challenges in enforcing strong security controls. So the first one I see is detection and

monitoring. So detection and monitoring is almost impossible in some medical devices because these devices are cannot be connected out to internet. It cannot be connected to your backend server. So it lacks realtime monitoring because some hospitals are sensitive to that. So even if they allow you to do that, you have to be very very careful what you are getting out of your device. it cannot have any sensitive information like patient records or any other ID. The second one is these IoT devices are running on very limited computing environment. So some security functions are computationally expensive. So thanks to cryptographic accelerators like SHA as u that problem is slowly going away but it still exist. So that's why

security should be lightweight and efficient. And the third one is connectivity as I explained earlier. So lack of connectivity leads to um a lot of problems and legacy systems. So some device some devices are decades old. So when that devices were built security was not into the product. So trying to fit security right now creates a lot of financial and technical limitations and safety versus security trade-off. That's very important uh concept because you need to prioritize safety over security. Uh so as I explained in the first slide if it were implantable like what would you do like would you make your device uh setting remote commands like updating remote firmware what that's a priority that's a trade-off you have to do then

some devices can only be updated via manual procedure so some devices can only be updated via USB in person uh it can doesn't have maybe it doesn't have remote connection or it's very old so that's still applicable so it stops your uh process of issuing security releases even though you have issued new releases patches software patch patches so it's uh not possible for those devices to take them in and lack of secure by design culture so security should not be built on top of the devices instead it should be built alongside the product development so some engineering teams like I have seen they don't have like proper security by design culture instead they have security just like a

checkbox to them and that's what exactly should have changed uh should change Thank you. Yeah, thank you for attending. So this is my LinkedIn. Feel free to connect with me. So let's talk