## 3 Consumer Products and Active Implantable Medical Devices
### Security Trade-offs in Active Implantable Medical Device Designs
**Security _vs._ accessibility**: An AIMD must be secure against an attacker on a day-to-day basis, but in an emergency situation that same device must allow for accessibility by previously unauthorized personnel (e.g. emergency room physicians or paramedics) [45]. An AIMD cannot easily differentiate between these scenarios in order to vary security settings, this due to a lack of physical access to the AIMD and aforementioned power constraints on it. Designers of an AIMD, then, might consider criticality-aware access policies infeasible (see [48] for reading on criticality-aware access policies). Solutions for secure AIMD accessibility which are completely internal to an AIMD (that is, without a paired external device) have been proposed. One such solution proposes that AIMDs emit an audible warning during communication sessions, thereby enabling a patient to physically leave the communication range of unauthorized communicators [46]. It has been proposed that AIMDs and their programmers can mutually authenticate one another via observed physiological signals (for example, heart rate variability). These mutually observed signals would be used as the basis for a biometric encryption and authentication scheme between programmer and AIMD [49, 50]. **Security _vs._ functionality**: As computational and medical hardware continue making strides in power efficiency, it is possible to put more functionality on-board an AIMD. Designers should analyze these functionalities to ensure they do not introduce excessive security or patient safety risks. For example, the ability to reprogram or otherwise communicate with an AIMD from a long distance is of great benefit medically, but unfortunately also allows attackers to carry out malicious activities from a long distance. Similarly, strong authentication between AIMDs and communicating devices is desired from a security standpoint, but latencies introduced by such a system may be medically unacceptable [46]. **Security _vs._ data retention**: Though a medical practitioner might desire an AIMD to contain a patient's entire medical history, this would allow a successful attacker access to the patient's history. Designers should evaluate the trade-offs between inclusion of data, the desire to keep that data out of an attacker's hands, and the effectiveness of device security measures. Beyond the trade-offs of AIMD design described above, specific attacks on AIMDs are possible, including attacks against anonymity. Any communication system deployed in an AIMD must guard against denial of service attacks. Such attacks might include blocking of computational resources, depletion of energy reserves, or jamming of communications channels [45]. An AIMD utilizing a challenge-response authentication protocol might be susceptible to all three of these defects: generating a response utilizes computational resources, wireless communication utilizes significant energy reserves, and that same wireless communication further consumes communications channel bandwidth. An AIMD can mitigate these attacks by filtering communication from devices which are known, or reasonably suspected, to be malicious [51, 52]. Efficiently and accurately categorizing third party devices as malicious remains a challenge.