Implantable medical devices, such as implantable cardiac defibrillators and pacemakers, now use wireless communication protocols vulnerable to attacks that can physically harm patients. Security measures that impede emergency access by physicians could be equally devastating. We propose that access keys be written into patients’ skin using ultraviolet-ink micropigmentation (invisible tattoos). 1 The IMD Key Storage Problem Life-critical implantable medical devices (IMDs) are becoming increasingly commonplace. The most familiar, the pacemaker, is implanted into a million patients each year [11] and generates $1.98 billion for market leader Medtronic alone [10, p22]. Implantable cardiac defibrillators (ICDs) grew in popularity starting in 1990 [8]. Recently, researchers have raised concerns about IMDs use of wireless protocols; the of lack authentication and integrity mechanisms put patients at risk from attack by anyone with a transmitter [5, 6, 7]. Cryptographic authentication and integrity-protection would require an access key available to authorized physicians but not attackers. In emergencies, patients may require the care of physicians not previously authorized to access the device. Emergency physicians cannot rely on patients to be conscious to provide access keys. RFID tags, such as the VeriChip [13], cannot be used to store access keys as they provide no defense against malicious key requests. Access keys could be stored on medical bracelets, as are used to disclose conditions such as diabetes in emergencies [7]. Denning et al. proposed a medical bracelet that would prevent access to IMDs when worn and that would be removed in an emergency [3, 4]. Regardless of whether bracelets provide or prevent access, patients may lose or forget these bracelets and the mere presence of a bracelet reveals a patient’s condition to potential attackers. 2 Encoding keys as UV-Ink Tattoos We propose that a user-selected human-readable key be encoded directly onto patients using ultraviolet-ink micropigmentation, adjacent to the point of implantation. To increase reliability the encoding could be augmented to include an error correcting code and/or be replicated in full on the base of the patient’s leftmost foot—at the arch. All devices used to communicate with the IMD would be equipped with a small, reliable, and inexpensive ultraviolet light emitting diode (UV LED) and an input mechanism for key entry (a keypad or touch-screen). A single key would be sufficient for multiple devices and could be re-used when devices are replaced. The key encodings could take the form of user chosen character strings (optimizing for user choice), random character strings (optimizing for minimal size), or strings of hieroglyphic-like images chosen from a subset deemed acceptable to the user. The first option gives the greatest control to reluctant patients, whereas latter two options guarantee a minimum level of key entropy and can easily be augmented with error correcting codes. Each patient would be allowed to request new random encodings until finding one he or she deemed acceptable. 3 Safety, security, and reliability The biggest safety concern with UV micropigmentation the UV ink formulations used in tattoo’s today have not yet been sufficiently refined to minimize skin irritations and proven free of long-term health risks [12]. Unlike bracelets, UV micropigmentation does not advertise the presence of the IMD to potential attackers. When not covered by clothing, the UV ink can be hidden by UV-blocking sunscreen. Anyone close enough to read a patient’s tattoo is already close enough to harm the patient using other forensically untraceable mechanisms. Also unlike bracelets, patients cannot forget their tattoo. Placing micropigmented encodings adjacent to scars

We evaluate website authentication measures that are designed to protect users from man-in-the-middle, 'phishing', and other site forgery attacks. We asked 67 bank customers to conduct common online banking tasks. Each time they logged in, we presented increasingly alarming clues that their connection was insecure. First, we removed HTTPS indicators. Next, we removed the participant's site-authentication image-the customer-selected image that many websites now expect their users to verify before entering their passwords. Finally, we replaced the bank's password-entry page with a warning page. After each clue, we determined whether participants entered their pass-words or withheld them.We also investigate how a study's design affects participant behavior: we asked some participants to play a role and others to use their own accounts and passwords. We also presented some participants with security-focused instructions.We confirm prior findings that users ignore HTTPS indicators: no participants withheld their passwords when these indicators were removed. We present the first empirical investigation of site-authentication images, and we find them to be ineffective: even when we removed them, 23 of the 25 (92%) participants who used their own accounts entered their passwords. We also contribute the first empirical evidence that role playing affects participants' security behavior: role-playing participants behaved significantly less securely than those using their own passwords.

We examine the code base of the OpenBSD operating system to determine whether its security is increasing over time. We measure the rate at which new code has been introduced and the rate at which vulnerabilities have been reported over the last 7.5 years and fifteen versions. We learn that 61% of the lines of code in today's OpenBSD are foundational: they were introduced prior to the release of the initial version we studied and have not been altered since. We also learn that 62% of reported vulnerabilities were present when the study began and can also be considered to be foundational. We find strong statistical evidence of a decrease in the rate at which foundational vulnerabilities are being reported. However, this decrease is anything but brisk: foundational vulnerabilities have a median lifetime of at least 2.6 years. Finally, we examined the density of vulnerabilities in the code that was altered/introduced in each version. The densities ranged from 0 to 0.033 vulnerabilities reported per thousand lines of code. These densities will increase as more vulnerabilities are reported.

Address harvesting is the act of searching a compromised host for the names and addresses of other targets to attack, such as occurs when an email virus locates target addresses from users’ address lists or mail archives. We examine how host addresses harvested from Secure Shell (SSH) clients’ known hosts files can aid those attacking SSH servers. Each user’s known hosts file contains the names of every host previously accessed by its owner. Thus, when an attacker compromises a user’s password or identity key, the known hosts file can be used to identify those hosts on a network that are most likely to accept this compromised credential. Such attacks are not theoretical – a single attacker who targeted host authentication via SSH and employed known hosts address harvesting was able to gain access to a multitude of academic, commercial, and government systems. To show the value of known hosts files to such attackers, we present results of a study of known hosts files and other data collected from 173 hosts distributed over 25 top level domains. We also collected data on users’ credential management practices, and discovered that 61.7% of the identity keys we encountered were stored unencrypted. To show how host authentication attacks via SSH could evolve if automated, we survey mechanisms used to attack and their suitability for use in self-propagating code. Finally, we present countermeasures devised to defend against address harvesting, which have been adopted by the OpenSSH team and one of the two main commercial SSH software vendors.

The deployment of network-wide security enhancements to the Internet has proven more dicult than many had initially anticipated. We leverage existing models of networks’ value to model the problem of bootstrapping the adoption of security technologies. We describe a variety of policy interventions and deployment strategies that can help to catalyze this adoption. Using this framework, we provide a series of short case studies for previous attempts to deploy security technologies to the Internet. We then provide a detailed study of strategies for deploying the security-enhanced protocols into the Internet’s Domain Name System (DNS). Finally, we show how the adoption of these DNS security enhancements can help to alleviate bootstrapping problems that have impeded the deployment of other security-enhanced protocols.

ConclusionTo thwart piracy the entertainment industry must keep distribution costs high, reduce the size of distribution networks, and (if possible) raise the cost of extracting content. However, if ‘trusted computing’ mechanisms deliver on their promises, large peer-to-peer distribution networks will be more robust against attack and trading in pirated entertainment will become safer, more reliable, and thus cheaper. Since it will always be possible for some individuals to extract content from the media on which it is stored, future entertainment may be more vulnerable to piracy than before the introduction of ‘trusted computing’ technologies.

Worm detection and response systems must act quickly to identify and quarantine scanning worms, as when left unchecked such worms have been able to infect the majority of vulnerable hosts on the Internet in a matter of minutes [9]. We present a hybrid approach to detecting scanning worms that integrates significant improvements we have made to two existing techniques: sequential hypothesis testing and connection rate limiting. Our results show that this two-pronged approach successfully restricts the number of scans that a worm can complete, is highly effective, and has a low false alarm rate.

We address the question of how much security is required to protect a packaged system, installed in a large number of organizations, from thieves who would exploit a single vulnerability to attack multiple installations. While our work is motivated by the need to help organizations make decisions about how to defend themselves, we also show how they can better protect themselves by helping to protect each other.

The damage inflicted by viruses and worms has been limited by the risks that come with the more lucrative payloads. The problem facing authors of self-reproducing malware is that monetizing each intrusion requires the author to risk communication with the infected system. Malware authors looking to minimize risk and maximize loot have been better off carefully targeting trojan horses at a few systems at a time. However, this could change if malware authors could infect a large number of systems using a worm and sell access to infected systems to other black hats. We introduce a new type of worm that enables this division of labor, installing a back door on each infected system that opens only when presented a system-specific ticket generated by the worm's author. The risk to the worm's author is minimized because he need not communicate with the infected systems. This new class of attack could increase the incentives to write malware and create a market for such specialized skills. In addition to describing this new threat, we propose a number of approaches for defending against it.

Webmasters often use the following rule of thumb to ensure that HTTP server performance does not degrade when traffic is its heaviest — provide twice the server capacity required to handle your site's average load. As a result the server will spend half of its CPU cycles idle during normal operation. These cycles could be used to reduce the latency of a significant subset of HTTP transactions handled by the server. In this paper we introduce the use of path profiles for describing HTTP request behavior and describe an algorithm for efficiently creating these profiles. We then show that we can predict request behavior using path profiles with high enough probability to justify generating dynamic content before the client requests it. If requests are correctly predicted and pre-generated by the server, the end user will witness significantly lower latencies for these requests.

Program profiling is a mechanism that is useful for performance evaluation and code optimization. Profiling techniques that provide detailed information with extremely low overhead are especially important for systems that continuously monitor or dynamically optimize running executables. In this paper, we describe an approach for program profiling called ephemeral instrumentation and show that it collects useful profiles with low overhead. This approach builds on ideas from both program instrumentation and statistical sampling; it produces binaries that are able to periodically record aspects of their executions in great detail. It works because program behavior is predictable and because we are able to convert ephemeral profiles into traditional formats. This paper describes an ephemeral instrumentation system for gathering branch biases and post-processing that data into a traditional edge profile. We evaluate the usefulness of such profiles by using them to drive a superblock scheduler. Our experimental results show that we can gather ephemeral profiles with extremely low overheads (1-5%) while acquiring profile data that rivals the usefulness of complete profiles gathered at much higher overheads.

Worm detection and response systems must act quickly to identify and quarantine scanning worms, as these pathogens have been able to infect the ma- jority of vulnerable hosts on the Internet in a matter of minutes (11). On the other hand, detection sys- tems that issue false alarms, quarantining too many systems or even just one critical system, are likely to be deactivated quickly. We present a hybrid ap- proach to detecting scanning worms that integrates significant improvements we have made to two ex- isting techniques; sequential hypothesis testing and scan connection rate limiting. Our results show that this two-pronged approach successfully restricts the number of scans that a worm, is highly eective, and has a low false alarm rate.

The damage inflicted by viruses and worms has been limited because the payloads that are most lucrative to malware au- thors have also posed the greatest risks to them. The prob- lem facing authors of this self-reproducing malware is that monetizing each intrusion requires the author to risk com- munication with the infected system or its owner. The tool of choice for malware authors looking to minimize risk and maximize loot has been the carefully target attack, often employing a trojan horses or attack script. However, at- tacker's preferences would likely change if they could infect a large number of systems using a worm and sell access to infected systems to other black hats. We introduce a new type of worm that enables this division of labor, installing a back door on each infected system that opens only when presented a system-specific ticket generated by the worm's author. The risk to the worm's author is minimized because he need not communicate with the infected systems. This new class of attack could increase the incentives to write malware and create a market for such specialized skills. In addition to describing this new threat, we propose a number of approaches for defending against it.