1Introduction toEmbedded SystemsEdward A. Lee & Sanjit A. SeshiaUC BerkeleyCopyright © 2008-date, Edward A. Lee & Sanjit A. Seshia, All rights reserved(however, see notice on slide 6 for material used in this lecture)SecurityLee & Seshia, UC Berkeley: 2What is Security?(compare with:Reliability = [the fraction of time that / whether] a system performs its specified function for a specified period of time under stated operating conditions )What’s different:New kinds of functionsWorst-case adversarial conditions2Lee & Seshia, UC Berkeley: 3What is Security?Secrecy/PrivacyCan secret data be leaked to an attacker?IntegrityCan the system be modified by the attacker?AvailabilityIs the system always able to perform its function? (Is “denial-of-service” possible?)Lee & Seshia, UC Berkeley: 4About this LectureSecurity is increasingly a major concern for embedded systems designers Automotive, avionics, medical devices, control systems, …Need to know about the security pitfalls in design & implementation of embedded systemsTake CS 161 to learn about computer security in general.3Lee & Seshia, UC Berkeley: 5Main topic discussed todayAnalysis of security properties of an Implantable Cardioverter Defibrillator (ICD)An ICD is one kind of IMDIMD = Implantable Medical DeviceIMDs are used to monitor chronic disorders and treat patients with automatic therapiesLee & Seshia, UC Berkeley: 6ReferenceThis lecture is mostly based on the following article that appeared in May 2008:“Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses”, Daniel Halperin, Thomas S. Heydt-Benjamin, Benjamin Ransford, Shane S. Clark, Benessa Defend, Will Morgan, Kevin Fu, Tadayoshi Kohno, William H. Maisel, IEEE Symposium on Security and Privacy, May 2008.Images and material from the paper reproduced here is the work of the above authors and © IEEE and the authors4Lee & Seshia, UC Berkeley: 7Warning (adapted from CS 161)This lecture discusses vulnerabilities in IMDs. This is notintended as an invitation to go exploit those vulnerabilities. It is important that we be able to discuss real-world experience candidly, and students are expected to behave responsibly.Berkeley policy is very clear: you may not break into machines that are not your own; you may not attempt to attack or subvert system security. Breaking into other people's systems is inappropriate, and the existence of a security hole is no excuse.Unethical or inappropriate actions may result in failing the course and being referred for further disciplinary action. Lee & Seshia, UC Berkeley: 8What an ICD doesPacingPeriodically send a small electrical stimulus to the heartDefibrillationOccasionally send a larger shock to restore normal heart rhythm5Lee & Seshia, UC Berkeley: 9The ICD ProgrammerThe “programmer” is a device intended to be used to: perform diagnostics  read and write private (patient) data adjust therapy settingson the ICD.Programmer communicates with ICD wirelessly. typically 175 kHz short-range communication Lee & Seshia, UC Berkeley: 10Analysis done in the Paper: Threat/Attacker ModelsConsidered attacks on ICD security by three classes of attackers: Attacker possessing an ICD programmer Attacker who simply eavesdrops on communications between an ICD and the programmer, using commodity software radio Attacker who eavesdrops as well as generates arbitrary RF traffic to the ICD, possibly spoofing an ICD programmer.Demonstrated that successful attacks are possible under all three classes!6Lee & Seshia, UC Berkeley: 11Results of Experiments by Halperin et al.Lee & Seshia, UC Berkeley: 12Communication between ICD & Programmer Inside the ICD is a magnetic switchProgrammer “head” has a magnet whose field closes this switch, which causes the ICD to transmit telemetry data, including EKG readings7Lee & Seshia, UC Berkeley: 13Main Concepts to Discuss Dangers of sending messages in cleartext  How protocols can be reverse engineered Power matters  Use of “Zero-power” protocols Security fundamentals  Encryption, nonces, Trusted Computing Base (TCB)Lee & Seshia, UC Berkeley: 14Equipment UsedoscilloscopeantennasICD USRP8Lee & Seshia, UC Berkeley: 15Methodology to Reverse Engineeer Protocol Connected antenna to recording device (oscilloscope, USRP – universal s/w radio peripheral) Placed antenna within cms of ICD/programmer Demodulated the RF signals picked up – used spectral analysis to determine modulation technique (e.g., 2-FSK for programmer) Decoded demodulated output – by transmitting a known message like AAAA – and trying different well-known encoding schemes (e.g., Non-Return-to-Zero-Inverted – NRZI)Lee & Seshia, UC Berkeley: 16Transaction Timeline of the ProtocolThis timeline can be followed in a “replay attack”9Lee & Seshia, UC Berkeley: 17Replay Attacks using a Commodity Software Radio Triggering ICD identification Disclosing patient data (name, diagnosis, etc.) Disclosing cardiac data  Changing patient name Setting the ICD’s clock Changing therapies (e.g. disabling therapies) Inducing fibrillation (using a feature to test the device) Safeguards can be bypassed (because they are built into the commercial programmer) Power denial of service attack: make ICD keep transmittingLee & Seshia, UC Berkeley: 18Proposed Defenses: Goals1. Prevent/Deter attacks using both custom equipment and commercial programmer devices2. Security should draw no power from the primary battery of the ICD3. Security-sensitive events should be effortlessly detectable by the patient4. New security mechanisms should not introduce new failure modes Qn. What about a ‘traditional’ security approach that encrypts all data using a key that is embedded into the ICD at manufacture time?10Lee & Seshia, UC Berkeley: 19Proposed Defenses: Goals1. Prevent/Deter attacks using both custom equipment and commercial programmer devices2. Security should draw no power from the primary battery of the ICD3. Security-sensitive events should be effortlessly detectable by the patient4. New security mechanisms should not introduce new failure modesSolutions: “Zero-Power” Techniques for Notification, Authentication, and Key-ExchangeLee & Seshia, UC Berkeley: 20Wireless Identification and Sensing Platform (WISPer) for NotificationGoal: Cause the ICD to beep when programmer initiates RF communicationApproach: