 Hello dear listeners, welcome to this talk. This is Tom from the translation team. If you have feedback to the translators, tweet at C3lingo or use the hashtag C3T or email us at hello at C3lingo.org. So we have telematic infrastructure in Germany. We have the electronic health insurance card now, which has been introduced and the reactions So it saves many different types of health data like prescriptions diagnosis. How much of this has actually been put into place, how the technology has evolved in the last years? If the big promises have been kept that will be and I did now by Christoph. He works at the University of Applied Sciences, Münster and we'll talk about the last years here of technology. Welcome, Christoph. Thank you and welcome. Now at this late time, I want to talk about the telematic infrastructure. We had a smaller talk recently, but now we talk about the technical specifications. I want to create a small overview for you and this can only be a small one, because if you look at this specification, you can download this actually at schematic.de and you will find a zip file, actually 97 zip files and 8,000 pages of PDFs, one to two thousand other pages and this is only really a small overview and I would please like to encourage you to discuss about this, but also an objective and fact-based discussion and there are lots of reports recently, especially in the last year about the telematic infrastructure, but as far as I know, not all of this has been very correct from the technical point of view, so there were some half truths going around and I want to inform you today about this. So we begin. What are we talking about with telematic infrastructure? So here on the left side, you can see the IT systems of the health workers. This is the network of the practice and many are connected or at least they have connected systems and the telematic infrastructure, or short TI, there is the card reader where you can put the health insurance card inside, but also other cards like the medical professional card and this connector here, this connects the internal network with the central TI network. This is this other zone here and there we find different things like certificate authority and other central things like a time server, DNS server, directory server, like an LAP server and this is not a transparent network, it is enclosed. And it is disconnected through some security measures, so not entirely connected. There's also the provider zone where the manufacturers of systems are hosting the products and specific services as well and on the very right side, you can only see the system, the data archive system, but there's also other networks like the secure network of the KVK, which is mandatory now, if you want to actually get paid as a doctor and you can only do that through this KVK network. This only works for VPN connectors, so they usually have this at their practice now, sometimes for many years already and now we don't want different ones, but we want actually one central one and that's why we all connect them to the telematic infrastructure, so we only need one from now on. Now we look at the actors. Who does what? Where does the telematic infrastructure come from? And of course we have the Ministry of Health, Jens Spahn is the current minister since May of this year and since then they're actually shareholder with more than 50% of gematic and at the same time they have put into law that for decisions, there is only necessary to have a simple majority. This used to be different where a consensus was necessary, but now the federal health office has the entire power to push anything they want. Jens Spahn wanted to increase the speed and this was the measure that he used for that and gematic here in the center, they specify the infrastructure itself, the services, the components, the applications that don't do this by themselves, but they do this in connection with the federal office for security and information technology and they create different guidelines there and gematic doesn't act alone. They do together with them, but they don't actually produce any components and they don't offer any services. This is all done by the private sector. Here we see the large systems, large providers like T-Systems and others and they actually offer the services or create connectors, for example, and for that they need a certification for which they also need a certification from the BSI and but they don't actually test this themselves, but they have different evaluators like the German TÜV, but also others and also interesting is that the providers can usually choose which evaluator they want and they also pay those, so there's a little conflict of interest actually between the providers and the evaluators and to combat this a little the BSI actually audits the evaluators and they also of course have to get certified to certify themselves. Now, let's go to the applications that are being used by doctors and patients, the so-called I will call them FAA from now on. And there is the management of the patient data, the SDM and for example, when I moved I had a new address and now I told my health insurance company I live somewhere else now and they told me, okay, you need this new card, they sent it to me, but this has been changed now and the data on the card actually can be updated now. When I go to the doctor, I put my card into the machine and the connector will check my data and if it is not updated anymore, it will get actually updated on the card and this is actually the only actually working and right now in production application of the telematic infrastructure. Okay, I want to look at the application and that's why I took the chance when I moved to try out happens. I have a new address, I have a new card and I wanted to see how it works and well fail. Three days later I had the new card, so it doesn't it's actually not in use really. There is a reason mainly because there are not enough doctors who are attached to the network and about 120 of the five-figure number of doctors is attached to the network, therefore they cannot even update the card and it's not being utilized, which is a bit sad. Next year maybe. Okay, so now we have this PII massive data management we have very critical information for example certain KPIs for risk management, disease management programs, so we need there's a paramount need for critical security, but so my talk becomes a little more technical now and we're looking at the specification now. There's a lot that has to be where they have to catch up with the state of the art. So on the very right you have an insurer's server. It is attached to a central network. On the very left you see the insured card in the middle you see a VPN connector, a card terminal, and insurers a VPN endpoint. And in order to have the connection set up properly you need a secure message system that is an ISO standard that is being applied here. It has symmetric encryption. It uses AES and a message encryption algorithm in order to have a secure and verified connection between the insurer and the card and the data is only unencrypted on the card itself. So let's look at the second application. It's the communication of the of the provider of the service. So between different service providers like doctors, psychotherapists and pharmacists they have an LDAP system that has the addresses. It's not in use yet. It's going to come next year. They're also registered email addresses of the doctors and then are being encrypted with a certificate. So basically they can encrypt their communication between the different service providers in order for it to be secure. If you compare this with PGP and SMIME it works a little different. For example, you also want to encrypt a subject and you want a certain level of encryption. So they thought they would do it a little differently and then do the subject and use ISGCM. So if you remember a PGP doesn't have GCM they use something similar but if you look back a year, e-fail was a big problem or rather it still is. And this is not an issue here because they have a different kind of crypto. So on the left you see the client here. It can be from the bird outlook or maybe even the doctor's infrastructure system. They have the original message and it's being packaged into another message. The original message is being encapsulated. It's going to be encrypted and signed in the doctor's office and this is being done in the connector. It's being sent to the email server by the doctor and there is a real encryption between the two connectors on both sides, the doctor and the insurers party. So let's go to the EPA, the digital patient file. It's supposed to be the killer app in the TI. It's a voluntary patient led or that the patient itself takes care of the file and the patient has to go up to the doctor and say, yeah, I want to have the EPA, has to fill out a form, go to the doctor, put his card into a device and then give them the credentials to do it. So they have to explicitly allow the doctor to create an EPA. It's also not being done that they created an empty file. It will only happen if the patient authorizes the doctor and the authorization is only for the specific doctor, not all of them. The patient can also read his or her own data. They can modify, they can delete it. So for example, if they have given authentication for a psychotherapist and they're unhappy with the diagnosis or don't want anybody else to see it, they can delete it a year later maybe. It also means that the doctor cannot rely on the fact that the data is complete because the patient is always able to delete stuff. So this is a bit problematic. But they can at least have the possibility to just securely save their data in a digital form. And it doesn't actually show up at the insurer's side and it's not being saved on the doctor's phone. So there's one problem with this. It has a good cryptography, but what happens if you lose the key? So the key is not, you can't export it from the card. So if the card is being lost, which happens quite frequently apparently, then the EPA is lost because the data would be lost, the file would be lost. They couldn't access it anywhere. So the question is, how do they get around it? Their approach to this is they have a key backup. We heard from this about this two days ago. It's basically being uploaded just like the EPA, which sounds dangerous at first. So what they did was they also encrypt this key. This looks like this. You can look it up in the specification. It's actually quite readable. They explain it quite nicely. So what happens is the client, for example, the phone app connects via the key generation system and encrypts the encryption key again with a master key. And the master key is being encrypted with two keys, the key one and the key two, twice because SGD-1 and SGD-2 are being securely distributed between two companies, different personnel. You want to try to do secret sharing here. So that a single attacker from one of the organizations cannot unencrypt the data. So what happens if you have an attacker without authorization? So back two days you have two problems. Technically you would need a key backup and the encrypted EPA. And then you would have to break both SGD-1 and SGD-2 to get both keys. So they actually have put in a mechanism that even if you lose the key, they still can audit and do it. And there's also another problem. The app is supposed to work in a way that you can control everything, but it's being audited and certified. But not every update is certified by itself. Once it's certified once, they can basically push updates without re-certifying every single update that they do. Obviously they have to test it, but there's no independent party that verifies that the update is okay and doesn't actually add new security holes. So what does that look like in practice? If you remember, 35C3, the patient file, it didn't look that well. So in practice, I'm not so sure how that's going to turn out. So at least I also help a small dental practice. And often things are unencrypted there and pictures are sent via email, unencrypted. And since the GPR has been introduced, there has been a lot of discussion. What could we do? Some recommendations from the groups of dental doctors, but the usability is not good and crypture has the problem that some external server outside of the practice has the unencrypted data. And that is definitely at least critical when it comes to the GPR. And then some other recommendations. Here's the handbook of cryptfile. What should we do? We should send one email and then only in a separate email. We should send the password, but both are unencrypted. What happens if I want to connect my practice? So I need this terminal and then I look at the handbook and then in one meter of this device, there has to be no camera, no microphone, not even a telephone. And the patient is also supposed to put the pin into the device. So the patient even has to make sure that, for example, their smartphone is more than one meter away. And then it also, of course, cannot be too close to a wall because there could be a device that could deduct from electromagnetic radiation what is going on inside the device. And then I'm using the device and I found a secure place. And before we start using it, so I have to check the device every morning and then after the break, lunch break, to make sure that there has been no manipulation. It has three seals, which I also have to check each time. And then I have the seal numbers on my list and I check them. Then I also open my drawer with my black UV light, lamp, and then check all the holograms there. And I ask around between different doctors and nobody actually does this. So these are four pages, common criteria and that you have to keep in mind. But this is from the common criteria protection profile. And this means they are a potential victim with very high potential to become a victim. So that's why you also have to think of things like the electromagnetic radiation that I mentioned earlier. And there's the VPN connector. I also have to put that into my doctor's office. And there has been a lot of discussion about this connector. There's a serial part. So between the internal network and the internet, I put this connector and these lines indicate the secure connection. And the provider of the VPN offers me a secure internet connection. But this means all my traffic goes through this external provider. But you should really think about whether you really want to do this. Not the possibility would be a parallel model for installation. So there is the normal connection to the internet, but there's also the VPN connector for the TI connections. They go through the connector, but the other traffic goes straight from the office to the internet. And the connection of the connector actually is truly done by an external party that is local. And over 90 percent of the practices are connected in the parallel mode. But these are not automatically insecure because if I already have a network which is on the internet anyway, even with a firewall, I thought about all things. I have a secure email client and I'm on the internet. And then I want to connect the connector. Then personally I would also do it with the parallel model because I don't want to route all my traffic through this third party. But the problem is if my practice is not connected to the internet yet and then there's this external service provider and he is paid by the action. So he doesn't want to do too much work. So he usually does the easiest thing to fulfill the minimum requirements. But what happens? Where does he get his information from? He has a handbook and he looks inside and there it's written, okay, turn off TLS and authentication because it only creates problems. That is actually in the confidential technician handbook. But if it's written there, you know, they will do it probably. And there's the acoustic pin protection and then it is recommended to talk to the doctor to decrease the volume of that. The doctor of course will say, I don't know what this is about. Do whatever you want. This is pretty loud. So turn it off. And in the handbook it's written only the maximum volume of 10 is actually out. So actually I'm working against the specifications already. So now the TI in public media or in public opinion, for example on ZDF, the second German television network, there was a, they talked about it and there was a trojan house on the practice network. And they showed that if this is the case, then I can actually intercept the data of the electronic health insurance card. But the relevancy of the other protection mechanisms is questionable once you have a trojan on your system because the trojan could just read the unequipped data anyway that you have stored. So you don't need access to the telematic infrastructure. So we should really discuss this because this is a big problem. And we really should change this to be more correctly implemented. I think other connection infrastructure projects, they have, they are actually currently suing the telematic infrastructure because it is insecure. And they are actually against the centralization of data storage. So they actually want to decentralize this at the different providers. And this is voluntary and personally, of course, I would also wish for something that I can do voluntarily and save it decentralized on a voluntary basis. But they who actually criticize the centralization of data storage actually also save the data centrally. So this is a little bit inconsistent because if you criticize this, you shouldn't be doing it yourself, right? But maybe they're doing it because of other reasons that are unknown. So my conclusion about the telematic infrastructure, so we have to really increase the detail and quality of the specification. It can't be that some technician just drives there, plugs something in and then it is supposedly working. We really have to make sure that we improve this. And we have, we had the chance to increase the security level of all German doctors offices. But we missed that chance to make it mandatory. And the actual tutorials for the staff were sometimes even more like a sales pitch than an actual educational program. And we have to include the doctors more in the creation of the specification. So if you look at the requirements of the handbook and then look at reality, they're not compatible. So we have to ask doctors what they think of this. And if we can convince the doctors, then perhaps we can also reach the patients. We also, I'm also wishing for more transparency. So the report they do on security, it is pretty slim. Effectively only six pages which say everything is secure, don't worry. So for example, I would love to see the pen test results. They could be published. I would like to see that. So finally e-health, we won't be able to stop it. It will become more digital. Nobody wants to send analog extra pictures or at least it would be easier if this was digital. But I also want to make sure I don't want to stop it in every single aspect of health. But we have to make sure that we evaluate correctly where it is a valuable addition. And we should look at all the different components and make sure that they are as secure as possible. And with this, I want to thank you. You've been listening to and Kaste for the translation of the talk e-health. We would be very grateful for any feedback via Twitter using the hashtag at C3ET. Until next time, thank you very much for listening. We're now going to go to the Q&A. Are there any things with the TI, some mode of lawful interceptions, so can the government actually ask them to provide data? I'm always only talking about the current specification and obviously laws and specifications can change. Currently, this is not the case. I'm thinking about the EPA. And only the patient is allowed to authorize and access that data. And the key is not exportable in order. It's only exportable for a backup, but that's about it. The key export is also tied to the secret sharing scheme. So this is not specified in a way that lawful interceptions possible. What isn't really clear to me is what the doctor first collect all the data into their internal system and what if the doctor is not allowed to look at it and he's not allowed to copy it, but obviously you have to make sure that if you give them access, they can also copy it. You cannot prevent them from making a copy. If the data is wrong, they actually have to correct it and they can copy it. Thank you for the talk. One question about the VP and appliances, which are now in every doctor's office. What about backups and configuration updates and thermal updates? Recently, there was a case at the telecom where a few parts were overlooked. Is there any specification for updates? Is it centralized from the TI or is it locally done by the service providers? The updates for the reader and the connector are being pushed centrally. It's not mandatory. They cannot actually push it, neither the schematic nor the ops team. The doctor has to authorizes and depending on the kind of contract they have for the update. They can also download it themselves from the web self interface of the connector and for the updates it's the case that they actually have to be certified. A question from the internet. Looking at the IT know how and the demographic situation, what is the expected usage in percent of the electronic health record? Good question. I'd rather assume that it's the younger folks that are using it. I honestly don't know. I can only have a guesstimate. There are no numbers publicly available. There are only pre-test studies that were done in advance, but I don't know the number. Sorry. Thank you for the talk. What about if I say I actually write my own health file app or there is an open source program and I compile it myself and I host it myself. Can I do this? Can I certify myself somehow to be eligible? No, that's not something that was provided for. You would need a central authorization through the PSI and the schematic and you need access to the system. You don't get that without the certification and you have to walk up to the schematic or going to verify you against all sorts of dependencies and requests that they have and it's not actually considered valid then to use open source software in this case. So there was a slide about better crypto for email. Who can use this and how can I use this with my doctor? Currently, this is not something they had in mind for the patient only for the service provider. For example, the doctors can exchange mails and doctors letters especially for the x-rays. It's a very common scenario so they can communicate among themselves. They didn't have it in mind to use it for the patients. I would think this is a good idea but they didn't think about it when they specified it. I have two questions. First one, if I understood correctly, this is not for everyone but for the publicly insured. So is it possible to be insured there, to solidate it if you're privately insured? Second question, what happens if we accidentally swap cards? So somebody falls down, they have dementia but they have the wrong card, they're connected now but the data gets mixed there. How can we solve this? As for your first question, the private insurers basically stopped participating in the project 2009. Currently, there are attempts to think about it at least to get on board again for them. They're evaluating how it's working. They didn't have them in mind when doing the specification. It's technically feasible of course but if it's going to come, well, we don't know. We're going to see. For the second question, if the card is identified or is used for the wrong person and if it's attached to the wrong file in the computer for the wrong patient then obviously you're going to have a mix up and you're going to have a bit of a mess in the data and you can possibly, well, get the data from someone else. There's no way to check if it actually matches. Can I take it back? Yeah, as a patient I can definitely delete it. Okay. Well, there's a stand-in if you're not capable of doing it but the patient first has to give them the authorization. So, for example, the doctor is allowed to access the data and there is a stand-in rule that basically you're saying, okay, I want my daughter to take care of this for me and I'm not so sure if the doctor is allowed to delete their own data but the one that they created for the patient. We have five minutes left. Six people at McDonald's, please shorten your questions. Thank you for the talk. I want to motivate why you should look at this continuously from now and 15 years ago when I was working in this field as a consultant, it is clear now today we have to do everything analog still but isn't this really a dead horse which is just eating up billions? So, do you think this will actually become something useful or is it just going to rot? Yeah. Well, it's depending on the estimation but it's between one and a half and three billion. It kind of depends on the kind of requirements that they put out and for the different governing bodies at the gematic under Dr. Rössler and all their ministry of health was he had different ideas in mind and they stopped it and then they had to start it again which took time and money and the current communication is sort of already the future. Basically the communication between patients is something I as a data protection officer I really look forward to because it provides a lot of additional security for the data and I think it's a lot better if the patients actually have a look at the data that they is being saved for them if you go to the doctor and it's sometimes tricky or used to be tricky to get the data that the doctor has on file for you. I'm not sure if EPA is the best way for example decentral storage would also be nice but the important part is that something moves and that something changes towards the better and it looks like it's starting now to get better and we definitely didn't work on it but it's still it looks like we're on a good path. So data is actually encrypted with private providers but for how many years is this crypto actually going to be considered to be good? How can we ensure that the data encrypted today can't be easily decrypted in the future? Well obviously there's no 100% security for this. They're using AS256 and you can speculate if it's going to be broken one day but EPA should be a lifelong file so they're basically banking oh they actually have a method for re-encrypting it every now and then built into the specification and you could change the encryption along the way. So if you realize at some point that there is an attack on AES then you could v-key it to a different encryption algorithm for you. This is being done right now because they're going to ECC so elliptic curves so if there's a break for for AES then your data would suddenly be readable so if if there is a new attack definitely would be readable. The doctor is responsible for the data that he created in his practice. How can I trust the system that it is actually secure? Legally speaking I'm not a lawyer of course but the patient has to give access and the doctor can say that the patient did the access permission or they gave permission to access it so he doesn't have any way to legally say secure his position he can only look at the specification which is well questionable. He cannot really check it what where the data is going so he they can only put in the data and then upload it but obviously he or she cannot personally audit what is happening today after that fact because he's not running the system but thank you for the talk and for showing us the errors in the CDF coverage. Another question about the technicians handbook where for example it's written that TLS should be turned off who made this handbook they're probably different variants but who wrote this and who's being critiqued here? One of many different manuals different tutors. So this concludes this talk and Q&A unfortunately not everybody could ask the questions but thank you so much for your attention thank you for coming here and we now say goodbye to Christoph with a warm round of applause.