@article{GierlingSaatjohannDresenetal.2020,
  author    = {Gierling, Markus and Saatjohann, Christoph and Dresen, Christian and K{\"o}be, Julia and Rath, Benjamin and Eckardt, Lars and Schinzel, Sebastian},
  title     = {Reviewing Cyber Security Research of Implantable Medical Rhythm Devices regarding Patients' Risk},
  series = {86. Jahrestagung und Herztage 2020 der DGK},
  volume    = {Band 109, Supplement 1, April 2020},
  journal   = {86. Jahrestagung und Herztage 2020 der DGK},
  doi       = {10.1007/s00392-020-01621-0},
  pages     = {1 -- 2},
  year      = {2020},
  abstract  = {Introduction: The recent publication of several critical cyber security issues in cardiac implantable devices and the resulting press coverage upsets affected users and their trust in medical device producers. Reviewing the published security vulnerabilities regarding networked medical devices, it raises the question, if the reporting media, the responsible security researchers, and the producers handle security vulnerabilities appropriately. Are the media reports of security vulnerabilities in medical devices meaningful in a way that patients can assess their respective risk for an attack via the security vulnerability? The collaboration between IT-security experts and clinicians aims at reviewing published security vulnerabilities of rhythm devices, and evaluate overall patients risks. Methodology: We performed a literature review on security vulnerabilities in implantable medical devices with a focus on cardiac devices. We analyzed (Fig. 1) the (1) requirements for an attacker and the (2) technical feasibility and clustered them in three different scenarios: The first scenario requires that the attacker physically approaches a victim with a programming device. The second scenario requires proximity to the victim, e.g., within a few meters. The third and strongest attacker scenario is a remote attack that doesn't require any physical proximity to the victim. We then compare the attacker scenarios and (3) the overall patients' risks with the press coverage (overhyped, adequate, underhyped). (4) The resulting overall patients' risk was rated by clinicians (security vulnerability of patients' data, dangerous programming possible). Results: Out of the three analyzed incidents, we found one to be underhyped, one to be overhyped, and one was appropriate compared to the medial coverage (Fig. 2). The most occurring technical issues were based on the absence of basic security primitives. The patient damage for all of the analyzed incidents was fatal in the worst-case scenario. Further, the patient damage and the overall patient risks are disjunct due to the missing capability of performing large scale attacks. Conclusion: The resulting overall patients' risks may not adequately reflect the patient damage in the considered cases. Often, the overall patient risk is not as severe as the necessary attacker capabilities are high and it would require strongly motivated attackers to perform the attack. Therefore, most of the reviewed cases are considered with a smaller overall patient risk than implied by press reports. Reviewing the ongoing IT-Security trends regarding implantable medical devices shows an increasing focus on researching in the field of medical device security. Therefore, further findings in the near future are to be expected. To deal with this fact in a responsible way, proper proactive knowledge management is mandatory. We recommend medical staff to critically reflect reports in mass media due to possible sensationalism. Therefore, we propose a joint approach in combining the technical expertise of cyber security experts with clinical aspects of medical experts, to ensure a solid understanding of a newly published vulnerability. The combination of both communities promises to result in better predictions for patients' risks from security vulnerabilities in implanted cardiac devices.},
  language  = {en}
}
@inproceedings{WillingSaatjohannRathetal.2021,
  author    = {Willing, Markus and Saatjohann, Christoph and Rath, Benjamin and Schinzel, Sebastian and Eckardt, Lars and K{\"o}be, Julia},
  title     = {Experiences with General Data Protection Regulations and Remote Monitoring of Implantable Rhythm Devices},
  series = {87. Jahrestagung der Deutsche Gesellschaft f{\"u}r Kardiologie - Herz‑ und Kreislauforschung e.V},
  booktitle = {87. Jahrestagung der Deutsche Gesellschaft f{\"u}r Kardiologie - Herz‑ und Kreislauforschung e.V},
  publisher = {Springer-Verlag GmbH},
  doi       = {10.1007/s00392-021-01843-w},
  year      = {2021},
  language  = {en}
}
@inproceedings{IsingPoddebniakKappertetal.2023,
  author    = {Ising, Fabian and Poddebniak, Damian and Kappert, Tobias and Saatjohann, Christoph and Schinzel, Sebastian},
  title     = {Content-Type: multipart/oracle -- Tapping into Format Oracles in Email End-to-End Encryption},
  series = {32nd USENIX Security Symposium},
  booktitle = {32nd USENIX Security Symposium},
  publisher = {USENIX Association},
  year      = {2023},
  abstract  = {S/MIME and OpenPGP use cryptographic constructions repeatedly shown to be vulnerable to format oracle attacks in protocols like TLS, SSH, or IKE. However, format oracle attacks in the End-to-End Encryption (E2EE) email setting are considered impractical as victims would need to open many attacker-modified emails and communicate the decryption result to the attacker. But is this really the case? In this paper, we survey how an attacker may remotely learn the decryption state in email E2EE. We analyze the interplay of MIME and IMAP and describe side-channels emerging from network patterns that leak the decryption status in Mail User Agents (MUAs). Concretely, we introduce specific MIME trees that produce decryption-dependent net work patterns when opened in a victim's email client. We survey 19 OpenPGP- and S/MIME-enabled email clients and four cryptographic libraries and uncover a side-channel leaking the decryption status of S/MIME messages in one client. Further, we discuss why the exploitation in the other clients is impractical and show that it is due to missing feature support and implementation quirks. These unintended defenses create an unfortunate conflict between usability and security. We present more rigid countermeasures for MUA developers and the standards to prevent exploitation.},
  language  = {en}
}