1<!DOCTYPE html> 2<html lang="en"> 3<head> 4 <meta charset="utf-8"> 5 <meta name="description" content="J. Alex Halderman - Publications"> 6 <meta name="viewport" content="width=device-width, initial-scale=1.0"> 7 <title>J. Alex Halderman - Publications</title> 8 <link rel="stylesheet" href="../home/common.css"> 9 <style> 10 .toggler { font-family: helvetica, arial, sans-serif; font-size: 12px; color: #aaa; } 11 .toggler:hover { color: #4A78BA; } 12 .abstract, .spacer { margin: 0 0 18px 0; padding: 12px 1px 1px 1px; } 13 .abstract > a.toggler { position: absolute; padding-left: 13px; margin-top: -7.28px; } 14 .toggleOff > a.toggler { background: url(../home/plus.png) center left no-repeat; } 15 .toggleOn > a.toggler { background: url(../home/minus.png) center left no-repeat; } 16 .abstract > p { display: none; font-size: 91%; margin: 8px 0 0 13px; text-align: justify; } 17 .toggleOn > p { display: block; } 18 .title { margin-bottom: 2px; } 19 .title > a { font-weight: bold; } 20 .altlink { margin-left: 6px; } 21 .tt { font-family: monospace; } 22 #expandall { height: 20px; margin: 3px 0; } 23 @media screen { h3#top { margin-top: 0; } } 24 @media print { .toggler, .altlink, #expandall { display: none; } } 25 </style> 26
26<script> 27 document.addEventListener('DOMContentLoaded', () => { 28 const abstracts = Array.from(document.getElementsByClassName('abstract')); 29 30 function makeToggler(text, onClick) { 31 const a = document.createElement('a'); 32 a.className = 'toggler'; 33 a.href = '#'; 34 a.textContent = text; 35 a.addEventListener('click', (e) => { e.preventDefault(); onClick(); }); 36 return a; 37 } 38 39 function setOpen(div, open) { 40 div.classList.toggle('toggleOn', open); 41 div.classList.toggle('toggleOff', !open); 42 } 43 44 function allOpen() { 45 return abstracts.every((div) => div.classList.contains('toggleOn')); 46 } 47 48 const expandAll = makeToggler('Expand all abstracts', () => { 49 const open = !allOpen(); 50 abstracts.forEach((div) => setOpen(div, open)); 51 updateExpandAll(); 52 }); 53 document.getElementById('expandall').appendChild(expandAll); 54 55 function updateExpandAll() { 56 expandAll.textContent = allOpen() ? 'Close all abstracts' : 'Expand all abstracts'; 57 } 58 59 abstracts.forEach((div) => { 60 setOpen(div, false); 61 div.prepend(makeToggler('Abstract', () => { 62 setOpen(div, !div.classList.contains('toggleOn')); 63 updateExpandAll(); 64 })); 65 }); 66 }); 67 </script>
67 68</head> 69<body> 70 71 <div class="fore"> 72 <h1>Publications</h1> 73 <h2> 74 <span class="morelinks"> 75 <a href="https://scholar.google.com/citations?user=h6yXnyEAAAAJ">» <span class="wide">Google Scholar</span><span class="narrow">Scholar</span></a> 76 <a href="../">» home</a> 77 </span> 78 <a href="../">J. Alex Halderman</a> 79 </h2> 80 81 <div id="expandall"></div> 82 83 <h3 id="top">Peer-reviewed research papers</h3> 84 85 <div class="citation"> 86 <div class="title"><a href="https://www.usenix.org/system/files/usenixsecurity26-ablove.pdf">Technical Analysis of the Geedge Networks Firewall Source Code Leak</a></div> 87 <div class="author">Anna Ablove, Johnnie Walker, Ben Wolin, Niklas Niere, Felix Lange, Aaron Ortwein, Armin Huremagic, Richa Priyanka, Ali Zohaib, Jade Sheffey, Nico Heitmann, J. Alex Halderman, Juraj Somorovsky, Amir Houmansadr, Roya Ensafi, Mingshi Wu, and Eric Wustrow</div> 88 <div class="ref"><i>35th USENIX Security Symposium</i>, August 2026</div> 89 <div class="abstract"> 90 <p>In September 2025, over 100K internal documents (including code, 91 communications, etc.) from Geedge Networks, a Chinese DPI company with 92 ties to the Great Firewall of China, were leaked to the public. In this 93 paper, we analyze the source code from this leak, focusing on Geedge 94 Networks’ flagship product, the Tiangou Secure Gateway (TSG) 95 firewall. Working across multiple repositories, we successfully build 96 and run a local copy of TSG—revealing key aspects of its 97 architecture, including the protocols it is capable of parsing and the 98 format of blocking rules used to censor sites, proxies, and other 99 resources. Finally, we extract several fingerprints from TSG, including 100 custom random number generators and parsing idiosyncrasies that allow us 101 to identify its use and similar deployments in the Great Firewall of 102 China.</p> 103 <p>This is the first time that the source code of a commercial DPI has 104 been leaked, and our work is the first code analysis of a core firewall 105 component used in national censorship infrastructure. This unprecedented 106 investigation offers insights that can assist circumvention developers 107 and Internet security researchers in further understanding the 108 capabilities and limitations of modern censorship technology.</p> 109 </div> 110 </div> 111 112 <div class="citation"> 113 <div class="title"><a href="https://pubsonline.informs.org/doi/full/10.1287/opre.2023.0422">Improving the Security of United States Elections with Robust Optimization</a> — <b>Harvey J. Greenberg Research Award</b></div> 114 <div class="author">Braden Crimmins, J. Alex Halderman, and Bradley Sturt</div> 115 <div class="ref"><i>Operations Research</i> 73(1):61-85, January–February 2025</div> 116 <div class="abstract"> 117 <p>For more than a century, election officials across the United States 118 have inspected voting machines before elections using a procedure called 119 logic and accuracy testing (LAT). This procedure consists of election 120 officials casting a test deck of ballots into each voting machine and 121 confirming the machine produces the expected vote total for each 122 candidate. We bring a scientific perspective to LAT by introducing the 123 first formal approach to designing test decks with rigorous security 124 guarantees. Specifically, our approach employs robust optimization to 125 find test decks that are guaranteed to detect any voting machine 126 misconfiguration that would cause votes to be swapped across candidates. 127 Of all the test decks with this security guarantee, our robust 128 optimization problem yields the test deck with the minimum number of 129 ballots, thereby minimizing implementation costs for election officials. 130 To facilitate deployment at scale, we develop a practically efficie
130nt 131 exact algorithm for solving our robust optimization problems based on 132 the cutting plane method. In partnership with the Michigan Bureau of 133 Elections, we retrospectively applied our approach to all 6,928 ballot 134 styles from Michigan’s November 2022 general election; this 135 retrospective study reveals that the test decks with rigorous security 136 guarantees obtained by our approach require, on average, only 1.2% more 137 ballots than current practice. Our approach has since been piloted in 138 real-world elections by the Michigan Bureau of Elections as a low-cost 139 way to improve election security and increase public trust in democratic 140 institutions.</p> 141 </div> 142 </div> 143 144 <div class="citation"> 145 <div class="title"><a href="https://dl.acm.org/doi/pdf/10.1145/3646547.3689012">Ten Years of ZMap</a></div> 146 <div class="author">Zakir Durumeric, David Adrian, Phillip Stephens, Eric Wustrow, and J. Alex Halderman</div> 147 <div class="ref"><i>24th ACM Internet Measurement Conference</i> (IMC), November 2024</div> 148 <div class="abstract"> 149 <p>Since ZMap’s debut in 2013, networking and security researchers 150 have used the open-source scanner to write hundreds of research papers 151 that study Internet behavior. In addition, ZMap has been adopted by the 152 security industry to build new classes of enterprise security and 153 compliance products. Over the past decade, much of ZMap’s 154 behavior—ranging from its pseudorandom IP generation to its packet 155 construction—has evolved as we have learned more about how to scan 156 the Internet. In this work, we quantify ZMap’s adoption over the 157 ten years since its release, describe its modern behavior (and the 158 measurements that motivated changes), and offer lessons from releasing 159 and maintaining ZMap for future tools.</p> 160 </div> 161 </div> 162 163 <div class="citation"> 164 <div class="title"><a href="https://www.usenix.org/system/files/usenixsecurity24-crimmins.pdf">DVSorder: Ballot Randomization Flaws Threaten Voter Privacy</a> <span class="altlink">(<a href="https://dvsorder.org">website and tools</a>)</span></div> 165 <div class="author">Braden L. Crimmins, Dhanya Y. Narayanan, Drew Springall, and J. Alex Halderman</div> 166 <div class="ref"><i>33rd USENIX Security Symposium</i>, August 2024 — <b>Best Paper Award</b></div> 167 <div class="abstract"> 168 <p>A trend towards publishing ballot-by-ballot election results has 169 created new risks to voter privacy due to inadequate protections by 170 election technology. These risks are manifested by a vulnerability we 171 discovered in precinct-based ballot scanners made by Dominion Voting 172 Systems, which are used in parts of 21 states and Canada. In a variety 173 of scenarios, the flaw—which we call DVSorder—would allow 174 attackers to link individuals with their votes and compromise ballot 175 secrecy. The root cause is that the scanners assign pseudorandom ballot 176 identifiers using a linear congruential generator, an approach known 177 since the 1970s to be insecure. Dominion attempted to obfuscate the 178 generator’s output, but we show that it can be broken using only 179 pen and paper to reveal the order in which all ballots were cast. Unlike 180 past ballot randomization flaws, which typically required insider access 181 to exploit or access to proprietary software to discover, DVSorder can 182 be discovered and exploited using only public information.</p> 183 <p>In addition, the election sector’s response to our findings 184 provides a case study highlighting gaps in regulations and vulnerability 185 management within this area of critical infrastructure. Although 186 Dominion released a software update in response to DVSorder, some 187 localities have continued to publish vulnerable data due to inadequate 188 information sharing and mitigation planning, and at least one state has 189 deferred addressing the flaw until after the 2024 presidential election, 190 more than two years following our disclosure.</p> 191 </div> 192 </div> 193 194 <div class="citation"> 195 <div class="title"><a href="https://www.petsymposium.org/foci/2024/foci-2024-0003.pdf">Just add WATER: WebAssembly-based Circumvention Transports</a></div> 196 <div class="author">Erik Chi, Gaukas Wang, J. Alex Halderman, Eric Wustrow, and Jack Wampler</div> 197 <div class="ref"><i>Workshop on Free and Open Communications on the Internet (FOCI)</i>, February 2024</div> 198 <div class="abstract"> 199 <p>As Internet censors rapidly evolve new blocking techniques, 200 circumvention tools must also adapt and roll out new strategies to 201 remain unblocked. But new strategies can be time consuming for 202 circumventors to develop and deploy, and usually an update to one tool 203 often requires significant additional effort to be ported to others. 204 Moreover, distributing the updated application across different 205 platforms poses its own set of challenges.</p> 206 <p>In this paper, we introduce WATER (WebAssembly Transport Executables 207 Runtime), a novel design that enables applications to use a 208 WebAssembly-based application-layer to wrap network transports (e.g., 209 TLS). Deploying a new circumvention technique with WATER only requires
210 distributing the WebAssembly Transport Module (WATM) binary and any 211 transport-specific configuration, allowing dynamic transport updates 212 without any change to the application itself. WATMs are also designed to 213 be generic such that different applications using WATER can use the same 214 WATM to rapidly deploy successful circumvention techniques to their own 215 users, facilitating rapid interoperability between independent 216 circumvention tools.</p> 217 </div> 218 </div> 219 220 <div class="citation"> 221 <div class="title"><a href="https://arxiv.org/pdf/2107.10344">Challenges in Cybersecurity: Lessons from Biological Defense Systems</a></div> 222 <div class="author">Edward Schrom, Ann Kinzig, Stephanie Forrest, Andrea L. Graham, Simon A. Levin, Carl T. Bergstrom, Carlos Castillo-Chavez, James P. Collins, Rob J. de Boer, Adam Doupé, Roya Ensafi, Stuart Feldman, Bryan T. Grenfell, J. Alex Halderman, Silvie Huijben, Carlo Maley, Melanie Moses, Alan S. Perelson, Charles Perrings, Joshua Plotkin, Jennifer Rexford, and Mohit Tiwari</div> 223 <div class="ref"><i>Mathematical Biosciences</i>, vol. 362, August 2023</div> 224 <div class="abstract"> 225 <p>We explore the commonalities between methods for assuring the 226 security of computer systems (cybersecurity) and the mechanisms that 227 have evolved through natural selection to protect vertebrates against 228 pathogens, and how insights derived from studying the evolution of 229 natural defenses can inform the design of more effective cybersecurity 230 systems. More generally, security challenges are crucial for the 231 maintenance of a wide range of complex adaptive systems, including 232 financial systems, and again lessons learned from the study of the 233 evolution of natural defenses can provide guidance for the protection of 234 such systems.</p> 235 </div> 236 </div> 237 238 <div class="citation"> 239 <div class="title"><a href="https://arxiv.org/pdf/2207.14394.pdf">Logic and Accuracy Testing: A Fifty-State Review</a></div> 240 <div class="author">Josiah Walker, Nakul Bajaj, Braden L. Crimmins, and J. Alex Halderman</div> 241 <div class="ref"><i>7th International Joint Conference on Electronic Voting</i> (E-Vote-ID ’22), October 2022</div> 242 <div class="abstract"> 243 <p>Pre-election logic and accuracy (L&A) testing is a process in 244 which election officials validate the behavior of voting equipment by 245 casting a known set of test ballots and confirming the expected results. 246 Ideally, such testing can serve to detect certain forms of human error 247 or fraud and help bolster voter confidence. We present the first 248 detailed analysis of L&A testing practices across the United States. 249 We find that while all states require L&A testing before every 250 election, their implementations vary dramatically in scope, 251 transparency, and rigorousness. We summarize each state’s 252 requirements and score them according to uniform criteria. We also 253 highlight best practices and flag opportunities for improvement, in 254 hopes of encouraging broader adoption of more effective L&A 255 processes.</p> 256 </div> 257 </div> 258 259 <div class="citation"> 260 <div class="title"><a href="https://www.usenix.org/system/files/sec22-halderman.pdf">The Antrim County 2020 Election Incident: An Independent Forensic Investigation</a> <span class="altlink">(<a href="https://www.michigan.gov/documents/sos/Antrim_720623_7.pdf">original expert report</a>)</span></div> 261 <div class="author">J. Alex Halderman</div> 262 <div class="ref"><i>31st USENIX Security Symposium</i>, August 2022 — <b>Best Paper Award</b></div> 263 <div class="abstract"> 264 <p>In November 2020, Antrim County, Michigan published unofficial 265 election results that misstated totals in the presidential race and 266 other contests by up to several thousand votes. Antrim subsequently 267 issued a series of corrections, and the certified presidential results 268 were confirmed by a hand count. Nevertheless, Antrim was cited by the 269 President of the United States as evidence of widespread fraud, and it 270 remains a centerpiece of conspiracy theories about the 2020 election. At 271 the request of the Michigan Secretary of State and Attorney General, I 272 performed a forensic investigation of the incident. Using data from the 273 election system, I precisely reproduce the major anomalies, explain 274 their cause, and verify that they have been corrected. I also uncover 275 other errors affecting specific down-ballot contests that have 276 <i>not</i> been corrected, despite the unusual attention focused on the 277 results, one of which may have changed the outcome of a local contest. 278 Based on this analysis, I refute misinformation about the incident, 279 concluding that it was not the result of a security breach but rather a 280 series of operator errors compounded by inadequate procedures and 281 insufficiently defensive software design. These events offer lessons for 282 improving election administration and highlight the value of rigorously 283 investigating election technology incidents for enhancing accuracy and 284 public trust.</p> 285 </div> 286 </div> 287 288 <div class="citation"> 289 <div class="title"><a href="https://www.usenix.org/system/files/sec22fall_xue-diwen.pdf">OpenVPN is Open to VPN Fingerprinting</a></div> 290 <div class="author">Diwen Xue, Reethika Ramesh, Arham Jain, Michalis Kallitsis, J. Alex Halderman, Jedidiah R. Crandall, and Roya Ensafi</div> 291 <div class="ref"><i>31st USENIX Security Symposium</i>, August 2022 — <b>Best Paper Award</b> — <b>Internet Defense Prize Winner</b></div> 292 <div class="abstract"> 293 <p>VPN adoption has seen steady growth over the past decade due to 294 increased public awareness of privacy and surveillance threats. In 295 response, certain governments are attempting to restrict VPN access by 296 identifying connections using “dual use” DPI technology. To 297 investigate the potential for VPN blocking, we develop mechanisms for 298 accurately fingerprinting connections using OpenVPN, the most popular 299 protocol for commercial VPN services. We identify three fingerprints 300 based on protocol features such as byte pattern, packet size, and server 301 response. Playing the role of an attacker who controls the network, we 302 design a two-phase framework that performs passive fingerprinting and 303 active probing in sequence. We evaluate our framework in partnership 304 with a million-user ISP and find that we identify over 85% of OpenVPN 305 flows with only negligible false positives, suggesting that 306 OpenVPN-based services can be effectively blocked with little collateral 307 damage. Although some commercial VPNs implement countermeasures to avoid 308 detection, our framework successfully identified connections to 34 out 309 of 41 “obfuscated” VPN configurations. We discuss the 310 implications of the VPN fingerprintability for different threat models
311 and propose short-term defenses. In the longer term, we urge commercial 312 VPN providers to be more transparent about their obfuscation approaches 313 and to adopt more principled detection countermeasures, such as those 314 developed in censorship circumvention research.</p> 315 </div> 316 </div> 317 318 <div class="citation"> 319 <div class="title"><a href="https://arxiv.org/pdf/2111.08662.pdf">RemoteVote and SAFE Vote: Towards Usable End-to-End Verification for Vote-by-Mail</a></div> 320 <div class="author">Braden L. Crimmins, Marshall Rhea, and J. Alex Halderman</div> 321 <div class="ref"><i>7th Workshop on Advances in Secure Electronic Voting</i>, February 2022</div> 322 <div class="abstract"> 323 <p>Postal voting is growing rapidly in the U.S., with 43% of voters 324 casting ballots by mail in 2020, yet until recently there has been 325 little research about extending the protections of end-to-end verifiable 326 (E2E-V) election schemes to vote-by-mail contexts. The first—and 327 to date, only—framework to focus on this setting is STROBE, which 328 has important usability limitations. In this work, we present two 329 approaches, RemoteVote and SAFE Vote, that allow mail-in voters to 330 benefit from E2E-V without changing the voter experience for those who 331 choose not to participate in verification. To evaluate these systems and 332 compare them with STROBE, we consider an expansive set of properties, 333 including novel attributes of usability and verifiability, several of 334 which have applicability beyond vote-by-mail contexts. We hope that our 335 work will help catalyze further progress towards universal applicability 336 of E2E-V for real-world elections.</p> 337 </div> 338 </div> 339 340 <div class="citation"> 341 <div class="title"><a href="/pub/papers/ballotscanning-evoteid21.pdf">Improving the Accuracy of Ballot Scanners Using Supervised Learning</a></div> 342 <div class="author">Sameer Barretto, William Chown, David Meyer, Aditya Soni, Atreya Tata, and J. Alex Halderman</div> 343 <div class="ref"><i>6th International Joint Conference on Electronic Voting</i> (E-Vote-ID ’21), October 2021</div> 344 <div class="abstract"> 345 <p>Most U.S. voters cast hand-marked paper ballots that are counted by 346 optical scanners. Deployed ballot scanners typically utilize simplistic 347 mark-detection methods, based on comparing the measured intensity of 348 target areas to preset thresholds, but this technique is known to 349 sometimes misread “marginal” marks that deviate from ballot 350 instructions. We investigate the feasibility of improving scanner 351 accuracy using supervised learning. We train a convolutional neural 352 network to classify various styles of marks extracted from a large 353 corpus of voted ballots. This approach achieves higher accuracy than a 354 naive intensity threshold while requiring far fewer ballots to undergo 355 manual adjudication. It is robust to imperfect feature extraction, as 356 may be experienced in ballots that lack timing marks, and efficient 357 enough to be performed in real time using contemporary central-count 358 scanner hardware.</p> 359 </div> 360 </div> 361 362 <div class="citation"> 363 <div class="title"><a href="/pub/papers/omniballot-sec21.pdf">Security Analysis of the Democracy Live Online Voting System</a> <span class="altlink">(<a href="/pub/papers/omniballot-20.pdf">initial public version</a>)</span></div> 364 <div class="author">Michael A. Specter and J. Alex Halderman</div> 365 <div class="ref"><i>30th USENIX Security Symposium</i>, August 2021</div> 366 <div class="abstract"> 367 <p>Democracy Live’s OmniBallot platform is a web-based system for 368 blank ballot delivery, ballot marking, and online voting. In early 2020, 369 three states—Delaware, West Virginia, and New 370 Jersey—announced that they would allow certain voters to cast 371 votes online using OmniBallot, but, despite the well established risks 372 of Internet voting, the system has never before undergone a public, 373 independent security review.</p> 374 <p>We reverse engineered the client-side portion of OmniBallot, as used 375 in Delaware, in order to detail the system’s operation and analyze 376 its security. We find that OmniBallot uses a simplistic approach to 377 Internet voting that is vulnerable to vote manipulation by malware on 378 the voter’s device and by insiders or other attackers who can 379 compromise Democracy Live, Amazon, Google, or Cloudflare. In addition, 380 Democracy Live, which had no privacy policy prior to our work, receives 381 sensitive personally identifiable information—including the 382 voter’s identity, ballot selections, and browser 383 fingerprint—that could be used to target political ads or 384 disinformation campaigns. Even when OmniBallot is used to mark ballots 385 that will be printed and returned in the mail, the softw
385are sends the 386 voter’s identity and ballot choices to Democracy Live, an 387 unnecessary risk that jeopardizes the secret ballot.</p> 388 <p>We recommend changes to make the platform safer for ballot delivery 389 and marking. However, we conclude that using OmniBallot for electronic 390 ballot return represents a severe risk to election security and could 391 allow attackers to alter election results without detection. In response 392 to our findings, Delaware and New Jersey halted their use of OmniBallot 393 for online voting, but it remains available in other jurisdictions, as 394 do similar tools that likely face the same serious risks.</p> 395 </div> 396 </div> 397 398 <div class="citation"> 399 <div class="title"><a href="https://dl.acm.org/doi/pdf/10.1145/3419394.3423665">Investigating Large-Scale HTTPS Interception in Kazakhstan</a></div> 400 <div class="author">Ram Sundara Raman, Leonid Evdokimov, Eric Wustrow, J. Alex Halderman, and Roya Ensafi</div> 401 <div class="ref"><i>20th ACM Internet Measurement Conference</i> (IMC), October 2020</div> 402 <div class="abstract"> 403 <p>Increased adoption of HTTPS has created a largely encrypted web, but 404 these security gains are on a collision course with governments that 405 desire visibility into and control over user communications. Last year, 406 the government of Kazakhstan conducted an unprecedented large-scale 407 HTTPS interception attack by forcing users to trust a custom root 408 certificate. We were able to detect the interception and monitor its 409 scale and evolution using measurements from in-country vantage points 410 and remote measurement techniques. We find that the attack targeted 411 connections to 37 unique domains, with a focus on social media and 412 communication services, suggesting a surveillance motive, and that it 413 affected a large fraction of connections passing through the 414 country’s largest ISP, Kazakhtelecom. Our continuous real-time 415 measurements indicated that the interception system was shut down after 416 being intermittently active for 21 days. Subsequently, supported by our 417 findings, two major browsers (Mozilla Firefox and Google Chrome) 418 completely blocked the use of Kazakhstan’s custom root. However, 419 the incident sets a dangerous precedent, not only for Kazakhstan but for 420 other countries that may seek to circumvent encryption online.</p> 421 </div> 422 </div> 423 424 <div class="citation"> 425 <div class="title"><a href="/pub/papers/refraction-pets20.pdf">Running Refraction Networking for Real</a></div> 426 <div class="author">Benjamin VanderSloot, Sergey Frolov, Jack Wampler, Sze Chuen Tan, Irv Simpson, Michalis Kallitsis, J. Alex Halderman, Nikita Borisov, and Eric Wustrow</div> 427 <div class="ref"><i> 20th Privacy Enhancing Technologies Symposium</i> (PETS), July 2020</div> 428 <div class="abstract"> 429 <p>Refraction networking is a next-generation censorship circumvention 430 approach that locates proxy functionality in the network itself, at 431 participating ISPs or other network operators. Following years of 432 research and development and a brief pilot, we established the 433 world’s first production deployment of a Refraction Networking 434 system. Our deployment uses a high-performance implementation of the 435 TapDance protocol and is enabled as a transport in the popular 436 circumvention app Psiphon. It uses TapDance stations at four physical 437 uplink locations of a mid-sized ISP, Merit Network, with an aggregate 438 bandwidth of 140 Gbps. By the end of 2019, our system was enabled as a 439 transport option in 559,000 installations of Psiphon, and it served 440 upwards of 33,000 unique users per month. This paper reports on our 441 experience building the deployment and operating it for the first year. 442 We describe how we overcame engineering challenges, present detailed 443 performance metrics, and analyze how our system has responded to dynamic 444 censor behavior. Finally, we review lessons learned from operating this 445 unique artifact and discuss prospects for further scaling Refraction 446 Networking to meet the needs of censored users.</p> 447 </div> 448 </div> 449 450 <div class="citation"> 451 <div class="title"><a href="/pub/papers/slowdown-sigmetrics20.pdf">Characterizing Transnational Internet Performance and the Great Bottleneck of China</a></div> 452 <div class="author">Pengxiong Zhu, Keyu Man, Zhongjie Wang, Zhiyun Qian, Roya Ensafi, J. Alex Halderman, and Haixin Duan</div> 453 <div class="ref"><i>ACM SIGMETRICS 2020</i>, June 2020</div> 454 <div class="abstract"> 455 <p>Transnational Internet performance is an important indication of a 456 country’
456s level of infrastructure investment, globalization, and 457 openness. We conduct a large-scale measurement study of transnational 458 Internet performance in and out of 29 countries and regions, and find 459 six countries that have surprisingly low performance. Five of them are 460 African countries and the last is mainland China, a significant outlier 461 with major discrepancies between downstream and upstream performance. We 462 then conduct a comprehensive investigation of the unusual transnational 463 Internet performance of mainland China, which we refer to as the 464 “Great Bottleneck of China”. Our results show that this 465 bottleneck is widespread, affecting 79% of the receiver–sender 466 pairs we measured. More than 70% of the pairs suffer from extremely slow 467 speed (less than 1 Mbps) for more than 5 hours every day. In most tests 468 the bottleneck appeared to be located deep inside China, suggesting poor 469 network infrastructure to handle transnational traffic. The phenomenon 470 has far-reaching implications for Chinese users’ browsing habits 471 as well as for the ability of foreign Internet services to reach Chinese 472 customers.</p> 473 </div> 474 </div> 475 476 <div class="citation"> 477 <div class="title"><a href="/pub/papers/bmd-verifiability-sp20.pdf">Can Voters Detect Malicious Manipulation of Ballot Marking Devices?</a></div> 478 <div class="author">Matthew Bernhard, Allison McDonald, Henry Meng, Jensen Hwa, Nakul Bajaj, Kevin Chang, and J. Alex Halderman</div> 479 <div class="ref"><i>41st IEEE Symposium on Security and Privacy</i> (Oakland ’20), May 2020 — <b>Best Student Paper Award</b></div> 480 <div class="abstract"> 481 <p>Ballot marking devices (BMDs) allow voters to select candidates on a 482 computer kiosk, which prints a paper ballot that the voter can review 483 before inserting it into a scanner to be tabulated. Unlike paperless 484 voting machines, BMDs provide voters an opportunity to verify an 485 auditable physical record of their choices, and a growing number of U.S. 486 jurisdictions are adopting them for all voters. However, the security of 487 BMDs depends on how reliably voters notice and correct any adversarially 488 induced errors on their printed ballots. In order to measure 489 voters’ error detection abilities, we conducted a large study 490 (N=241) in a realistic polling place setting using real voting machines 491 that we modified to introduce an error into each printout. Without 492 intervention, only 40% of participants reviewed their printed ballots at 493 all, and only 6.6% told a poll worker something was wrong. We also find 494 that carefully designed interventions can improve verification 495 performance. Verbally instructing voters to review the printouts and 496 providing a written slate of candidates for whom to vote both 497 significantly increased review and reporting rates—although the 498 improvements may not be large enough to provide strong security in close 499 elections, especially when BMDs are used by all voters. Based on these 500 findings, we make several evidence-based recommendations to help better 501 defend BMD-based elections.</p> 502 </div> 503 </div> 504 505 <div class="citation"> 506 <div class="title"><a href="/pub/papers/letsencrypt-ccs19.pdf">Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web</a></div> 507 <div class="author">Josh Aas, Richard Barnes, Benton Case, Zakir Durumeric, Peter Eckersley, Alan Flores-López, J. Alex Halderman, Jacob Hoffman-Andrews, James Kasten, Eric Rescorla, Seth Schoen, and Brad Warren</div> 508 <div class="ref"><i>26th ACM Conference on Computer and Communications Security</i> (CCS ’19), November 2019</div> 509 <div class="abstract"> 510 <p>Let’s Encrypt is a free, open, and automated HTTPS certificate 511 authority (CA) created to advance HTTPS adoption to the entire Web. 512 Since its launch in late 2015, Let’s Encrypt has grown to become 513 the world’s largest HTTPS CA, accounting for more currently valid 514 certificates than all other browser-trusted CAs combined. By January 515 2019, it had issued over 538 million certificates for 223 million domain 516 names. We describe how we built Let’s Encrypt, including the 517 architecture of the CA software system (Boulder) and the structure of 518 the organization that operates it (ISRG), and we discuss lessons learned 519 from the experience. We also describe the design of ACME, the 520 IETF-standard protocol we created to automate CA-server interactions and 521 certificate issuance, and survey the diverse ecosystem of ACME clients, 522 including Certbot, a software agent we created to automate HTTPS 523 deployment. Finally, we measure Let’s Encrypt’s impact on 524 the Web and the CA ecosystem. We hope that the success of Let’s 525 Encrypt can provide a model for further enhancements to the Web PKI and
526 for future Internet security infrastructure.</p> 527 </div> 528 </div> 529 530 <div class="citation"> 531 <div class="title"><a href="/pub/papers/conjure-ccs19.pdf">Conjure: Summoning Proxies from Unused Address Space</a></div> 532 <div class="author">Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow</div> 533 <div class="ref"><i>26th ACM Conference on Computer and Communications Security </i> (CCS ’19), November 2019</div> 534 <div class="abstract"> 535 <p>Refraction Networking (formerly known as “Decoy Routing”) 536 has emerged as a promising next-generation approach for circumventing 537 Internet censorship. Rather than trying to hide individual circumvention 538 proxy servers from censors, proxy functionality is implemented in the 539 core of the network, at cooperating ISPs in friendly countries. Any 540 connection that traverses these ISPs could be a conduit for the free 541 flow of information, so censors cannot easily block access without also 542 blocking many legitimate sites. While one Refraction scheme, TapDance, 543 has recently been deployed at ISP-scale, it suffers from several 544 problems: a limited number of “decoy” sites in realistic 545 deployments, high technical complexity, and undesirable tradeoffs 546 between performance and observability by the censor. These challenges 547 may impede broader deployment and ultimately allow censors to block such 548 techniques.</p> 549 <p>We present Conjure, an improved Refraction Networking approach that 550 overcomes these limitations by leveraging unused address space at 551 deploying ISPs. Instead of using real websites as the decoy destinations 552 for proxy connections, our scheme connects to IP addresses where no web 553 server exists leveraging proxy functionality from the core of the 554 network. These phantom hosts are difficult for a censor to distinguish 555 from real ones, but can be used by clients as proxies. We define the 556 Conjure protocol, analyze its security, and evaluate a prototype using 557 an ISP testbed. Our results suggest that Conjure can be harder to block 558 than TapDance, is simpler to maintain and deploy, and offers 559 substantially better network performance.</p> 560 </div> 561 </div> 562 563 <div class="citation"> 564 <div class="title"><a href="/pub/papers/unclear-evoteid19.pdf">UnclearBallot: Automated Ballot Image Manipulation</a></div> 565 <div class="author">Matthew Bernhard, Kartikeya Kandula, Jeremy Wink, and J. Alex Halderman</div> 566 <div class="ref"><i>4th International Joint Conference on Electronic Voting</i> (E-Vote-ID ’19), October 2019</div> 567 <div class="abstract"> 568 <p>As paper ballots and post-election audits gain increased adoption in 569 the United States, election technology vendors are offering products 570 that allow jurisdictions to review ballot images—digital scans 571 produced by optical-scan voting machines—in their post-election 572 audit procedures. Jurisdictions including the state of Maryland rely on 573 such image audits as an alternative to inspecting the physical paper 574 ballots. We show that image audits can be reliably defeated by an 575 attacker who can run malicious code on the voting machines or election 576 management system. Using computer vision techniques, we develop an 577 algorithm that automatically and seamlessly manipulates ballot images, 578 moving voters’ marks so that they appear to be votes for the 579 attacker’s preferred candidate. Our implementation is compatible 580 with many widely used ballot styles, and we show that it is effective 581 using a large corpus of ballot images from a real election. We also show 582 that the attack can be delivered in the form of a malicious Windows 583 scanner driver, which we test with a scanner that has been certified for 584 use in vote tabulation by the U.S. Election Assistance Commission. These 585 results demonstrate that post-election audits must inspect physical 586 ballots, not merely ballot images, if they are to strongly defend 587 against computer-based attacks on widely used voting systems.</p> 588 </div> 589 </div> 590 591 <div class="citation"> 592 <div class="title"><a href="/pub/papers/https-chi19.pdf">On the Usability of HTTPS Deployment</a></div> 593 <div class="author">Matthew Bernhard, Jonathan Sharman, Claudia Z. Acemyan, Philip Kortum, Dan S. Wallach, and J. Alex Halderman</div> 594 <div class="ref"><i>ACM Conference on Human Factors in Computing Systems</i> (CHI ’19), May 2019</div> 595 <div class="abstract"> 596 <p>HTTPS and TLS are the backbone of Internet security, however setting 597 up web servers to run these protocols is a notoriously difficult 598 process. In this paper, we perform two live subjects usability studies 599 on the deployment of HTTPS in a real-world setting. Study 1 is a within 600 subjects comparison between traditional HTTPS configuration (purchasing 601 a certificate and installing it on a server) and Let’s Encrypt, 602 which automates much of the process. Study 2 is a between subjects study
603 looking at the same two systems, examining why users encounter usability 604 issues. Overall we confirm past results that HTTPS is difficult to 605 deploy, and we find some evidence that suggests Let’s Encrypt is 606 an easier, more efficient method for deploying HTTPS.</p> 607 </div> 608 </div> 609 610 <div class="citation"> 611 <div class="title"><a href="https://fc19.ifca.ai/voting/papers/OBHRS19.pdf">Bernoulli Ballot-Polling: A Manifest Improvement for Risk-Limiting Audits</a></div> 612 <div class="author">Kellie Ottoboni, Matthew Bernhard, J. Alex Halderman, Ronald L. Rivest, and Philip B Stark</div> 613 <div class="ref"><i>4th Workshop on Advances in Secure Electronic Voting</i> (Voting ’19), February 2019</div> 614 <div class="abstract"> 615 <p>We present a method and software for ballot-polling risk-limiting 616 audits (RLAs) based on Bernoulli sampling: ballots are included in the 617 sample with probability <i>p</i>, independently. Bernoulli sampling has 618 several advantages: (1) it does not require a ballot manifest; (2) it 619 can be conducted independently at different locations, rather than 620 requiring a central authority to select the sample from the whole 621 population of cast ballots or requiring stratified sampling; (3) it can 622 start in polling places on election night, before margins are known. If 623 the reported margins for the 2016 U.S. Presidential election are 624 correct, a Bernoulli ballot-polling audit with a risk limit of 5% and a 625 sampling rate of <i>p</i><sub>0</sub>=1% would have had at least a 99% 626 probability of confirming the outcome in 42 states. (The other states 627 were more likely to have needed to examine additional ballots.) 628 Logistical and security advantages that auditing in the polling place 629 affords may outweigh the cost of examining more ballots than some other 630 methods might require.</p> 631 </div> 632 </div> 633 634 <div class="citation"> 635 <div class="title"><a href="/pub/papers/geoblocking-imc18.pdf">403 Forbidden: A Global View of Geoblocking</a></div> 636 <div class="author">Allison McDonald, Matthew Bernhard, Benjamin VanderSloot, Will Scott, J. Alex Halderman, and Roya Ensafi</div> 637 <div class="ref"><i>18th ACM Internet Measurement Conference</i> (IMC ’18), October 2018</div> 638 <div class="abstract"> 639 <p>We report the first wide-scale measurement study of serverside 640 geographic restriction, or geoblocking, a phenomenon in which server 641 operators intentionally deny access to users from particular countries 642 or regions. Many sites practice geoblocking due to legal requirements or 643 other business reasons, but excessive blocking can needlessly deny 644 valuable content and services to entire national populations.</p> 645 <p>To help researchers and policymakers understand this phenomenon, we 646 develop a semi-automated system to detect instances where whole websites 647 were rendered inaccessible due to geoblocking. By focusing on detecting 648 geoblocking capabilities offered by large CDNs and cloud providers, we 649 can reliably distinguish the practice from dynamic anti-abuse mechanisms 650 and network-based censorship. We apply our techniques to test for 651 geoblocking across the Alexa Top 10K sites from thousands of vantage 652 points in 177 countries. We then expand our measurement to a sample of 653 CDN customers in the Alexa Top 1M.</p> 654 <p>We find that geoblocking occurs across a broad set of countries and 655 sites. We observe geoblocking in nearly all countries we study, with 656 Iran, Syria, Sudan, Cuba, and Russia experiencing the highest rates. 657 These countries experience particularly high rates of geoblocking for 658 finance and banking sites, likely as a result of U.S. economic 659 sanctions. We also verify our measurements with data provided by 660 Cloudflare, and find our observations to be accurate.</p> 661 </div> 662 </div> 663 664 <div class="citation"> 665 <div class="title"><a href="https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-vandersloot.pdf">Quack: Scalable Remote Measurement of Application-Layer Censorship</a></div> 666 <div class="author">Benjamin VanderSloot, Allison McDonald, Will Scott, J. Alex Halderman, and Roya Ensafi</div> 667 <div class="ref"><i>27th USENIX Security Symposium</i> (Sec ’18), August 2018</div> 668 <div class="abstract"> 669 <p>Remote censorship measurement tools can now detect DNS- and IP-based 670 blocking at global scale. However, a major <i>unmonitored</i> form of 671 interference is blocking triggered by deep packet inspection of 672 application-layer data. We close this gap by introducing Quack, a
673 scalable, remote measurement system that can efficiently detect 674 application-layer interference.</p> 675 <p>We show that Quack can effectively detect application-layer blocking 676 triggered on HTTP and TLS headers, and it is flexible enough to support 677 many other diverse protocols. In experiments, we test for blocking 678 across 4458 autonomous systems, an order of magnitude larger than 679 provided by country probes used by OONI. We also test a corpus of 680 100,000 keywords from vantage points in 40 countries to produce detailed 681 national blocklists. Finally, we analyze the keywords we find blocked to 682 provide insight into the application-layer blocking ecosystem and 683 compare countries’ behavior. We find that the most consistently 684 blocked services are related to circumvention tools, pornography, and 685 gambling, but that there is significant country-to-country 686 variation.</p> 687 </div> 688 </div> 689 690 <div class="citation"> 691 <div class="title"><a href="/pub/papers/misissuance-sp18.pdf">Tracking Certificate Misissuance in the Wild</a></div> 692 <div class="author">Deepak Kumar, Zhengping Wang, Matthew Hyder, Joseph Dickinson, Gabrielle Beck, David Adrian, Joshua Mason, Zakir Durumeric, J. Alex Halderman, and Michael Bailey</div> 693 <div class="ref"><i>39th IEEE Symposium on Security and Privacy</i> (Oakland ’18), May 2018</div> 694 <div class="abstract"> 695 <p>Certificate Authorities (CAs) regularly make mechanical errors when 696 issuing certificates. To quantify these errors, we introduce ZLint, a 697 certificate linter that codifies the policies set forth by the 698 CA/Browser Forum Baseline Requirements and RFC 5280 that can be tested 699 in isolation. We run ZLint on browser-trusted certificates in Censys and 700 systematically analyze how well CAs construct certificates. We find that 701 the number errors has drastically reduced since 2012. In 2017, only 702 0.02% of certificates have errors. However, this is largely due to a 703 handful of large authorities that consistently issue correct 704 certificates. There remains a long tail of small authorities that 705 regularly issue non-conformant certificates. We further find that 706 issuing certificates with errors is correlated with other types of 707 mismanagement and for large authorities, browser action. Drawing on our 708 analysis, we conclude with a discussion on how the community can best 709 use lint data to identify authorities with worrisome organizational 710 practices and ensure long-term health of the Web PKI.</p> 711 </div> 712 </div> 713 714 <div class="citation"> 715 <div class="title"><a href="/pub/papers/snet-imc17.pdf">Initial Measurements of the Cuban Street Network</a></div> 716 <div class="author">Eduardo Pujol, Will Scott, Eric Wustrow, and J. Alex Halderman</div> 717 <div class="ref"><i>17th ACM Internet Measurement Conference</i> (IMC ’17), November 2017</div> 718 <div class="abstract"> 719 <p>Internet access in Cuba is severely constrained, due to limited 720 availability, slow speeds, and high cost. Within this isolated 721 environment, technology enthusiasts have constructed a disconnected but 722 vibrant IP network that has grown organically to reach tens of thousands 723 of households across Havana. We present the first detailed 724 characterization of this deployment, which is known as the SNET, or 725 Street Network. Working in collaboration with SNET operators, we 726 describe the network’s infrastructure and map its topology, and we 727 measure bandwidth, available services, usage patterns, and user 728 demographics. Qualitatively, we attempt to answer <i>why</i> the SNET 729 exists and what benefits it has afforded its users. We go on to discuss 730 technical challenges the network faces, including scalability, security, 731 and organizational issues. To our knowledge, the SNET is the largest 732 isolated community-driven network in existence, and its structure, 733 successes, and obstacles show fascinating contrasts and similarities to 734 those of the Internet at large.</p> 735 </div> 736 </div> 737 738 <div class="citation"> 739 <div class="title"><a href="https://arxiv.org/abs/1707.08619">Public Evidence from Secret Ballots</a></div> 740 <div class="author">Matthew Bernhard, Josh Benaloh, J. Alex Halderman, Ronald L. Rivest, Peter Y. A. Ryan, Philip B. Stark, Vanessa Teague, Poorvi L. Vora, and Dan S. Wallach</div> 741 <div class="ref"><i>2nd International Joint Conference on Electronic Voting</i> (E-Vote-ID ’17), October 2017</div> 742 <div class="abstract"> 743 <p>Elections seem simple—<i>aren’t they just counting?</i> 744 But they have a unique, challenging combination of security and privacy 745 requirements. The stakes are high; the context is adversarial; the 746 electorate needs to be convinced that the results are correct; and the 747 secrecy of the ballot must be ensured. And they have practical
748 constraints: time is of the essence, and voting systems need to be 749 affordable and maintainable, and usable by voters, election officials, 750 and pollworkers. It is thus not surprising that voting is a rich 751 research area spanning theory, applied cryptography, practical systems 752 analysis, usable security, and statistics. Election integrity involves 753 two key concepts: <i>convincing evidence that outcomes are correct and 754 privacy</i>, which amounts to <i>convincing assurance that there is no 755 evidence</i> about how any given person voted. These are obviously in 756 tension. We examine how current systems walk this tightrope.</p> 757 </div> 758 </div> 759 760 <div class="citation"> 761 <div class="title"><a href="/pub/papers/mirai-sec17.pdf">Understanding the Mirai Botnet</a></div> 762 <div class="author">Manos Antonakakis, Tim April, Michael Bailey, Matt Bernhard, Elie Bursztein, Jaime Cochran, Zakir Durumeric, J. Alex Halderman, Luca Invernizzi, Michalis Kallitsis, Deepak Kumar, Chaz Lever, Zane Ma, Joshua Mason, Damian Menscher, Chad Seaman, Nick Sullivan, Kurt Thomas, and Yi Zhou</div> 763 <div class="ref"><i>26th USENIX Security Symposium</i> (Sec ’17), August 2017</div> 764 <div class="abstract"> 765 <p>The Mirai botnet, composed primarily of embedded and IoT devices, 766 took the Internet by storm in late 2016 when it overwhelmed several 767 high-profile targets with massive distributed denial-of-service (DDoS) 768 attacks. In this paper, we provide a seven-month retrospective analysis 769 of Mirai’s growth to a peak of 600k infections and a history of 770 its DDoS victims. By combining a variety of measurement perspectives, we 771 analyze how the botnet emerged, what classes of devices were affected, 772 and how Mirai variants evolved and competed for vulnerable hosts. Our 773 measurements serve as a lens into the fragile ecosystem of IoT devices. 774 We argue that Mirai may represent a sea change in the evolutionary 775 development of botnets—the simplicity through which devices were 776 infected and its precipitous growth, demonstrate that novice malicious 777 techniques can compromise enough low-end devices to threaten even some 778 of the best-defended targets. To address this risk, we recommend 779 technical and nontechnical interventions, as well as propose future 780 research directions.</p> 781 </div> 782 </div> 783 784 <div class="citation"> 785 <div class="title"><a href="/pub/papers/deployment-foci17.pdf">An ISP-Scale Deployment of TapDance</a></div> 786 <div class="author">Sergey Frolov, Fred Douglas, Will Scott, Allison McDonald, Benjamin VanderSloot, Rod Hynes, Adam Kruger, Michalis Kallitsis, David Robinson, Nikita Borisov, J. Alex Halderman, and Eric Wustrow</div> 787 <div class="ref"><i>7th USENIX Workshop on Free and Open Communications on the Internet</i> (FOCI ’17), August 2017</div> 788 <div class="abstract"> 789 <p>We report initial results from the world’s first ISP-scale 790 field trial of a refraction networking system. Refraction networking is 791 a next-generation censorship circumvention approach that locates proxy 792 functionality in the middle of the network, at participating ISPs or 793 other network operators. We built a high-performance implementation of 794 the TapDance refraction networking scheme and deployed it on four ISP 795 uplinks with an aggregate bandwidth of 100 Gbps. Over one week of 796 operation, our deployment served more than 50,000 real users. The 797 experience demonstrates that TapDance can be practically realized at ISP 798 scale with good performance and at a reasonable cost, potentially paving 799 the way for long-term, large-scale deployments of TapDance or other 800 refraction networking schemes in the future.</p> 801 </div> 802 </div> 803 804 <div class="citation"> 805 <div class="title"><a href="/pub/papers/tangled-www17.pdf">Security Challenges in an Increasingly Tangled Web</a></div> 806 <div class="author">Deepak Kumar, Zane Ma, Zakir Durumeric, Ariana Mirian, Joshua Mason, J. Alex Halderman, and Michael Bailey</div> 807 <div class="ref"><i>26th World Wide Web Conference</i> (WWW ’17), April 2017</div> 808 <div class="abstract"> 809 <p>Over the past 20 years, websites have grown increasingly complex and 810 interconnected. In 2016, only a negligible number of sites are 811 dependency free, and over 90% of sites rely on external
811content. In this 812 paper, we investigate the current state of web dependencies and explore 813 two security challenges associated with the increasing reliance on 814 external services: (1) the expanded attack surface associated with 815 serving unknown, implicitly trusted third-party content, and (2) how the 816 increased set of external dependencies impacts HTTPS adoption. We hope 817 that by shedding light on these issues, we can encourage developers to 818 consider the security risks associated with serving third-party content 819 and prompt service providers to more widely deploy HTTPS.</p> 820 </div> 821 </div> 822 823 <div class="citation"> 824 <div class="title"><a href="/pub/papers/interception-ndss17.pdf">The Security Impact of HTTPS Interception</a></div> 825 <div class="author">Zakir Durumeric, Zane Ma, Drew Springall, Richard Barnes, Nick Sullivan, Elie Bursztein, Michael Bailey, J. Alex Halderman, and Vern Paxson</div> 826 <div class="ref"><i>24th Network and Distributed Systems Symposium</i> (NDSS ’17), February 2017</div> 827 <div class="abstract"> 828 <p>As HTTPS deployment grows, middlebox and antivirus products are 829 increasingly intercepting TLS connections to retain visibility into 830 network traffic. In this work, we present a comprehensive study on the 831 prevalence and impact of HTTPS interception. First, we show that web 832 servers can detect interception by identifying a mismatch between the 833 HTTP User-Agent header and TLS client behavior. We characterize the TLS 834 handshakes of major browsers and popular interception products, which we 835 use to build a set of heuristics to detect interception and identify the 836 responsible product. We deploy these heuristics at three large network 837 providers: (1) Mozilla Firefox update servers, (2) a set of popular 838 e-commerce sites, and (3) the Cloudflare content distribution network. 839 We find more than an order of magnitude more interception than 840 previously estimated and with dramatic impact on connection security. To 841 understand why security suffers, we investigate popular middleboxes and 842 client- side security software, finding that nearly all reduce 843 connection security and many introduce severe vulnerabilities. Drawing 844 on our measurements, we conclude with a discussion on recent proposals 845 to safely monitor HTTPS and recommendations for the security 846 community.</p> 847 </div> 848 </div> 849 850 <div class="citation"> 851 <div class="title"><a href="/pub/papers/subgroup-ndss16.pdf">Measuring Small Subgroup Attacks Against Diffie-Hellman</a> <span class="altlink">(<a href="https://eprint.iacr.org/2016/995">ePrint</a>)</span></div> 852 <div class="author">Luke Valenta, David Adrian, Antonio Sanso, Shaanan Cohney, Joshua Fried, Marcella Hastings, J. Alex Halderman, and Nadia Heninger</div> 853 <div class="ref"><i>24th Network and Distributed Systems Symposium</i> (NDSS ’17), February 2017</div> 854 <div class="abstract"> 855 <p>Several recent standards, including NIST SP 800-56A and RFC 5114, 856 advocate the use of “DSA” parameters for Diffie-Hellman key 857 exchange. While it is possible to use such parameters securely, 858 additional validation checks are necessary to prevent well known and 859 potentially devastating attacks. In this paper, we observe that many 860 Diffie-Hellman implementations do not properly validate key exchange 861 inputs. Combined with other protocol properties and implementation 862 choices, this can radically decrease security. We measure the prevalence 863 of these parameter choices in the wild for HTTPS, POP3S, SMTP with 864 STARTTLS, SSH, IKEv1, and IKEv2, finding millions of hosts using DSA and 865 other non-“safe” primes for Diffie-Hellman key exchange, 866 many of them in combination with potentially vulnerable behaviors. We 867 examine over 20 open-source cryptographic libraries and applications and 868 observe that until January 2016, not a single one validated subgroup 869 orders by default. We found feasible full or partial key recovery 870 vulnerabilities in OpenSSL, the Exim mail server, the Unbound DNS 871 client, and Amazon’s load balancer, as well as susceptibility to 872 weaker attacks in many other applications.</p> 873 </div> 874 </div> 875 876 <div class="citation"> 877 <div class="title"><a href="/pub/papers/ics-pst16.pdf">An Internet-Wide View of ICS Devices</a></div> 878 <div class="author">Ariana Mirian, Zane Ma, David Adrian, Matthew Tischer, Thasphon Chuenchujit, Tim Yardley, Robin Berthier, Josh Mason, Zakir Durumeric, J. Alex Halderman, and Michael Bailey</div> 879 <div class="ref"><i>14th IEEE Conference on Privacy, Security, and Trust</i> (PST ’16), December 2016</div> 880 <div class="abstract"> 881 <p>
881Industrial control systems have become ubiquitous, enabling the 882 remote, electronic control of physical equipment and sensors. Originally 883 designed to operate on closed networks, the protocols used by these 884 devices have no built-in security. However, despite this, an alarming 885 number of systems are connected to the public Internet and an attacker 886 who finds a device often can cause catastrophic damage to physical 887 infrastructure. We consider two aspects of ICS security in this work: 888 (1) what devices have been inadvertently exposed on the public Internet, 889 and (2) who is searching for vulnerable systems. First, we implement 890 five common SCADA protocols in ZMap and conduct a survey of the public 891 IPv4 address space finding more than 60K publicly accessible systems. 892 Second, we use a large network telescope and high-interaction honeypots 893 to find and profile actors searching for devices. We hope that our 894 findings can both motivate and inform future work on securing industrial 895 control systems.</p> 896 </div> 897 </div> 898 899 <div class="citation"> 900 <div class="title"><a href="/pub/papers/kiosk-pst16.pdf">Implementing Attestable Kiosks</a></div> 901 <div class="author">Matthew Bernhard, J. Alex Halderman, and Gabe Stocco</div> 902 <div class="ref"><i>14th IEEE Conference on Privacy, Security, and Trust</i> (PST ’16), December 2016</div> 903 <div class="abstract"> 904 <p>In this paper we explore the notion of a secure kiosk, a trusted 905 computing platform built using off-the-shelf components. We demonstrate 906 how kiosks serve as convenient primitives when designing secure 907 computing protocols, as they allow for a very prescribed set of 908 assumptions to be made about a system. We begin by defining the 909 necessary properties of a kiosk, and then explain how each of these 910 properties can (or cannot) be attained using current off-the-shelf 911 hardware and software components. We construct a proof-of-concept 912 implementation using TPM hardware and Windows 10. We also provide 913 ASKVote, the Attestable and Secure Voting protocol to demonstrate the 914 flexibility gained from the use of kiosks in a larger secure system.</p> 915 </div> 916 </div> 917 918 <div class="citation"> 919 <div class="title"><a href="/pub/papers/police-pst16.pdf">A Security Analysis of Police Computer Systems</a></div> 920 <div class="author">Benjamin VanderSloot, Stuart Wheaton, and J. Alex Halderman</div> 921 <div class="ref"><i>14th IEEE Conference on Privacy, Security, and Trust</i> (PST ’16), December 2016</div> 922 <div class="abstract"> 923 <p></p> 924 </div> 925 </div> 926 927 <div class="citation"> 928 <div class="title"><a href="/pub/papers/forward-secrecy-imc16.pdf">Measuring the Security Harm of TLS Crypto Shortcuts</a></div> 929 <div class="author">Drew Springall, Zakir Durumeric, and J. Alex Halderman</div> 930 <div class="ref"><i>16th ACM Internet Measurement Conference</i> (IMC ’16), November 2016</div> 931 <div class="abstract"> 932 <p>TLS has the potential to provide strong protection against 933 network-based attackers and mass surveillance, but many implementations 934 take security shortcuts in order to reduce the costs of cryptographic 935 computations and network round trips. We report the results of a 936 nine-week study that measures the use and security impact of these 937 shortcuts for HTTPS sites among Alexa Top Million domains. We find 938 widespread deployment of DHE and ECDHE private value reuse, TLS session 939 resumption, and TLS session tickets. These practices greatly reduce the 940 protection afforded by forward secrecy: connections to 38% of Top 941 Million HTTPS sites are vulnerable to decryption if the server is 942 compromised up to 24 hours later, and 10% up to 30 days later, 943 regardless of the selected cipher suite. We also investigate the 944 practice of TLS secrets and session state being shared across domains, 945 finding that in some cases, the theft of a single secret value can 946 compromise connections to tens of thousands of sites. These results 947 suggest that site operators need to better understand the tradeoffs 948 between optimizing TLS performance and providing strong security,
949 particularly when faced with nation-state attackers with a history of 950 aggressive, large-scale surveillance.</p> 951 </div> 952 </div> 953 954 <div class="citation"> 955 <div class="title"><a href="/pub/papers/https-perspectives-imc16.pdf">Towards a Complete View of the Certificate Ecosystem</a></div> 956 <div class="author">Benjamin VanderSloot, Johanna Amann, Matthew Bernhard, Zakir Durumeric, Michael Bailey, and J. Alex Halderman</div> 957 <div class="ref"><i>16th ACM Internet Measurement Conference</i> (IMC ’16), November 2016</div> 958 <div class="abstract"> 959 <p>The HTTPS certificate ecosystem has been of great interest to the 960 measurement and security communities. Without any ground truth, 961 researchers have attempted to study this PKI from a variety of 962 fragmented perspectives, including passively monitored networks, scans 963 of the popular domains or the IPv4 address space, search engines such as 964 Censys, and Certificate Transparency (CT) logs. In this work, we 965 comparatively analyze all these perspectives. We find that aggregated CT 966 logs and Censys snapshots have many properties that complement each 967 other, and that together they encompass over 99% of all certificates 968 found by any of these techniques. However, they still miss 1.5% of 969 certificates observed in a crawl of all domains in <span 970 class="tt">.com</span>, <span class="tt">.net</span>, and <span 971 class="tt">.org</span>. We go on to illustrate how this combined 972 perspective affects results from previous studies. In light of these 973 findings, we have worked with the operators of Censys to incorporate CT 974 log data into its results going forward, and we recommend that future 975 HTTPS measurement adopt this new vantage.</p> 976 </div> 977 </div> 978 979 <div class="citation"> 980 <div class="title"><a href="/pub/papers/cbsec-nspw16.pdf">Content-Based Security for the Web</a></div> 981 <div class="author">Alexander Afanasyev, J. Alex Halderman, Scott Ruoti, Kent Seamons, Yingdi Yu, Daniel Zappala, and Lixia Zhang</div> 982 <div class="ref"><i>2016 New Security Paradigms Workshop</i> (NSPW ’16), September 2016</div> 983 <div class="abstract"> 984 <p>The World Wide Web has become the most common platform for building 985 applications and delivering content. Yet despite years of research, the 986 web continues to face severe security challenges related to data 987 integrity and confidentiality. Rather than continuing the 988 exploit-and-patch cycle, we propose addressing these challenges at an 989 architectural level, by supplementing the web’s existing 990 connection-based and server-based security models with a new approach: 991 content-based security. With this approach, content is directly signed 992 and encrypted at rest, enabling it to be delivered via any path and then 993 validated by the browser. We explore how this new architectural approach 994 can be applied to the web and analyze its security benefits. We then 995 discuss a broad research agenda to realize this vision and the 996 challenges that must be overcome.</p> 997 </div> 998 </div> 999 1000 <div class="citation"> 1001 <div class="title"><a href="https://drownattack.com/drown-attack-paper.pdf">DROWN: Breaking TLS using SSLv2</a> <span class="altlink">(<a href="https://drownattack.com/">website and test tool</a>)</span></div> 1002 <div class="author">Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky, Nadia Heninger, Maik Dankel, Jens Steube, Luke Valenta, David Adrian, J. Alex Halderman, Viktor Dukhovni, Emilia Käsper, Shaanan Cohney, Susanne Engels, Christof Paar, and Yuval Shavitt</div> 1003 <div class="ref"><i>25th USENIX Security Symposium</i> (Sec ’16), Austin, TX, August 2016 — <b><a href="https://pwnies.com/">Pwnie Award </a></b> — <b>Internet Defense Prize Finalist</b></div> 1004 <div class="abstract"> 1005 <p>We present DROWN, a novel cross-protocol attack on TLS that uses a 1006 server supporting SSLv2 as an oracle to decrypt modern TLS 1007 connections.</p> 1008 <p>We introduce two versions of the attack. The more general form 1009 exploits multiple unnoticed protocol flaws in SSLv2 to develop a new and 1010 stronger variant of the Bleichenbacher RSA padding-oracle attack. To 1011 decrypt a 2048-bit RSA TLS ciphertext, an attacker must observe 1,000 1012 TLS handshakes, initiate 40,000 SSLv2 connections, and perform 1013 2<sup>50</sup> offline work. The victim client never initiates SSLv2 1014 connections. We implemented the attack and can decrypt a TLS 1.2 1015 handshake using 2048-bit RSA in under 8 hours, at a cost of $440 on 1016 Amazon EC2. Using Internet-wide scans, we find that 33% of all HTTPS 1017 servers and 22% of those with browser-trusted certificates are 1018 vulnerable to this protocol-level attack due to widespread key and 1019 certificate reuse.</p> 1020 <p>For an even cheaper attack, we apply our new techniques together with 1021 a newly discovered vulnerability in OpenSSL that was present in releases 1022 from 1998 to early 2015. Given an unpatched SSLv2 server to use as an 1023 oracle, we can decrypt a TLS ciphertext in one minute on a single 1024 CPU—fast enough to enable man-in-the-middle attacks against modern 1025 browsers. We find that 26% of HTTPS servers are vulnerable to this 1026 attack.</p> 1027 <p>We further observe that the QUIC protocol is vulnerable to a variant 1028 of our attack that allows an attacker to impersonate a server 1029 indefinitely after performing as few as 2<sup>17</sup> SSLv2 connections 1030 and 2<sup>58</sup> offline work.</p> 1031 <p>We conclude that SSLv2 is not only weak, but actively harmful to the 1032 TLS ecosystem.</p> 1033 </div> 1034 </div> 1035 1036 <div class="citation"> 1037 <div class="title"><a href="/pub/papers/ftp-dsn16.pdf">FTP: The Forgotten Cloud</a></div> 1038 <div class="author">Drew Springall, Zakir Durumeric, and J. Alex Halderman</div> 1039 <div class="ref"><i>46th IEEE/IFIP International Conference on Dependable Systems and Networks</i> (DSN ’16), Toulouse, June 2016</div> 1040 <div class="abstract"> 1041 <p>Once pervasive, the File Transfer Protocol (FTP) has been largely 1042 supplanted by HTTP, SCP, and BitTorrent for transferring data between 1043 hosts. Yet, in a comprehensive analysis of the FTP ecosystem as of 2015, 1044 we find that there are still more than 13 million FTP servers in the 1045 IPv4 address space, 1.1 million of which allow “anonymous” 1046 (public) access. These anonymous FTP servers leak sensitive information, 1047 such as tax documents and cryptographic secrets. More than 20,000 FTP 1048 servers allow public write access, which has facilitated malicious 1049 actors’ use of free storage as well as malware deployment and 1050 click-fraud attacks. We further investigate real-world attacks by 1051 deploying eight FTP honeypots, shedding light on how attackers are 1052 abusing and exploiting vulnerable servers. We conclude with lessons and 1053 recommendations for securing FTP.</p> 1054 </div> 1055 </div> 1056 1057 <div class="citation"> 1058 <div class="title"><a href="/pub/papers/deception-fc16.pdf">Android UI Deception Revisited: Attacks and Defenses</a></div> 1059 <div class="author">Earlence Fernandes, Qi Alfred Chen, Justin Paupore, Georg Essl, J. Alex Halderman, Z. Morley Mao, and Atul Prakash</div> 1060 <div class="ref"><i>20th International Conference on Financial Cryptography and Data Security</i> (FC ’16), Barbados, February 2016</div> 1061 <div class="abstract"> 1062 <p>App-based deception attacks are increasingly a problem on mobile 1063 devices and they are used to steal passwords, credit card numbers, text 1064 messages, etc. Current versions of Android are susceptible to these 1065 attacks. Recently, Bianchi et al. proposed a novel solution (“What 1066 the App is That”) that included a host-based system to identify 1067 apps to users via a security indicator and help assure them that their 1068 input goes to the identified apps. Unfortunately, we found that the 1069 solution has a significant side channel vulnerability as well as 1070 susceptibility to clickjacking that allow non-privileged malware to 1071 completely compromise the defenses, and successfully steal passwords or 1072 other keyboard input. We discuss the vulnerabilities found, propose 1073 possible defenses, and then evaluate the defenses against different 1074 types of UI deception attacks.</p> 1075 </div> 1076 </div> 1077 1078 <div class="citation"> 1079 <div class="title"><a href="https://weakdh.org/imperfect-forward-secrecy.pdf">Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice</a> <span class="altlink">(<a href="https://weakdh.org/">website</a>)</span></div> 1080 <div class="author">David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, and Paul Zimmermann</div> 1081 <div class="ref"><i>22nd ACM Conference on Computer and Communications Security</i> (CCS ’15), Denver, CO, October 2015 — <b>Best Paper Award</b> — <b>
1081<a href="https://pwnies.com/">Pwnie Award </a></b></div> 1082 <div class="ref">Reprinted in <i><a href="/pub/papers/weakdh-cacm19.pdf">Communications of the ACM</a></i>, <!--52(5):91-98,--> January 2019</div> 1083 <div class="abstract"> 1084 <p>We investigate the security of Diffie-Hellman key exchange as used in 1085 popular Internet protocols and find it to be less secure than widely 1086 believed. First, we present Logjam, a novel flaw in TLS that lets a 1087 man-in-the-middle downgrade connections to “export-grade” 1088 Diffie-Hellman. To carry out this attack, we implement the number field 1089 sieve discrete log algorithm. After a week-long precomputation for a 1090 specified 512-bit group, we can compute arbitrary discrete logs in that 1091 group in about a minute. We find that 82% of vulnerable servers use a 1092 single 512-bit group, allowing us to compromise connections to 7% of 1093 Alexa Top Million HTTPS sites. In response, major browsers are being 1094 changed to reject short groups.</p> 1095 <p>We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We 1096 estimate that even in the 1024-bit case, the computations are plausible 1097 given nation-state resources. A small number of fixed or standardized 1098 groups are used by millions of servers; performing precomputation for a 1099 single 1024-bit group would allow passive eavesdropping on 18% of 1100 popular HTTPS sites, and a second group would allow decryption of 1101 traffic to 66% of IPsec VPNs and 26% of SSH servers. A close reading of 1102 published NSA leaks shows that the agency’s attacks on VPNs are 1103 consistent with having achieved such a break. We conclude that moving to 1104 stronger key exchange methods should be a priority for the Internet 1105 community.</p> 1106 </div> 1107 </div> 1108 1109 <div class="citation"> 1110 <div class="title"><a href="/pub/papers/censys-ccs15.pdf">Censys: A Search Engine Backed by Internet-Wide Scanning</a> <span class="altlink">(<a href="https://censys.io">website</a>)</span></div> 1111 <div class="author">Zakir Durumeric, David Adrian, Ariana Mirian, Michael Bailey, and J. Alex Halderman</div> 1112 <div class="ref"><i>22nd ACM Conference on Computer and Communications Security</i> (CCS ’15), Denver, CO, October 2015</div> 1113 <div class="abstract"> 1114 <p>Fast Internet-wide scanning has opened new avenues for security 1115 research, ranging from uncovering widespread vulnerabilities in random 1116 number generators to tracking the evolving impact of Heartbleed. 1117 However, this technique still requires significant effort: even simple 1118 questions, such as, “What models of embedded devices prefer CBC 1119 ciphers?”, require developing an application scanner, manually 1120 identifying and tagging devices, negotiating with network 1121 administrators, and responding to abuse complaints. In this paper, we 1122 introduce Censys, a public search engine and data processing facility 1123 backed by data collected from ongoing Internet-wide scans. Designed to 1124 help researchers answer security-related questions, Censys supports 1125 full-text searches on protocol banners and querying a wide range of 1126 derived fields (e.g., <span style="font-family:monospace; font-size:80%;">443.https.cipher</span>). It can identify specific 1127 vulnerable devices and networks and generate statistical reports on 1128 broad usage patterns and trends. Censys returns these results in 1129 sub-second time, dramatically reducing the effort of understanding the 1130 hosts that comprise the Internet. We present the search engine 1131 architecture and experimentally evaluate its performance. We also 1132 explore Censys’s applications and show how questions asked in 1133 recent studies become simple to answer.</p> 1134 </div> 1135 </div> 1136 1137 <div class="citation"> 1138 <div class="title"><a href="/pub/papers/mail-imc15.pdf">Neither Snow Nor Rain Nor MITM… An Empirical Analysis of Email Delivery Security</a></div> 1139 <div class="author">Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, Elie Bursztein, Nicholas Lidzborski, Kurt Thomas, Vijay Eranti, Michael Bailey, and J. Alex Halderman</div> 1140 <div class="ref"><i>15th ACM Internet Measurement Conference</i> (IMC ’15), Tokyo, Japan, October 2015 — <b><a href="https://irtf.org/anrp">IRTF Applied Networking Research Prize</a> Winner</b></div> 1141 <div class="abstract"> 1142 <p>The SMTP protocol is responsible for carrying some of users’ 1143 most intimate communication, but like other Internet protocols, 1144 authentication and confidentiality were added only as an afterthought. 1145 In this work, we present the first report on global adoption rates of 1146 SMTP security extensions, including StartTLS, SPF, DKIM, and DMARC. We 1147 present data from two perspectives: SMTP server configurations for the 1148 Alexa Top Million domains, and over a year of SMTP connections to and 1149 from Gmail. We find that the top mail providers (e.g., Gmail, Yahoo, 1150 Outlook) all proactively encrypt and authenticate messages. However, 1151 these best practices have yet to reach widespread adoption in a long 1152 tail of over 700,000 SMTP servers, of which only 35% successfully 1153 configure encryption and 1.1% specify a DMARC authentication policy. 1154 This security patchwork—paired with SMTP policies that favor 1155 failing open to allow gradual deployment—
1155exposes users to 1156 attackers who downgrade TLS connections in favor of cleartext and who 1157 falsify MX records to reroute messages. We present evidence of such 1158 attacks in the wild, highlighting seven countries where more than 20% of 1159 inbound Gmail messages arrive in cleartext due to network attackers.</p> 1160 </div> 1161 </div> 1162 1163 <div class="citation"> 1164 <div class="title"><a href="https://arxiv.org/pdf/1504.05646v2.pdf">The New South Wales iVote System: Security Failures and Verification Flaws in a Live Online Election</a> <span class="altlink">(<a href="https://freedom-to-tinker.com/blog/teaguehalderman/ivote-vulnerability/">blog post</a>)</span></div> 1165 <div class="author">J. Alex Halderman and Vanessa Teague</div> 1166 <div class="ref"><i>5th International Conference on E-voting and Identity</i> (VoteID ’15), Bern, Switzerland, September 2015</div> 1167 <div class="abstract"> 1168 <p>In the world’s largest-ever deployment of online voting, the 1169 iVote Internet voting system was trusted for the return of 280,000 1170 ballots in the 2015 state election in New South Wales, Australia. During 1171 the election, we performed an independent security analysis of parts of 1172 the live iVote system and uncovered severe vulnerabilities that could be 1173 leveraged to manipulate votes, violate ballot privacy, and subvert the 1174 verification mechanism. These vulnerabilities do not seem to have been 1175 detected by the election authorities before we disclosed them, despite a 1176 pre-election security review and despite the system having run in a live 1177 state election for five days. One vulnerability, the result of including 1178 analytics software from an insecure external server, exposed some votes 1179 to complete compromise of privacy and integrity. At least one 1180 parliamentary seat was decided by a margin much smaller than the number 1181 of votes taken while the system was vulnerable. We also found protocol 1182 flaws, including vote verification that was itself susceptible to 1183 manipulation. This incident underscores the difficulty of conducting 1184 secure elections online and carries lessons for voters, election 1185 officials, and the e-voting research community.</p> 1186 </div> 1187 </div> 1188 1189 <div class="citation"> 1190 <div class="title"><a href="/pub/papers/umbra-woscps15.pdf">Umbra: Embedded Web Security through Application-Layer Firewalls</a></div> 1191 <div class="author">Travis Finkenauer and J. Alex Halderman</div> 1192 <div class="ref"><i>1st Workshop on the Security of Cyberphysical Systems</i> (WOS-CPS ’15), Vienna, Austria, September 2015</div> 1193 <div class="abstract"> 1194 <p>Embedded devices with web interfaces are prevalent, but, due to 1195 memory and processing constraints, implementations typically make use of 1196 Common Gateway Interface (CGI) binaries written in low-level, 1197 memory-unsafe languages. This creates the possibility of memory 1198 corruption attacks as well as traditional web attacks. We present Umbra, 1199 an application-layer firewall specifically designed for protecting web 1200 interfaces in embedded devices. By acting as a “friendly 1201 man-in-the-middle,” Umbra can protect against attacks such as 1202 cross-site request forgery (CSRF), information leaks, and authentication 1203 bypass vulnerabilities. We evaluate Umbra’s security by analyzing 1204 recent vulnerabilities listed in the CVE database from several embedded 1205 device vendors and find that it would have prevented half of these 1206 vulnerabilities. We also show that Umbra comfortably runs within the 1207 constraints of an embedded system while incurring minimal performance 1208 overhead.</p> 1209 </div> 1210 </div> 1211 1212 <div class="citation"> 1213 <div class="title"><a href="/pub/papers/replication-woot15.pdf">Replication Prohibited: Attacking Restricted Keyways with 3D Printing</a></div> 1214 <div class="author">Ben Burgess, Eric Wustrow, and J. Alex Halderman</div> 1215 <div class="ref"><i>9th USENIX Workshop on Offensive Technologies</i> (WOOT ’15), Washington, DC, August 2015</div> 1216 <div class="abstract"> 1217 <p>Several attacks against physical pin-tumbler locks require access to 1218 one or more key blanks to perform. These attacks include bumping, 1219 impressioning, rights amplification, and teleduplication. To mitigate 1220 these attacks, many lock systems rely on restricted keyways and use 1221 blanks that are not sold to the general public, making it harder for 1222 attackers to obtain them. Often the key blank designs themselves are 1223 patented, further discouraging distribution or manufacture by even 1224 skilled machinists. In this paper, we investigate the impact that 1225 emerging rapid-prototyping—or 3D-printing—tools have on the 1226 security of these restricted keyway systems. We find that commodity 3D 1227 printers are able to produce key blanks and pre-cut keys with enough 1228 resolution to work in several commonly used pin-tumbler locks and that 1229 their material is strong enough to withstand the requirements to perform 1230 the aforementioned attacks. In addition, in order to demonstrate the low 1231 skill requirements necessary to perform these attacks, we develop a tool 1232 that automatically generates a 3D-printable CAD model of a key blank 1233 using only a single picture of a lock’s keyway. This tool allows 1234 us to rapidly manufacture key blanks for restricted keyways that were 1235 previously difficult to make or buy. Finally, we discuss possible 1236 mitigations for these attacks that lock manufacturers, installer
1236s, and 1237 users can perform to protect their assets.</p> 1238 </div> 1239 </div> 1240 1241 <div class="citation"> 1242 <div class="title"><a href="/pub/papers/heartbleed-imc14.pdf">The Matter of Heartbleed</a></div> 1243 <div class="author">Zakir Durumeric, Frank Li, James Kasten, Johanna Amann, Jethro Beekman, Mathias Payer, Nicolas Weaver, David Adrian, Vern Paxson, Michael Bailey, and J. Alex Halderman</div> 1244 <div class="ref"><i>14th ACM Internet Measurement Conference</i> (IMC ’14), Vancouver, BC, November 2014 — <b>Best Paper Award</b></div> 1245 <div class="abstract"> 1246 <p>The Heartbleed vulnerability took the Internet by surprise in April 1247 2014. The vulnerability, one of the most consequential since the advent 1248 of the commercial Internet, allowed attackers to remotely read protected 1249 memory from an estimated 24–55% of popular HTTPS sites. In this 1250 work, we perform a comprehensive, measurement-based analysis of the 1251 vulnerability’s impact, including (1) tracking the vulnerable 1252 population, (2) monitoring patching behavior over time, (3) assessing 1253 the impact on the HTTPS certificate ecosystem, and (4) exposing real 1254 attacks that attempted to exploit the bug. Furthermore, we conduct a 1255 large-scale vulnerability notification experiment involving 150,000 1256 hosts and observe a nearly 50% increase in patching by notified hosts. 1257 Drawing upon these analyses, we discuss what went well and what went 1258 poorly, in an effort to understand how the technical community can 1259 respond more effectively to such events in the future.</p> 1260 </div> 1261 </div> 1262 1263 <div class="citation"> 1264 <div class="title"><a href="/pub/papers/ivoting-ccs14.pdf">Security Analysis of the Estonian Internet Voting System</a> <span class="altlink">(<a href="https://estoniaevoting.org">website and videos</a>)</span></div> 1265 <div class="author">Drew Springall, Travis Finkenauer, Zakir Durumeric, Jason Kitcat, Harri Hursti, Margaret MacAlpine, and J. Alex Halderman</div> 1266 <div class="ref"><i>21st ACM Conference on Computer and Communications Security</i> (CCS ’14), Scottsdale, AZ, November 2014</div> 1267 <div class="abstract"> 1268 <p>Estonia was the first country in the world to use Internet voting 1269 nationally, and today more than 30% of its ballots are cast online. In 1270 this paper, we analyze the security of the Estonian I-voting system 1271 based on a combination of in-person election observation, code review, 1272 and adversarial testing. Adopting a threat model that considers the 1273 advanced threats faced by a national election system—including 1274 dishonest insiders and state-sponsored attacks—we find that the 1275 I-voting system has serious architectural limitations and procedural 1276 gaps that potentially jeopardize the integrity of elections. In 1277 experimental attacks on a reproduction of the system, we demonstrate how 1278 such attackers could target the election servers or voters’ 1279 clients to alter election results or undermine the legitimacy of the 1280 system. Our findings illustrate the practical obstacles to Internet 1281 voting in the modern world, and they carry lessons for Estonia, for 1282 other countries considering adopting such systems, and for the security 1283 research community.</p> 1284 </div> 1285 </div> 1286 1287 <div class="citation"> 1288 <div class="title"><a href="/pub/papers/audit-evote14.pdf">Efficiently Auditing Multi-Level Elections</a></div> 1289 <div class="author">Joshua A. Kroll, Edward W. Felten, and J. Alex Halderman</div> 1290 <div class="ref"><i>6th International Conference on Electronic Voting</i> (EVOTE ’14), Lochau, Austria, October 2014</div> 1291 <div class="abstract"> 1292 <p>In a multi-level election, voters are divided into groups, an 1293 election is held within each group, and some deterministic procedure is 1294 used to combine the group results to determine the overall election 1295 result. Examples of multi-level elections include U.S. presidential 1296 elections and some parliamentary elections (such as those with regional 1297 groupings of voters). The results of such an election can hinge on a few 1298 votes in one group, while being insensitive to large shifts within other 1299 groups. These disparities create opportunities to focus election 1300 integrity efforts in the places where they have the highest leverage. We 1301 consider how to improve the efficiency of post-election audits, such as
1302 those that compare paper ballots to corresponding electronic records, in 1303 multi-level elections. We evaluate our proposed solutions using data 1304 from past elections.</p> 1305 </div> 1306 </div> 1307 1308 <div class="citation"> 1309 <div class="title"><a href="https://radsec.org/secure1000-sec14.pdf">Security Analysis of a Full-Body Scanner</a> <span class="altlink">(<a href="https://radsec.org">website</a>)</span></div> 1310 <div class="author">Keaton Mowery, Eric Wustrow, Tom Wypych, Corey Singleton, Chris Comfort, Eric Rescorla, Stephen Checkoway, J. Alex Halderman, and Hovav Shacham</div> 1311 <div class="ref"><i>23rd USENIX Security Symposium</i> (Sec ’14), San Diego, CA, August 2014</div> 1312 <div class="abstract"> 1313 <p>Advanced imaging technologies are a new class of people screening 1314 systems used at airports and other sensitive environments to detect 1315 metallic as well as nonmetallic contraband. We present the first 1316 independent security evaluation of such a system, the Rapiscan Secure 1317 1000 full-body scanner, which was widely deployed at airport checkpoints 1318 in the U.S. from 2009 until 2013. We find that the system provides weak 1319 protection against adaptive adversaries: It is possible to conceal 1320 knives, guns, and explosives from detection by exploiting properties of 1321 the device’s backscatter X-ray technology. We also investigate 1322 cyberphysical threats and propose novel attacks that use malicious 1323 software and hardware to compromise the the effectiveness, safety, and 1324 privacy of the device. Overall, our findings paint a mixed picture of 1325 the Secure 1000 that carries lessons for the design, evaluation, and 1326 operation of advanced imaging technologies, for the ongoing public 1327 debate concerning their use, and for cyberphysical security more 1328 broadly.</p> 1329 </div> 1330 </div> 1331 1332 <div class="citation"> 1333 <div class="title"><a href="/pub/papers/tapdance-sec14.pdf">TapDance: End-to-Middle Anticensorship without Flow Blocking</a></div> 1334 <div class="author">Eric Wustrow, Colleen M. Swanson, and J. Alex Halderman</div> 1335 <div class="ref"><i>23rd USENIX Security Symposium</i> (Sec ’14), San Diego, CA, August 2014</div> 1336 <div class="abstract"> 1337 <p>In response to increasingly sophisticated state-sponsored Internet 1338 censorship, recent work has proposed a new approach to censorship 1339 resistance: end-to-middle proxying. This concept, developed in systems 1340 such as Telex, Decoy Routing, and Cirripede, moves anticensorship 1341 technology into the core of the network, at large ISPs outside the 1342 censoring country. In this paper, we focus on two technical obstacles to 1343 the deployment of certain end-to-middle schemes: the need to selectively 1344 block flows and the need to observe both directions of a connection. We 1345 propose a new construction, TapDance, that removes these requirements. 1346 TapDance employs a novel TCP-level technique that allows the 1347 anticensorship station at an ISP to function as a passive network tap, 1348 without an inline blocking component. We also apply a novel 1349 steganographic encoding to embed control messages in TLS ciphertext, 1350 allowing us to operate on HTTPS connections even under asymmetric 1351 routing. We implement and evaluate a TapDance prototype that 1352 demonstrates how the system could function with minimal impact on an 1353 ISP’s network operations.</p> 1354 </div> 1355 </div> 1356 1357 <div class="citation"> 1358 <div class="title"><a href="/pub/papers/scanning-sec14.pdf">An Internet-Wide View of Internet-Wide Scanning</a></div> 1359 <div class="author">Zakir Durumeric, Michael Bailey, and J. Alex Halderman</div> 1360 <div class="ref"><i>23rd USENIX Security Symposium</i> (Sec ’14), San Diego, CA, August 2014</div> 1361 <div class="abstract"> 1362 <p>
1362While it is widely known that port scanning is widespread, neither 1363 the scanning landscape nor the defensive reactions of network operators 1364 have been measured at Internet scale. In this work, we analyze data from 1365 a large network telescope to study scanning activity from the past year, 1366 uncovering large horizontal scan operations and identifying broad 1367 patterns in scanning behavior. We present an analysis of who is 1368 scanning, what services are being targeted, and the impact of new 1369 scanners on the overall landscape. We also analyze the scanning behavior 1370 triggered by recent vulnerabilities in Linksys routers, OpenSSL, and 1371 NTP. We empirically analyze the defensive behaviors that organizations 1372 employ against scanning, shedding light on who detects scanning 1373 behavior, which networks blacklist scanning, and how scan recipients 1374 respond to scans conducted by researchers. We conclude with 1375 recommendations for institutions performing scans and with implications 1376 of recent changes in scanning behavior for researchers and network 1377 operators.</p> 1378 </div> 1379 </div> 1380 1381 <div class="citation"> 1382 <div class="title"><a href="/pub/papers/traffic-woot14.pdf">Green Lights Forever: Analyzing the Security of Traffic Infrastructure</a></div> 1383 <div class="author">William Beyer, Branden Ghena, Allen Hillaker, Jonathan Pevarnek, and J. Alex Halderman</div> 1384 <div class="ref"><i>8th USENIX Workshop on Offensive Technologies</i> (WOOT ’14), San Diego, CA, August 2014</div> 1385 <div class="abstract"> 1386 <p>The safety critical nature of traffic infrastructure requires that it 1387 be secure against computer-based attacks, but this is not always the 1388 case. We investigate a networked traffic signal system currently 1389 deployed in the United States and discover a number of security flaws 1390 that exist due to systemic failures by the designers. We leverage these 1391 flaws to create attacks which gain control of the system, and we 1392 successfully demonstrate them on the deployment in coordination with 1393 authorities. Our attacks show that an adversary can control traffic 1394 infrastructure to cause disruption, degrade safety, or gain an unfair 1395 advantage. We make recommendations on how to improve existing systems 1396 and discuss the lessons learned for embedded systems security in 1397 general.</p> 1398 </div> 1399 </div> 1400 1401 <div class="citation"> 1402 <div class="title"><a href="/pub/papers/zmap10gig-woot14.pdf">Zippier ZMap: Internet-Wide Scanning at 10Gbps</a></div> 1403 <div class="author">David Adrian, Zakir Durumeric, Gulshan Singh, and J. Alex Halderman</div> 1404 <div class="ref"><i>8th USENIX Workshop on Offensive Technologies</i> (WOOT ’14), San Diego, CA, August 2014</div> 1405 <div class="abstract"> 1406 <p>We introduce optimizations to the ZMap network scanner that achieve a 1407 10-fold increase in maximum scan rate. By parallelizing address 1408 generation, introducing an improved blacklisting algorithm, and using 1409 zero-copy NIC access, we drive ZMap to nearly the maximum throughput of 1410 10 gigabit Ethernet, almost 15 million probes per second. With these 1411 changes, ZMap can comprehensively scan for a single TCP port across the 1412 entire public IPv4 address space in 4.5 minutes given adequate upstream 1413 bandwidth. We consider the implications of such rapid scanning for both 1414 defenders and attackers, and we briefly discuss a range of potential 1415 applications.</p> 1416 </div> 1417 </div> 1418 1419 <div class="citation"> 1420 <div class="title"><a href="https://fc14.ifca.ai/papers/fc14_submission_158.pdf">Elliptic Curve Cryptography in Practice</a> <span class="altlink">(<a href="https://eprint.iacr.org/2013/734">ePrint</a>)</span></div> 1421 <div class="author">Joppe W. Bos, J. Alex Halderman, Nadia Heninger, Jonathan Moore, Michael Naehrig, and Eric Wustrow</div> 1422 <div class="ref"><i>18th International Conference on Financial Cryptography and Data Security</i> (FC ’14), March 2014</div> 1423 <div class="abstract"> 1424 <p>In this paper, we perform a review of elliptic curve cryptography 1425 (ECC), as it is used in practice today, in order to reveal unique 1426 mistakes and vulnerabilities that arise in implementations of ECC. We 1427 study four popular protocols that make use of this type of public-key
1428 cryptography: Bitcoin, secure shell (SSH), transport layer security 1429 (TLS), and the Austrian e-ID card. We are pleased to observe that about 1430 1 in 10 systems support ECC across the TLS and SSH protocols. However, 1431 we find that despite the high stakes of money, access and resources 1432 protected by ECC, implementations suffer from vulnerabilities similar to 1433 those that plague previous cryptographic systems.</p> 1434 </div> 1435 </div> 1436 1437 <div class="citation"> 1438 <div class="title"><a href="/pub/papers/smartwatch13.pdf">Outsmarting Proctors with Smartwatches: A Case Study on Wearable Computing Security</a> <span class="altlink">(<a href="https://freedom-to-tinker.com/blog/amigi/cheating-on-exams-with-smartwatches/">blog post</a>)</span></div> 1439 <div class="author">Alex Migicovsky, Zakir Durumeric, Jeff Ringenberg, and J. Alex Halderman</div> 1440 <div class="ref"><i>18th International Conference on Financial Cryptography and Data Security</i> (FC ’14), March 2014</div> 1441 <div class="abstract"> 1442 <p>Many companies have recently started to offer wearable computing 1443 devices including glasses, bracelets, and watches. While this technology 1444 enables exciting new applications, it also poses new security and 1445 privacy concerns. In this work, we explore these implications and 1446 analyze the impact of one of the first networked wearable 1447 devices—smartwatches—on an academic environment. As a proof 1448 of concept, we develop an application for the Pebble smartwatch called 1449 ConTest that would allow dishonest students to inconspicuously 1450 collaborate on multiple-choice exams in real time, using a cloud-based 1451 service, a smartphone, and a client application on the watch. We discuss 1452 the broader implications of this technology, suggest hardware and 1453 software approaches that can be used to prevent such attacks, and pose 1454 questions for future research.</p> 1455 </div> 1456 </div> 1457 1458 <div class="citation"> 1459 <div class="title"><a href="/pub/papers/https-imc13.pdf">Analysis of the HTTPS Certificate Ecosystem</a></div> 1460 <div class="author">Zakir Durumeric, James Kasten, Michael Bailey, and J. Alex Halderman</div> 1461 <div class="ref"><i>13th ACM Internet Measurement Conference</i> (IMC ’13), Barcelona, Spain, October 2013</div> 1462 <div class="abstract"> 1463 <p>We report the results of a large-scale measurement study of the HTTPS 1464 certificate ecosystem—the public-key infrastructure that underlies 1465 nearly all secure web communications. Using data collected by performing 1466 110 Internet-wide scans over 14 months, we gain detailed and temporally 1467 fine-grained visibility into this otherwise opaque area of 1468 security-critical infrastructure. We investigate the trust relationships 1469 among root authorities, intermediate authorities, and the leaf 1470 certificates used by web servers, ultimately identifying and classifying 1471 more than 1,800 entities that are able to issue certificates vouching 1472 for the identity of any website. We uncover practices that may put the 1473 security of the ecosystem at risk, and we identify frequent 1474 configuration problems that lead to user-facing errors and potential 1475 vulnerabilities. We conclude with lessons and recommendations to ensure 1476 the long-term health and security of the certificate ecosystem.</p> 1477 </div> 1478 </div> 1479 1480 <div class="citation"> 1481 <div class="title"><a href="/pub/papers/zmap-sec13.pdf">ZMap: Fast Internet-Wide Scanning and its Security Applications</a> <span class="altlink">(<a href="https://www.zmap.io">website and tool</a>)</span></div> 1482 <div class="author">Zakir Durumeric, Eric Wustrow, and J. Alex Halderman</div> 1483 <div class="ref"><i>22nd USENIX Security Symposium</i> (Sec ’13), Washington, DC, August 2013</div> 1484 <div class="abstract"> 1485 <p>Internet-wide network scanning has numerous security applications, 1486 including exposing new vulnerabilities and tracking the adoption of 1487 defensive mechanisms, but probing the entire public address space with 1488 existing tools is both difficult and slow. We introduce ZMap, a modular, 1489 open-source network scanner specifically architected to perform 1490 Internet-wide scans and capable of surveying the entire IPv4 address 1491 space in under 45 minutes from user space on a single machine, 1492 approaching the theoretical maximum speed of gigabit Ethernet. We 1493 present the scanner architecture, experimentally characterize its 1494 performance and accuracy, and explore the security implications of high 1495 speed Internet-scale network surveys, both offensive and defensive. We 1496 also discuss best practices for good Internet citizenship when 1497 performing Internet-wide surveys, informed by our own experiences 1498 conducting a long-term research survey over the past year.</p> 1499 </div> 1500 </div> 1501 1502 <div class="citation"> 1503 <div class="title"><a href="https://jhalderm.com/pub/papers/ipmi-woot13.pdf">Illuminating the Security Issues Surrounding Lights-Out Server Management</a></div> 1504 <div class="author">Anthony Bonkoski, Russ Bielawski, and J. Alex Halderman</div> 1505 <div class="ref"><i>7th USENIX Workshop on Offensive Technologies</i> (WOOT ’13), Washington, DC, August 2013</div> 1506 <div class="abstract"> 1507 <p>Out-of-band, lights-out management has become a standard feature on 1508 many servers, but while this technology can be a boon for system 1509 administrators, it also presents a new and interesting vector for 1510 attack. This paper examines the security implications of the Intelligent 1511 Platform Management Interface (IPMI), which is implemented on server 1512 motherboards using an embedded Baseboard Management Controller (BMC). We 1513 consider the threats posed by an incorrectly implemented IPMI and 1514 present evidence that IPMI vulnerabilities may be widespread. We analyze 1515 a major OEM’s IPMI implementation and discover that it is riddled 1516 with textbook vulnerabilities, some of which would allow a remote 1517 attacker to gain root access to the BMC and potentially take control of 1518 the host system. Using data from Internet-wide scans, we find that there 1519 are at least 100,000 IPMI-enabled servers (across three large vendors) 1520 running on publicly accessible IP addresses, contrary to recommended 1521 best practice. Finally, we suggest defensive strategies for servers 1522 currently deployed and propose avenues for future work.</p> 1523 </div> 1524 </div> 1525 1526 <div class="citation"> 1527 <div class="title"><a href="https://jhalderm.com/pub/papers/iran-foci13.pdf">Internet Censorship in Iran: A First Look</a></div> 1528 <div class="author">Simurgh Aryan, Homa Aryan, and J. Alex Halderman</div> 1529 <div class="ref"><i>3rd USENIX Workshop on Free and Open Communications on the Internet</i> (FOCI ’13), Washington, DC, August 2013</div> 1530 <div class="abstract"> 1531 <p>The Iranian government operates one of the largest and most 1532 sophisticated Internet censorship regimes in the world, but the 1533 mechanisms it employs have received little research attention, primarily 1534 due to lack of access to network connections within the country and 1535 personal risks to Iranian citizens who take part. In this paper, we 1536 examine the status of Internet censorship in Iran based on network 1537 measurements conducted from a major Iranian ISP during the lead up to 1538 the June 2013 presidential election. We measure the scope of the 1539 censorship by probing Alexa’s top 500 websites in 18 different 1540 categories. We investigate the technical mechanisms used for HTTP 1541 Host–based blocking, keyword filtering, DNS hijacking, and 1542 protocol-based throttling. Finally, we map the network topology of the
1543 censorship infrastructure and find evidence that it relies heavily on 1544 centralized equipment, a property that might be fruitfully exploited by 1545 next generation approaches to censorship circumvention.</p> 1546 </div> 1547 </div> 1548 1549 <div class="citation"> 1550 <div class="title"><a href="https://jhalderm.com/pub/papers/cage-fc13.pdf">CAge: Taming Certificate Authorities by Inferring Restricted Scopes</a> <span class="altlink">(<a href="https://jhalderm.com/pub/papers/cage-fc13-ext.pdf">extended paper</a>)</span></div> 1551 <div class="author">James Kasten, Eric Wustrow, and J. Alex Halderman</div> 1552 <div class="ref"><i>17th International Conference on Financial Cryptography and Data Security</i> (FC ’13), Okinawa, Japan, April 2013</div> 1553 <div class="abstract"> 1554 <p>The existing HTTPS public-key infrastructure (PKI) uses a 1555 coarse-grained trust model: either a certificate authority (CA) is 1556 trusted by browsers to vouch for the identity of <i>any</i> domain or it 1557 is not trusted at all. More than a thousand root and intermediate CAs 1558 can currently sign certificates for any domain and be trusted by popular 1559 browsers. This violates the principle of least privilege and creates an 1560 excessively large attack surface, as highlighted by recent CA 1561 compromises. In this paper, we present CAge, a mechanism that browser 1562 makers can apply to drastically reduce the excessive trust placed in CAs 1563 without fundamentally altering the CA ecosystem or breaking existing 1564 practice. CAge works by imposing restrictions on the set of top-level 1565 domains (TLDs) for which each CA is trusted to sign. Our key 1566 observation, based on an Internet-wide survey of TLS certificates, is 1567 that CAs commonly sign for only a handful of TLDs; in fact, 90% of CAs 1568 have signed certificates for domains in fewer than ten TLDs, and only 1569 35% have ever signed a certificate for a domain in <span 1570 class="tt">.com</span>. We show that it is possible to algorithmically 1571 <i>infer</i> reasonable restrictions on CAs’ trusted scopes based 1572 on this behavior, and we present evidence that browser-enforced inferred 1573 scopes would be a durable and effective way to reduce the attack surface 1574 of the HTTPS PKI. We find that simple inference rules can reduce the 1575 attack surface by nearly a factor of ten without hindering 99% of CA 1576 signing activity over a six-month period.</p> 1577 </div> 1578 </div> 1579 1580 <div class="citation"> 1581 <div class="title"><a href="/pub/papers/weakkeys-sec12.pdf">Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices</a> <span class="altlink">(<a href="https://factorable.net">website</a>, <a href="/pub/papers/weakkeys-sec12-extended.pdf">extended paper</a>)</span></div> 1582 <div class="author">Nadia Heninger, Zakir Durumeric, Eric Wustrow, and J. Alex Halderman</div> 1583 <div class="ref"><i>21st USENIX Security Symposium</i> (Sec ’12), Bellevue, WA, August 2012 — <b>Best Paper Award</b> — <b>Test of Time Award (2022)</b></div> 1584 <div><small>Named one of Computing Reviews’ <a href="https://www.computingreviews.com/recommend/bestof/notableitems_2012.cfm">Notable Computing Books and Articles of 2012</a>.</small> </div> 1585 <div class="abstract"> 1586 <p>RSA and DSA can fail catastrophically when used with malfunctioning 1587 random number generators, but the extent to which these problems arise 1588 in practice has never been comprehensively studied at Internet scale. We 1589 perform the largest ever network survey of TLS and SSH servers and 1590 present evidence that vulnerable keys are surprisingly widespread. We 1591 find that 0.75% of TLS certificates share keys due to insufficient 1592 entropy during key generation, and we suspect that another 1.70% come 1593 from the same faulty implementations and may be susceptible to 1594 compromise. Even more alarmingly, we are able to obtain RSA private keys 1595 for 0.50% of TLS hosts and 0.03% of SSH hosts, because their public keys 1596 shared nontrivial common factors due to entropy problems, and DSA 1597 private keys for 1.03% of SSH hosts, because of insufficient signature 1598 randomness. We cluster and investigate the vulnerable hosts, finding 1599 that the vast majority appear to be headless or embedded devices. In 1600 experiments with three software components commonly used by these 1601 devices, we are able to reproduce the vulnerabilities and identify 1602 specific software behaviors that induce them, including a boot-time 1603 entropy hole in the Linux random number generator. Finally, we suggest 1604 defenses and draw lessons for developers, users, and the security 1605 community.</p> 1606 </div> 1607 </div> 1608 1609 <div class="citation"> 1610 <div class="title"><a href="/pub/papers/dcvoting-fc12.pdf">Attacking the Washington, D.C. Internet Voting System</a> <span class="altlink">(<a href="https://freedom-to-tinker.com/blog/jhalderm/hacking-dc-internet-voting-pilot">blog post</a>, <a href="https://josephhall.org/nqb2/index.php/dccouncildvm">testimony</a>)</span></div> 1611 <div class="author">Scott Wolchok, Eric Wustrow, Dawn Isabel, and J. Alex Halderman</div> 1612 <div class="ref"><i>16th Intl. Conference on Financial Cryptography and Data Security</i> (FC ’12), Bonaire, February 2012</div> 1613 <div class="abstract"> 1614 <p>In 2010, Washington, D.C. developed an Internet voting pilot project 1615 that was intended to allow overseas absentee voters to cast their 1616 ballots using a website. Prior to deploying the system in the general 1617 election, the District held a unique public trial: a mock election 1618 during which anyone was invited to test the system or attempt to 1619 compromise its security. This paper describes our experience 1620 participating in this trial. Within 48 hours of the system going live, 1621 we had gained near-complete control of the election server. We 1622 successfully changed every vote and revealed almost every secret ballot. 1623 Election officials did not detect our intrusion for nearly two business 1624 days—and might have remained unaware for far longer had we not 1625 deliberately left a prominent clue. This case study—the first (to 1626 our knowledge) to analyze the security of a government Internet voting 1627 system from the perspective of an attacker in a realistic pre-election 1628 deployment—attempts to illuminate the practical challenges of 1629 securing online voting as practiced today by a growing number of 1630 jurisdictions.</p> 1631 </div> 1632 </div> 1633 1634 <div class="citation"> 1635 <div class="title"><a href="/pub/papers/telex-sec11.pdf">
1635Telex: Anticensorship in the Network Infrastructure</a> <span class="altlink">(<a href="https://telex.cc">website and software</a>, <a href="https://www.youtube.com/watch?v=a_2IDvTLz7I">video</a>)</span></div> 1636 <div class="author">Eric Wustrow, Scott Wolchok, Ian Goldberg, and J. Alex Halderman</div> 1637 <div class="ref"><i>20th USENIX Security Symposium</i> (Sec ’11), San Francisco, CA, August 2011 — <b>Runner-up for <a href="https://petsymposium.org/award/winners.php">2012 PET Award</a></b></div> 1638 <div class="abstract"> 1639 <p>In this paper, we present Telex, a new approach to resisting 1640 state-level Internet censorship. Rather than attempting to win the 1641 cat-and-mouse game of finding open proxies, we leverage censors’ 1642 unwillingness to completely block day-to-day Internet access. In effect, 1643 Telex converts innocuous, unblocked websites into proxies, without their 1644 explicit collaboration. We envision that friendly ISPs would deploy 1645 Telex stations on paths between censors’ networks and popular, 1646 uncensored Internet destinations. Telex stations would monitor seemingly 1647 innocuous flows for a special “tag” and transparently divert 1648 them to a forbidden website or service instead. We propose a new 1649 cryptographic scheme based on elliptic curves for tagging TLS handshakes 1650 such that the tag is visible to a Telex station but not to a censor. In 1651 addition, we use our tagging scheme to build a protocol that allows 1652 clients to connect to Telex stations while resisting both passive and 1653 active attacks. We also present a proof-of-concept implementation that 1654 demonstrates the feasibility of our system.</p> 1655 </div> 1656 </div> 1657 1658 <div class="citation"> 1659 <div class="title"><a href="/pub/papers/china-pam11.pdf">Internet Censorship in China: Where Does the Filtering Occur?</a></div> 1660 <div class="author">Xueyang Xu, Z. Morley Mao, and J. Alex Halderman</div> 1661 <div class="ref"><i>12th Passive and Active Measurement Conference</i> (PAM ’11), Atlanta, GA, March 2011</div> 1662 <div class="abstract"> 1663 <p>China filters Internet traffic in and out of the country. In order to 1664 circumvent the firewall, it is helpful to know where the filtering 1665 occurs. In this work, we explore the AS-level topology of China’s 1666 network, and probe the firewall to find the locations of filtering 1667 devices. We find that even though most filtering occurs in border ASes, 1668 choke points also exist in many provincial networks. The result suggests 1669 that two major ISPs in China have different approaches for placing 1670 filtering devices.</p> 1671 </div> 1672 </div> 1673 1674 <div class="citation"> 1675 <div class="title"><a href="/pub/papers/pwnage-fc11.pdf">Absolute Pwnage: Security Risks of Remote Administration Tools</a> <span class="altlink">(<a href="https://www.freedom-to-tinker.com/blog/jhalderm/schools-laptop-spying-software-exploitable-anywhere">blog post</a>)</span></div> 1676 <div class="author">Jay Novak, Jonathan Stribley, Kenneth Meagher, and J. Alex Halderman</div> 1677 <div class="ref"><i>15th International Financial Cryptography Conference</i> (FC ’11), February 2011</div> 1678 <div class="abstract"> 1679 <p>Many IT departments use remote administration products to configure, 1680 monitor, and maintain the systems they manage. These tools can be 1681 beneficial in the right hands, but they can also be devastating if 1682 attackers exploit them to seize control of machines. As a case study, we 1683 analyze the security of a remote administration product called Absolute 1684 Manage. We find that the system’s communication protocol suffers 1685 from serious design flaws and fails to provide adequate integrity, 1686 confidentiality, or authentication. Attackers can exploit these 1687 vulnerabilities to issue unauthorized commands on client systems and 1688 execute arbitrary code with administrator privileges. These blatant 1689 vulnerabilities suggest that remote administration tools require 1690 increased scrutiny from the security community. We recommend that 1691 developers adopt defensive designs that limit the damage attackers can 1692 cause if they gain control.</p> 1693 </div> 1694 </div> 1695 1696 <div class="citation"> 1697 <div class="title"><a href="/pub/papers/voting-wecsr11.pdf">Ethical Issues in E-Voting Security Analysis</a></div> 1698 <div class="author">David G. Robinson and J. Alex Halderman</div> 1699 <div class="ref"><i>2nd Workshop on Ethics in Computer Security Research</i> (WECSR ’11), March 2011</div> 1700 <div class="abstract"> 1701 <p>Research about weaknesses in deployed electronic voting systems 1702 raises a variety of pressing ethical concerns. In addition to ethical 1703 issues common to vulnerability research, such as the potential harms and 1704 benefits of vulnerability disclosure, electronic voting researchers face 1705 questions that flow from the unique and important role voting plays in 1706 modern democratic societies. Should researchers worry that their own 1707 work (not unlike the flaws they study) could sway an election outcome? 1708 When elected officials authorize a security review, how should 1709 researchers address the conflicted interests of these incumbent 1710 politicians, who may have powerful incentives to downplay problems, and 1711 might in principle be in a position to exploit knowledge about 1712 vulnerabilities when they stand for re-election? How should researchers 1713 address the risk that identifying specific flaws will lead to a false 1714 sense of security, after those particular problems have been resolved? 1715 This paper makes an early effort to address these and other questions 1716 with reference to experience from previous e-voting security reviews. We 1717 hope our provisional analysis will help practicing researchers 1718 anticipate and address ethical issues in future studies.</p> 1719 </div> 1720 </div> 1721 1722 <div class="citation"> 1723 <div class="title"><a href="/pub/papers/evm-ccs10.pdf">Security Analysis of India’s Electronic Voting Machines</a> <span class="altlink">(<a href="https://indiaevm.org">
1723website and video</a>)</span></div> 1724 <div class="author">Scott Wolchok, Eric Wustrow, J. Alex Halderman, Hari K. Prasad, Arun Kankipati, Sai Krishna Sakhamuri, Vasavya Yagati, and Rop Gonggrijp</div> 1725 <div class="ref"><i>17th ACM Conference on Computer and Communications Security</i> (CCS ’10), Chicago, IL, October 2010</div> 1726 <div class="abstract"> 1727 <p>Elections in India are conducted almost exclusively using electronic 1728 voting machines developed over the past two decades by a pair of 1729 government-owned companies. These devices, known in India as EVMs, have 1730 been praised for their simple design, ease of use, and reliability, but 1731 recently they have also been criticized following widespread reports of 1732 election irregularities. Despite this criticism, many details of the 1733 machines’ design have never been publicly disclosed, and they have 1734 not been subjected to a rigorous, independent security evaluation. In 1735 this paper, we present a security analysis of a real Indian EVM obtained 1736 from an anonymous source. We describe the machine’s design and 1737 operation in detail, and we evaluate its security in light of relevant 1738 election procedures. We conclude that in spite of the machines’ 1739 simplicity and minimal software trusted computing base, they are 1740 vulnerable to serious attacks that can alter election results and 1741 violate the secrecy of the ballot. We demonstrate two attacks, 1742 implemented using custom hardware, which could be carried out by 1743 dishonest election insiders or other criminals with only brief physical 1744 access to the machines. This case study carries important lessons for 1745 Indian elections and for electronic voting security more generally.</p> 1746 </div> 1747 </div> 1748 1749 <div class="citation"> 1750 <div class="title"><a href="/pub/papers/dht-woot10.pdf">Crawling BitTorrent DHTs for Fun and Profit</a></div> 1751 <div class="author">Scott Wolchok and J. Alex Halderman</div> 1752 <div class="ref"><i>4th USENIX Workshop on Offensive Technologies</i> (WOOT ’10), Washington, DC, August 2010</div> 1753 <div class="abstract"> 1754 <p>This paper presents two kinds of attacks based on crawling the DHTs 1755 used for distributed BitTorrent tracking. First, we show how pirates can 1756 use crawling to rebuild BitTorrent search engines just a few hours after 1757 they are shut down <i>(crawling for fun)</i>. Second, we show how 1758 content owners can use related techniques to monitor pirates’ 1759 behavior in preparation for legal attacks and negate any perceived 1760 anonymity of the decentralized BitTorrent architecture <i>(crawling for 1761 profit)</i>.</p> 1762 <p>We validate these attacks and measure their performance with a 1763 crawler we developed for the Vuze DHT. We find that we can establish a 1764 search engine with over one million torrents in under two hours using a 1765 single desktop PC. We also track 7.9 million IP addresses downloading 1766 1.5 million torrents over 16 days. These results imply that shifting 1767 from centralized BitTorrent tracking to DHT-based tracking will have 1768 mixed results for the file sharing arms race. While it will likely make 1769 illicit torrents harder to quash, it will not help users hide their 1770 activities.</p> 1771 </div> 1772 </div> 1773 1774 <div class="citation"> 1775 <div class="title"><a href="/pub/papers/sketcha-www10.pdf">Sketcha: A Captcha Based on Line Drawings of 3D Models</a> <span class="altlink">(<a href="https://www.cs.princeton.edu/gfx/pubs/Ross_2010_SAC/index.php">website</a>)</span></div> 1776 <div class="author">Steven A. Ross, J. Alex Halderman, and Adam Finkelstein</div> 1777 <div class="ref"><i>19th International World Wide Web Conference</i> (WWW ’10), Raleigh, NC, April 2010</div> 1778 <div class="abstract"> 1779 <p>This paper introduces a captcha based on upright orientation of line 1780 drawings rendered from 3D models. The models are selected from a large 1781 database, and images are rendered from random viewpoints, affording many 1782 different drawings from a single 3D model. The captcha presents the user 1783 with a set of images, and the user must choose an upright orientation 1784 for each image. This task generally requires understanding of the 1785 semantic content of the image, which is believed to be difficult for 1786 automatic algorithms. We describe a process called covert filtering 1787 whereby the image database can be continually refreshed with drawings 1788 that are known to have a high success rate for humans, by inserting 1789 randomly into the captcha new images to be evaluated. Our analysis shows 1790 that covert filtering can ensure that captchas are likely to be solvable 1791 by humans while deterring attackers who wish to learn a portion of the 1792 database. We performed several user studies that evaluate how 1793 effectively people can solve the captcha. Comparing these results to an 1794 attack based on machine learning, we find that humans possess a 1795 substantial performance advantage over computers.</p> 1796 </div> 1797 </div> 1798 1799 <div class="citation"> 1800 <div class="title"><a href="/pub/papers/unvanish-ndss10-web.pdf">Defeating Vanish with Low-Cost Sybil Attacks Against Large DHTs</a> <span class="altlink">(<a href="https://www.freedom-to-tinker.com/blog/felten/breaking-vanish-story-security-research-action">blog post</a>)</span></div> 1801 <div class="author">Scott Wolchok, Owen S. Hofmann, Nadia Heninger, Edward W. Felten, J. Alex Halderman, Christopher J. Rossbach, Brent Waters, and Emmett Witchel</div> 1802 <div class="ref"><i>17th Network and Distributed System Security Symposium</i> (NDSS ’10), San Diego, CA, February-March 2010</div> 1803 <div class="abstract"> 1804 <p>Researchers at the University of Washington recently proposed Vanish, 1805 a system for creating messages that automatically 1806 “self-destruct” after a period of time. Vanish works by 1807 encrypting each message with a random key and storing shares of the key 1808 in a large, public distributed hash table (DHT). Normally, DHTs expunge 1809 data older than a certain age. After they expire, the key is permanently 1810 lost, and the encrypted data is permanently unreadable. Vanish is an 1811 interesting approach to an important privacy problem, but, in its 1812 current form, it is insecure. In this paper, we defeat the deployed 1813 Vanish implementation, explain how the original paper’s security 1814 analysis is flawed, and draw lessons for future system designs.</p> 1815 <p>We present two Sybil attacks against the current Vanish 1816 implementation, which stores its encryption keys in the million-node 1817 Vuze BitTorrent DHT. These attacks work by continuously crawling the DHT 1818 and saving each stored value before it ages out. They can efficie
1818ntly 1819 recover keys for more than 99% of Vanish messages. We show that the 1820 dominant cost of these attacks is network data transfer, not memory 1821 usage as the Vanish authors expected, and that the total cost is two 1822 orders of magnitude less than they estimated. While we consider 1823 potential defenses, we conclude that public DHTs like Vuze probably 1824 cannot provide strong security for Vanish.</p> 1825 </div> 1826 </div> 1827 1828 <div class="citation"> 1829 <div class="title"><a href="/pub/papers/avc-evt09.pdf">Can DREs Provide Long-Lasting Security? The Case of Return-Oriented Programming and the AVC Advantage</a> <span class="altlink">(<a href="https://web.archive.org/web/20100625163538/https://cseweb.ucsd.edu/groups/security/avc/">website and video</a>)</span></div> 1830 <div class="author">Steve Checkoway, Ariel J. Feldman, Brian Kantor, J. Alex Halderman, Edward W. Felten, and Hovav Shacham</div> 1831 <div class="ref"><i>2009 USENIX/ACCURATE/IAVoSS Electronic Voting Technology Workshop</i> (EVT ’09), Montreal, QC, August 2009</div> 1832 <div class="abstract"> 1833 <p>A secure voting machine design must withstand new attacks devised 1834 throughout its multidecade service lifetime. In this paper, we give a 1835 case study of the longterm security of a voting machine, the Sequoia AVC 1836 Advantage, whose design dates back to the early 80s. The AVC Advantage 1837 was designed with promising security features: its software is stored 1838 entirely in read-only memory and the hardware refuses to execute 1839 instructions fetched from RAM. Nevertheless, we demonstrate that an 1840 attacker can induce the AVC Advantage to misbehave in arbitrary 1841 ways—including changing the outcome of an election—by means 1842 of a memory cartridge containing a specially-formatted payload. Our 1843 attack makes essential use of a recently-invented exploitation technique 1844 called return-oriented programming, adapted here to the Z80 processor. 1845 In return-oriented programming, short snippets of benign code already 1846 present in the system are combined to yield malicious behavior. Our 1847 results demonstrate the relevance of recent ideas from systems security 1848 to voting machine research, and vice versa. We had no access either to 1849 source code or documentation beyond that available on Sequoia’s 1850 web site. We have created a complete vote-stealing demonstration exploit 1851 and verified that it works correctly on the actual hardware.</p> 1852 </div> 1853 </div> 1854 1855 <div class="citation"> 1856 <div class="title"><a href="/pub/papers/paper-oak09.pdf">Fingerprinting Blank Paper Using Commodity Scanners</a> <span class="altlink">(<a href="https://web.archive.org/web/20110116061554/http://citp.princeton.edu/paper/">website</a>)</span></div> 1857 <div class="author">William Clarkson, Tim Weyrich, Adam Finkelstein, Nadia Heninger, J. Alex Halderman, and Edward W. Felten</div> 1858 <div class="ref"><i>30th IEEE Symposium on Security and Privacy</i> (Oakland ’09), Oakland, CA, May 2009</div> 1859 <div class="abstract"> 1860 <p>This paper presents a novel technique for authenticating physical 1861 documents based on random, naturally occurring imperfections in paper 1862 texture. We introduce a new method for measuring the three-dimensional 1863 surface of a page using only a commodity scanner and without modifying 1864 the document in any way. From this physical feature, we generate a 1865 concise fingerprint that uniquely identifies the document. Our technique 1866 is secure against counterfeiting and robust to harsh handling; it can be 1867 used even before any content is printed on a page. It has a wide range 1868 of applications, including detecting forged currency and tickets, 1869 authenticating passports, and halting counterfeit goods. Document 1870 identification could also be applied maliciously to de-anonymize printed 1871 surveys and to compromise the secrecy of paper ballots.</p> 1872 </div> 1873 </div> 1874 1875 <div class="citation"> 1876 <div class="title"><a href="/pub/papers/coldboot-sec08.pdf">Lest We Remember: Cold Boot Attacks on Encryption Keys</a> <span class="altlink">(<a href="https://web.archive.org/web/20110429202434/http://citp.princeton.edu/memory/">website and videos</a>)</span></div> 1877 <div class="author">J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten</div> 1878 <div class="ref"><i>17th USENIX Security Symposium</i> (Sec ’08), San Jose, CA, July 2008 — <b>Best Student Paper Award</b> — <b><a href="https://web.archive.org/web/20210506040522/https://pwnie
1878s.com/archive/2008/winners/">Pwnie Award </a></b></div> 1879 <div class="ref">Reprinted in <i><a href="/pub/papers/coldboot-cacm09.pdf">Communications of the ACM</a></i>, <!--52(5):91-98,--> May 2009</div> 1880 <div class="abstract"> 1881 <p>Contrary to popular assumption, DRAMs used in most modern computers 1882 retain their contents for seconds to minutes after power is lost, even 1883 at operating temperatures and even if removed from a motherboard. 1884 Although DRAMs become less reliable when they are not refreshed, they 1885 are not immediately erased, and their contents persist sufficiently for 1886 malicious (or forensic) acquisition of usable full-system memory images. 1887 We show that this phenomenon limits the ability of an operating system 1888 to protect cryptographic key material from an attacker with physical 1889 access. We use cold reboots to mount attacks on popular disk encryption 1890 systems — BitLocker, FileVault, dm-crypt, and TrueCrypt — 1891 using no special devices or materials. We experimentally characterize 1892 the extent and predictability of memory remanence and report that 1893 remanence times can be increased dramatically with simple techniques. We 1894 offer new algorithms for finding cryptographic keys in memory images and 1895 for correcting errors caused by bit decay. Though we discuss several 1896 strategies for partially mitigating these risks, we know of no simple 1897 remedy that would eliminate them.</p> 1898 </div> 1899 </div> 1900 1901 <div class="citation"> 1902 <div class="title"><a href="/pub/papers/prng-evt08.pdf">In Defense of Pseudorandom Sample Selection</a></div> 1903 <div class="author">Joseph A. Calandrino, J. Alex Halderman, and Edward W. Felten</div> 1904 <div class="ref"><i>2008 USENIX/ACCURATE Electronic Voting Technology Workshop</i> (EVT ’08), San Jose, CA, July 2008</div> 1905 <div class="abstract"> 1906 <p>Generation of random numbers is a critical component of existing 1907 post-election auditing techniques. Recent work has largely discouraged 1908 the use of all pseudorandom number generators, including 1909 cryptographically secure pseudorandom number generators (CSPRNGs), for 1910 this purpose, instead recommending the sole use of observable physical 1911 techniques. In particular, simple dice rolling has received a great deal 1912 of positive attention. The typical justification for this recommendation 1913 is that those less comfortable with mathematics prefer a simple, 1914 observable technique. This paper takes a contrary view. Simple, 1915 observable techniques like dice rolling are not necessarily robust 1916 against sleight of hand and other forms of fraud, and attempts to harden 1917 them against fraud can dramatically increase their complexity. With 1918 simple dice rolling, we know of no techniques that provide citizens with 1919 a reasonable means of verifying that fraud did not occur during the roll 1920 process. CSPRNGs, used properly, can be simple, robust, and verifiable, 1921 and they allow for the use of auditing techniques that might otherwise 1922 be impractical. While we understand initial skepticism towards this 1923 option, we argue that appropriate use of CSPRNGs would strengthen audit 1924 security.</p> 1925 </div> 1926 </div> 1927 1928 <div class="citation"> 1929 <div class="title"><a href="/pub/papers/stopgap-evt08.pdf">You Go to Elections with the Voting System You Have: Stop-Gap Mitigations for Deployed Voting Systems</a></div> 1930 <div class="author">J. Alex Halderman, Eric Rescorla, Hovav Shacham, and David Wagner</div> 1931 <div class="ref"><i>2008 USENIX/ACCURATE Electronic Voting Technology Workshop</i> (EVT ’08), San Jose, CA, July 2008</div> 1932 <div class="abstract"> 1933 <p>In light of the systemic vulnerabilities uncovered by recent reviews 1934 of deployed e-voting systems, the surest way to secure the voting 1935 process would be to scrap the existing systems and design new ones. 1936 Unfortunately, engineering new systems will take years, and many 1937 jurisdictions are unlikely to be able to afford new equipment in the 1938 near future. In this paper we ask how jurisdictions can make the best 1939 use of the equipment they already own until they can replace it. 1940 Starting from current practice, we propose defenses that involve new but 1941 realistic procedures, modest changes to existing software, and no 1942 changes to existing hardware. Our techniques achieve greatly improved 1943 protection against outsider attacks: they provide containment of viral 1944 spread, improve the integrity of vote tabulation, and offer some 1945 detection of individual compromised devices. They do not provide 1946 security against insiders with access to election management systems, 1947 which appears to require significantly greater changes to the existing 1948 systems.</p> 1949 </div> 1950 </div> 1951 1952 <div class="citation"> 1953 <div class="title"><a href="/pub/papers/harvest-ccs07.pdf">Harvesting Verifiable Challenges from Oblivious Online Sources</a></div> 1954 <div class="author">J. Alex Halderman and Brent Waters</div> 1955 <div class="ref"><i>14th ACM Conference on Computer and Communications Security</i> (CCS ’07), Washington, DC, October 2007</div> 1956 <div class="abstract"> 1957 <p>Several important security protocols require parties to perform 1958 computations based on random challenges. Traditionally, proving that the 1959 challenges were randomly chosen has required interactive communication 1960 among the parties or the existence of a trusted server. We offer an 1961 alternative solution where challenges are harvested from oblivious 1962 servers on the Internet. This paper describes a framework for deriving 1963 “harvested challenges” by mixing data from various 1964 pre-existing online sources. While individual sources may become 1965 predictable or fall under adversarial control, we provide a policy 1966 language that allows application developers to specify comb
1966inations of 1967 sources that meet their security needs. Participants can then convince 1968 each other that their challenges were formed freshly and in accordance 1969 with the policy. We present Combine, an open source implementation of 1970 our framework, and show how it can be applied to a variety of 1971 applications, including remote storage auditing and non-interactive 1972 client puzzles.</p> 1973 </div> 1974 </div> 1975 1976 <div class="citation"> 1977 <div class="title"><a href="/pub/papers/audit-evt07-full.pdf">Machine-Assisted Election Auditing</a> <span class="altlink">(<a href="/pub/papers/audit-evt07.pdf">workshop version</a>)</span></div> 1978 <div class="author">Joseph A. Calandrino, J. Alex Halderman, and Edward W. Felten</div> 1979 <div class="ref"><i>2007 USENIX/ACCURATE Electronic Voting Technology Workshop</i> (EVT ’07), Boston, MA, August 2007</div> 1980 <div class="abstract"> 1981 <p>Election audit procedures usually rely on precinct based recounts, in 1982 which workers manually review all paper ballots from selected polling 1983 places, but these recounts can be expensive due to the labor required. 1984 This paper proposes an alternative audit strategy that allows machines 1985 to perform most of the work. Precincts are recounted using recounting 1986 machines, and their output is manually audited using efficient ballot 1987 sampling techniques. This strategy can achieve equal or greater 1988 confidence than precinct-based auditing at a significantly lower cost 1989 while protecting voter privacy better than previous ballot-based 1990 auditing methods. We show how to determine which ballots to audit 1991 against the recounting machines’ records and compare this new 1992 approach to precinct-based audits in the context of Virginia’s 1993 November 2006 election. Far fewer ballots need to be audited by hand 1994 using our approach. We also explore extensions to these techniques, such 1995 as varying individual ballots’ audit probabilities based on the 1996 votes they contain, that promise further efficiency gains.</p> 1997 </div> 1998 </div> 1999 2000 <div class="citation"> 2001 <div class="title"><a href="/pub/papers/ts-evt07.pdf">Security Analysis of the Diebold AccuVote-TS Voting Machine</a> <span class="altlink">(<a href="/pub/papers/ts-evt07-init.pdf">initial public version</a>, <a href="https://web.archive.org/web/20110713050334/http://citp.princeton.edu/voting/">website and videos</a>)</span></div> 2002 <div class="author">Ariel J. Feldman, J. Alex Halderman, and Edward W. Felten</div> 2003 <div class="ref"><i>2007 USENIX/ACCURATE Electronic Voting Technology Workshop</i> (EVT ’07), Boston, MA, August 2007</div> 2004 <div class="abstract"> 2005 <p>This paper presents a fully independent security study of a Diebold 2006 AccuVote-TS voting machine, including its hardware and software. We 2007 obtained the machine from a private party. Analysis of the machine, in 2008 light of real election procedures, shows that it is vulnerable to 2009 extremely serious attacks. For example, an attacker who gets physical 2010 access to a machine or its removable memory card for as little as one 2011 minute could install malicious code; malicious code on a machine could 2012 steal votes undetectably, modifying all records, logs, and counters to 2013 be consistent with the fraudulent vote count it creates. An attacker 2014 could also create malicious code that spreads automatically and silently 2015 from machine to machine during normal election activities — a 2016 voting-machine virus. We have constructed working demonstrations of 2017 these attacks in our lab. Mitigating these threats will require changes 2018 to the voting machine’s hardware and software and the adoption of 2019 more rigorous election procedures.</p> 2020 </div> 2021 </div> 2022 2023 <div class="citation"> 2024 <div class="title"><a href="/pub/papers/rootkit-sec06.pdf">Lessons from the Sony CD DRM Episode</a> <span class="altlink">(<a href="/pub/papers/rootkit-sec06-full.pdf">extended version</a>, <a href="https://web.archive.org/web/20120128072803/https://freedom-to-tinker.com/tags/cd-copy-protection">blog posts</a>)</span></div> 2025 <div class="author">J. Alex Halderman and Edward W. Felten</div> 2026 <div class="ref"><i>15th USENIX Security Symposium</i> (Sec ’06), Vancouver, BC, August 2006</div> 2027 <div class="abstract"> 2028 <p>In the fall of 2005, problems discovered in two Sony-BMG compact disc 2029 copy protection systems, XCP and MediaMax, triggered a public uproar 2030 that ultimately led to class-action litigation and the recall of 2031 millions of discs. We present an in-depth analysis of these 2032 technologies, including their design, implementation, and deployment. 2033 The systems are surprisingly complex and suffer from a diverse array of 2034 flaws that weaken their content protection and expose users to serious 2035 security and privacy risks. Their complexity, and their failure, makes 2036 them an interesting case study of digital rights management that carries
2037 valuable lessons for content companies, DRM vendors, policymakers, end 2038 users, and the security community.</p> 2039 </div> 2040 </div> 2041 2042 <div class="citation"> 2043 <div class="title"><a href="/pub/papers/password-www05.pdf">A Convenient Method for Securely Managing Passwords</a></div> 2044 <div class="author">J. Alex Halderman, Brent Waters, and Edward W. Felten</div> 2045 <div class="ref"><i>14th International World Wide Web Conference</i> (WWW ’05), Chiba, Japan, May 2005</div> 2046 <div class="abstract"> 2047 <p>Computer users are asked to generate, keep secret, and recall an 2048 increasing number of passwords for uses including host accounts, email 2049 servers, e-commerce sites, and online financial services. Unfortunately, 2050 the password entropy that users can comfortably memorize seems 2051 insufficient to store unique, secure passwords for all these accounts, 2052 and it is likely to remain constant as the number of passwords (and the 2053 adversary’s computational power) increases into the future. In 2054 this paper, we propose a technique that uses a strengthened 2055 cryptographic hash function to compute secure passwords for arbitrarily 2056 many accounts while requiring the user to memorize only a single short 2057 password. This mechanism functions entirely on the client; no 2058 server-side changes are needed. Unlike previous approaches, our design 2059 is both highly resistant to brute force attacks and nearly stateless, 2060 allowing users to retrieve their passwords from any location so long as 2061 they can execute our program and remember a short secret. This 2062 combination of security and convenience will, we believe, entice users 2063 to adopt our scheme. We discuss the construction of our algorithm in 2064 detail, compare its strengths and weaknesses to those of related 2065 approaches, and present Password Multiplier, an implementation in the 2066 form of an extension to the Mozilla Firefox web browser.</p> 2067 </div> 2068 </div> 2069 2070 <div class="citation"> 2071 <div class="title"><a href="/pub/papers/memex-wpes04.pdf">Privacy Management for Portable Recording Devices</a></div> 2072 <div class="author">J. Alex Halderman, Brent Waters, and Edward W. Felten</div> 2073 <div class="ref"><i>2004 ACM Workshop on Privacy in the Electronic Society</i> (WPES ’04), Washington, DC, October 2004</div> 2074 <div class="abstract"> 2075 <p>The growing popularity of inexpensive, portable recording devices, 2076 such as cellular phone cameras and compact digital audio recorders, 2077 presents a significant new threat to privacy. We propose a set of 2078 technologies that can be integrated into recording devices to provide 2079 stronger, more accurately targeted privacy protections than other legal 2080 and technical measures now under consideration. Our design is based on 2081 an informed consent principle, which it supports by the use of novel 2082 devices and protocols that automate negotiations over consent and ensure 2083 appropriate safeguards on recorded data. We define the protocols needed 2084 for this purpose and establish their security. We also describe a 2085 working prototype implementation that safeguards audio recorded by 2086 laptop PCs in a wireless network.</p> 2087 </div> 2088 </div> 2089 2090 <div class="citation"> 2091 <div class="title"><a href="/pub/papers/puzzle-ccs04.pdf">New Client Puzzle Outsourcing Techniques for DoS Protection</a></div> 2092 <div class="author">Brent Waters, Ari Juels, J. Alex Halderman, and Edward W. Felten</div> 2093 <div class="ref"><i>11th ACM Conference on Computer and Communications Security</i> (CCS ’04), Washington, DC, October 2004</div> 2094 <div class="abstract"> 2095 <p>We explore new techniques for the use of cryptographic puzzles as a 2096 countermeasure to Denial-of-Service (DoS) attacks. We propose simple new 2097 techniques that permit the <i>outsourcing</i> of puzzles--their 2098 distribution via a robust external service that we call a 2099 <i>bastion</i>. Many servers can rely on puzzles distributed by a single 2100 bastion. We show how a bastion, somewhat surprisingly, need not know 2101 which servers rely on its services. Indeed, in one of our constructions, 2102 a bastion may consist merely of a publicly accessible random data 2103 source, rather than a special purpose server. Our outsourcing techniques 2104 help eliminate puzzle distribution as a point of compromise. Our design 2105 has three main advantages over prior approaches. First, it is more 2106 resistant to DoS attacks aimed at the puzzle mechanism itself, 2107 withstanding over 80% more attack traffic than previous methods in our 2108 experiments. Second, our scheme is cheap enough to apply at the IP 2109 level, though it also works at higher levels of the protocol stack. 2110 Third, our method allows clients to solve puzzles offline, reducing the 2111 need for users to wait while their computers solve puzzles. We present a 2112 prototype implementation of our approach, and we describe experiments 2113 that validate our performance claims.</p> 2114 </div> 2115 </div> 2116 2117 <div class="citation"> 2118 <div class="title"><a href="/pub/papers/search-web3d03.pdf">Early Experiences with a 3D Model Search Engine</a></div> 2119 <div class="author">Patrick Min, J. Alex Halderman, Michael Kazhdan, and Thomas A. Funkhouser</div> 2120 <div class="ref"><i>8th International Conference on 3D Web Technology</i> (Web3D ’03), March 2003 — <b>Best Paper Award</b></div> 2121 <div class="abstract"> 2122 <p>New acquisition and modeling tools make it easier to create 3D 2123 models, and fordable and powerful graphics hardware makes it easier to 2124 use them. As a result, the number of 3D models available on the web is 2125 increasing rapidly. However, it is still not as easy to find 3D models 2126 as it is to find, for example, text documents and images. What is needed 2127 is a “3D model search engine,” a specialized search engine 2128 that targets 3D models. We created a prototype 3D model search engine to 2129 investigate the design and implementation issues. Our search engine can 2130 be partitioned into three main components: (1) acquisition: 3D models 2131 have to be collected from the web, (2) analysis: they have to be 2132 analyzed for later matching, and (3) query processing and matching: an 2133 online system has to match user queries to the collected 3D models. Our 2134 site currently indexes over 36,000 models, of which about 31,000 are 2135 freely available. In addition to a text search interface, it offers 2136 several 3D and 2D shape-based query interfaces. Since it went online one 2137 year ago (in November 2001), it has processed over 148,000 searches from
2138 37,800 hosts in 103 different countries. Currently 20-25% of the about 2139 1,000 visitors per week are returning users. This paper reports on our 2140 initial experiences designing, building, and running the 3D model search 2141 engine.</p> 2142 </div> 2143 </div> 2144 2145 <div class="citation"> 2146 <div class="title"><a href="/pub/papers/search-tog03.pdf">A Search Engine for 3D Models</a></div> 2147 <div class="author">Thomas Funkhouser, Patrick Min, Misha Kazhdan, Joyce Chen, J. Alex Halderman, David Dobkin, and David Jacobs</div> 2148 <div class="ref"><i>ACM Transactions on Graphics</i>, 22(1):83-105, January 2003</div> 2149 <div class="abstract"> 2150 <p>As the number of 3D models available on the Web grows, there is an 2151 increasing need for a search engine to help people find them. 2152 Unfortunately, traditional text-based search techniques are not always 2153 effective for 3D data. In this paper, we investigate new shape-based 2154 search methods. The key challenges are to develop query methods simple 2155 enough for novice users and matching algorithms robust enough to work 2156 for arbitrary polygonal models. We present a web-based search engine 2157 system that supports queries based on 3D sketches, 2D sketches, 3D 2158 models, and/or text keywords. For the shape-based queries, we have 2159 developed a new matching algorithm that uses spherical harmonics to 2160 compute discriminating similarity measures without requiring repair of 2161 model degeneracies or alignment of orientations. It provides 46.245% 2162 better performance than related shape matching methods during 2163 precision-recall experiments, and it is fast enough to return query 2164 results from a repository of 20,000 models in under a second. The net 2165 result is a growing interactive index of 3D models available on the Web 2166 (i.e., a Google for 3D models).</p> 2167 </div> 2168 </div> 2169 2170 <div class="citation"> 2171 <div class="title"><a href="/pub/papers/cdcopy-drm02.pdf">Evaluating New Copy-Prevention Techniques for Audio CDs</a></div> 2172 <div class="author">J. Alex Halderman</div> 2173 <div class="ref"><i>ACM Workshop on Digital Rights Management</i> (DRM ’02), Washington, DC, November 2002</div> 2174 <div class="abstract"> 2175 <p>Several major record labels are adopting a new family of 2176 copy-prevention techniques intended to limit “casual” 2177 copying by compact disc owners using their personal computers. These 2178 employ deliberate data errors introduced into discs during manufacturing 2179 to cause incompatibility with PCs without affecting ordinary CD players. 2180 We examine three such recordings: A Tribute to Jim Reeves by Charley 2181 Pride, A New Day Has Come by Celine Dion, and More Music from The Fast 2182 and the Furious by various artists. In tests with different CD-ROM 2183 drives, operating systems, and playback software, we find these discs 2184 are unreadable in several widely-used applications as of July 2002. We 2185 analyze the specific technical differences between the modified 2186 recordings and standard audio CDs, and we consider repairs to hardware 2187 and software that would restore compatibility. We conclude that these 2188 schemes are harmful to legitimate CD owners and will not reduce illegal 2189 copying in the long term, so the music industry should reconsider their 2190 deployment.</p> 2191 </div> 2192 </div> 2193 2194 <h3>Selected other publications</h3> 2195 2196 <div class="citation"> 2197 <div class="title"><a href="/pub/misc/eac-comment-2023.pdf">Voter Privacy and VVSG 2.0</a></div> 2198 <div class="author">Braden Crimmins, Dhanya Narayanan, J. Alex Halderman, and Drew Springall</div> 2199 <div class="ref">Public comments in response to <a href="https://www.regulations.gov/document/EAC-2023-0001-0001">U.S. EAC VVSG 2.0 annual review</a>, June 6, 2023</div> 2200 <div class="spacer"><!-- No abstract --></div> 2201 </div> 2202 2203 <div class="citation"> 2204 <div class="title"><a href="/pub/misc/mi-hb4210-testimony-2023.pdf">Testimony in Opposition to Internet Voting in Michigan</a></div> 2205 <div class="author">J. Alex Halderman</div> 2206 <div class="ref">Written testimony to the <a href="https://www.legislature.mi.gov/Committees/Meeting?meetingID=fc7e896f46444806ab6aefaf6b573128">Michigan House Committee on Elections</a> regarding <a href="https://www.legislature.mi.gov/Bills/Bill?ObjectName=2023-HB-4210">H.B. 4210</a>, May 9, 2023</div> 2207 <div class="spacer"><!-- No abstract --></div> 2208 </div> 2209 2210 <div class="citation"> 2211 <div class="title">
2211<a href="/pub/misc/pde-memorial-2023.pdf">Remembering Peter Eckersley</a></div> 2212 <div class="author">J. Alex Halderman</div> 2213 <div class="ref">Remarks delivered at his <a href="https://ai.objectives.institute/pde-memorial">memorial service</a>, March 4, 2023</div> 2214 <div class="spacer"><!-- No abstract --></div> 2215 </div> 2216 2217 <div class="citation"> 2218 <div class="title"><a href="https://dvsorder.org">The DVSorder Vulnerability</a></div> 2219 <div class="author">Braden Crimmins, Dhanya Narayanan, Josiah Walker, Drew Springall, and J. Alex Halderman</div> 2220 <div class="ref">Oct. 2022</div> 2221 <div class="spacer"><!-- No abstract --></div> 2222 </div> 2223 2224 <div class="citation"> 2225 <div class="title"><a href="https://www.cisa.gov/uscert/ics/advisories/icsa-22-154-01">ICS Advisory: Vulnerabilities Affecting Dominion Voting Systems ImageCast X</a></div> 2226 <div class="author">Findings credited to J. Alex Halderman and Drew Springall</div> 2227 <div class="ref">CISA/ICS-CERT (ICSA-22-154-01), June 3, 2022</div> 2228 <div class="abstract"> 2229 <p>This advisory identifies vulnerabilities affecting versions of the 2230 Dominion Voting Systems Democracy Suite ImageCast X, which is an 2231 in-person voting system used to allow voters to mark their ballot. The 2232 ImageCast X can be configured to allow a voter to produce a paper record 2233 or to record votes electronically. While these vulnerabilities present 2234 risks that should be mitigated as soon as possible, CISA has no evidence 2235 that these vulnerabilities have been exploited in any elections.</p> 2236 <p>Exploitation of these vulnerabilities would require physical access 2237 to individual ImageCast X devices, access to the Election Management 2238 System (EMS), or the ability to modify files before they are uploaded to 2239 ImageCast X devices. Jurisdictions can prevent and/or detect the 2240 exploitation of these vulnerabilities by diligently applying the 2241 mitigations recommended in this advisory, including technical, physical, 2242 and operational controls that limit unauthorized access or manipulation 2243 of voting systems. Many of these mitigations are already typically 2244 standard practice in jurisdictions where these devices are in use and 2245 can be enhanced to further guard against exploitation of these 2246 vulnerabilities.</p> 2247 </div> 2248 </div> 2249 2250 <div class="citation"> 2251 <div class="title"><a href="https://www.newsweek.com/election-security-problems-still-must-addressed-opinion-1632592">Election Security Problems Still Must Be Addressed</a></div> 2252 <div class="author">Susan Greenhalgh and J. Alex Halderman</div> 2253 <div class="ref"><i>Newsweek</i>, September 27, 2021</div> 2254 <div class="spacer"><!-- No abstract --></div> 2255 </div> 2256 2257 <div class="citation"> 2258 <div class="title"><a href="https://storage.courtlistener.com/recap/gov.uscourts.gand.240678/gov.uscourts.gand.240678.1681.0.pdf">Security Analysis of Georgia’s ImageCast X Ballot Marking Devices</a> <span class="altlink">(<a class="external" href="https://freedom-to-tinker.com/2023/06/14/security-analysis-of-the-dominion-imagecast-x/">blog post</a>; <a class="external" href="https://www.cisa.gov/uscert/ics/advisories/icsa-22-154-01">CISA advisory</a>)</span></div> 2259 <div class="author">J. Alex Halderman and Drew Springall</div> 2260 <div class="ref">Expert report submitted on behalf of plaintiffs Donna Curling, et al. in <i>Curling v. Raffensperger</i>, Civil Action No. 1:17-CV-2989-AT, U.S. District Court for the Northern District of Georgia, Atlanta Division, July 1, 2021</div> 2261 <div class="spacer"><!-- No abstract --></div> 2262 </div> 2263 2264 <div class="citation"> 2265 <div class="title"><a href="https://www.michigan.gov/documents/sos/Antrim_720623_7.pdf">Analysis of the Antrim County, Michigan November 2020 Election Incident</a></div> 2266 <div class="author">J. Alex Halderman</div> 2267 <div class="ref">Expert report prepared for the State of Michigan, March 26, 2021</div> 2268 <div class="spacer"><!-- No abstract --></div> 2269 </div> 2270 2271 <div class="citation"> 2272 <div class="title"><a href="https://www.barrons.com/articles/elections-should-be-grounded-in-evidence-not-blind-trust-51609769710">Elections Should be Grounded in Evidence, Not Blind Trust</a></div> 2273 <div class="author">Philip B. Stark, Edward Perez, and J. Alex Halderman</div> 2274 <div class="ref"><i>Barrons</i>, January 4, 2021</div> 2275 <div class="spacer"><!-- No abstract --></div> 2276 </div> 2277 2278 <div class="citation"> 2279 <div class="title"><a href="https://www.michigan.gov/documents/sos/ESAC_Report_Recommendations_706522_7.pdf">Michigan Election Security Advisory Commission Report and Recommendations</a></div> 2280 <div class="author">J. Alex Halderman <i>et al.</i></div> 2281 <div class="ref">Report prepared for the State of Michigan, October 2020</div> 2282 <div class="spacer"><!-- No abstract --></div> 2283 </div> 2284 2285 <div class="citation"> 2286 <div class="title"><a href="https://slate.com/technology/2020/01/internet-voting-could-destroy-our-elections.html">Internet Voting Is Happening Now—And it could destroy our elections</a></div> 2287 <div class="author">Rachel Goodman and J. Alex Halderman</div> 2288 <div class="ref"><i>Slate</i>, January 15, 2020</div> 2289 <div class="spacer"><!-- No abstract --></div> 2290 </div> 2291 2292 <div class="citation"> 2293 <div class="title"><a href="/pub/misc/fsgg-voting-written19.pdf">Congressional Testimony Regarding Federal Funding for Election Cybersecurity</a><span class="altlink">(<a href="/pub/misc/fsgg-voting-written19.pdf">written statement</a>, <a href="/pub/misc/fsgg-voting-oral19.pdf">oral statement</a>, <a href="https://www.youtube.com/watch?v=-6nybiIC-9k">video</a>)</span></div> 2294 <div class="author">J. Alex Halderman</div> 2295 <div class="ref">Testimony before the U.S. House Appropriations Subcommittee on Financial Service and General Government, <a href="https://web.archive.org/web/20210118003255/https://appropriations.house.gov/legislation/hearings/election-security-ensuring-the-integrity-of-us-election-systems">Election Security: Ensuring the Integrity of U.S. Election Systems</a>, February 27, 2019</div> 2296 <div class="spacer"><!-- No abstract --></div> 2297 </div> 2298 2299 <div class="citation"> 2300 <div class="title">
2300<a href="https://www.nytimes.com/2018/04/05/opinion/election-voting-machine-hacking-russians.html">I Hacked an Election. So Can the Russians.</a></div> 2301 <div class="author">J. Alex Halderman</div> 2302 <div class="ref">Video op/ed in collaboration with <i>The New York Times</i>, April 5, 2018</div> 2303 <div class="spacer"><!-- No abstract --></div> 2304 </div> 2305 2306 <div class="citation"> 2307 <div class="title"><a href="/pub/misc/ssci-voting-testimony17.pdf">Congressional Testimony Regarding Russian Interference in the 2016 U.S. Elections</a> <span class="altlink">(<a href="https://www.youtube.com/watch?v=AmivIHUAy8Q#t=2h15m13s">video</a></span>)</div> 2308 <div class="author">J. Alex Halderman</div> 2309 <div class="ref">Testimony before the U.S. Senate Select Committee on Intelligence, June 21, 2017</div> 2310 <div class="spacer"><!-- No abstract --></div> 2311 </div> 2312 2313 <div class="citation"> 2314 <div class="title"><a href="https://www.washingtonpost.com/news/posteverything/wp/2017/06/21/heres-how-to-keep-russian-hackers-from-attacking-the-2018-elections">Here’s How to Keep Russian Hackers from Attacking the 2018 Elections</a></div> 2315 <div class="author">J. Alex Halderman and Justin Talbot-Zorn</div> 2316 <div class="ref"><i>The Washington Post</i>, June 21, 2017</div> 2317 <div class="spacer"><!-- No abstract --></div> 2318 </div> 2319 2320 <div class="citation"> 2321 <div class="title"><a href="/pub/papers/ch7-evoting-attacks-2016.pdf">Practical Attacks on Real-world E-voting</a></div> 2322 <div class="author">J. Alex Halderman</div> 2323 <div class="ref">In Feng Hao and Peter Y. A. Ryan (Eds.), <i>Real-World Electronic Voting: Design, Analysis and Deployment</i>, pages 145–171, CRC Press, December 2016</div> 2324 <div class="spacer"><!-- No abstract --></div> 2325 </div> 2326 2327 <div class="citation"> 2328 <div class="title"><a href="https://medium.com/@jhalderm/want-to-know-if-the-election-was-hacked-look-at-the-ballots-c61a6113b0ba">Want to Know if the Election was Hacked? Look at the Ballots</a></div> 2329 <div class="author">J. Alex Halderman</div> 2330 <div class="ref">Posted on Medium, November 23, 2016. (Read by over a million people.)</div> 2331 <div class="spacer"><!-- No abstract --></div> 2332 </div> 2333 2334 <div class="citation"> 2335 <div class="title"><a href="https://spectrum.ieee.org/tech-talk/telecom/security/the-security-challenges-of-online-voting-have-not-gone-away">The Security Challenges of Online Voting Have Not Gone Away</a></div> 2336 <div class="author">Robert Cunningham, Matthew Bernhard, and J. Alex Halderman</div> 2337 <div class="ref"><i>IEEE Spectrum</i>, November 3, 2016</div> 2338 <div class="spacer"><!-- No abstract --></div> 2339 </div> 2340 2341 <div class="citation"> 2342 <div class="title"><a href="https://www.eecs.umich.edu/techreports/cse/2014/CSE-TR-586-14.pdf">TIVOS: Trusted Visual I/O Paths for Android</a></div> 2343 <div class="author">Earlence Fernandes, Qi Alfred Chen, Georg Essl, J. Alex Halderman, Z. Morley Mao, and Atul Prakash</div> 2344 <div class="ref"><i>University of Michigan Technical Report</i>, May 2014</div> 2345 <div class="abstract"> 2346 <p>Stealthy pixel-perfect attacks on smartphone apps are a class of 2347 phishing attacks that rely on visual deception to trick users into 2348 entering sensitive information into trojan apps. We introduce an 2349 operating system abstraction called Trusted Visual I/O Paths (TIVOs) 2350 that enables a user to securely verify the app she is interacting with, 2351 only assuming that the operating system provides a trusted computing 2352 base. As proof of concept, we built a TIVO for Android, one that is 2353 activated any time a soft keyboard is used by an application (e.g., for 2354 password entry) so that the user can reliably determine the app that 2355 receives the user’s keyboard input. We implemented TIVO by 2356 modifying Android’s user-interface stack and evaluated the 2357 abstraction using a controlled user study where users had to decide 2358 whether to trust the login screen of four different applications that 2359 were randomly subjected to two forms of pixel-perfect attacks. The TIVO 2360 mechanism was found to significantly reduce the effectiveness of 2361 pixel-perfect attacks, with acceptable impact on overall usability and 2362 only modest performance overhead.</p> 2363 </div> 2364 </div> 2365 2366 <div class="citation"> 2367 <div class="title"><a href="https://www.foreignaffairs.com/articles/140214/nadia-heninger-and-j-alex-halderman/tales-from-the-crypto-community">Tales from the Crypto Community: The NSA Hurt Cybersecurity. Now It Should Come Clean</a></div> 2368 <div class="author">Nadia Heninger and J. Alex Halderman</div> 2369 <div class="ref"><i>Foreign Affairs</i>, October 23, 2013</div> 2370 <div class="abstract"> 2371 <p>Of all of the revelations about the NSA that have come to light in 2372 recent months, two stand out as the most worrisome and surprising to 2373 cybersecurity experts. The first is that the NSA has worked to weaken 2374 the international cryptographic standards that define how computers 2375 secure communications and data. The second is that the NSA has 2376 deliberately introduced backdoors into security-critical software and 2377 hardware. If the NSA has indeed engaged in such activities, it has 2378 risked the computer security of the United States (and the world) as 2379 much as any malicious attacks have to date.</p> 2380 </div> 2381 </div> 2382 2383 <div class="citation"> 2384 <div class="title"><a href="https://ieeexplore.ieee.org/document/5439535">To Strengthen Security, Change Developers’ Incentives</a></div> 2385 <div class="author">J. Alex Halderman</div> 2386 <div class="ref"><i>IEEE Security and Privacy</i>, March/April 2010</div> 2387 <div class="abstract"> 2388 <p>Many common software vulnerabilities are avoidable if software makers 2389 apply appropriate care, yet developers’ incentives often lead them 2390 to underinvest in security. Profit-maximizing developers invest to the 2391 extent that strengthening security increases sales or reduces their 2392 liability, yet these incentives are undermined by the softw
2392are 2393 market’s structure. By understanding and reshaping such 2394 incentives, we can greatly improve security at comparably low cost. The 2395 author argues for requiring increased transparency about security 2396 problems and development practices, which will help software buyers make 2397 better-informed purchases, and for holding developers liable for the 2398 costs of security failures caused by their products.</p> 2399 </div> 2400 </div> 2401 2402 <div class="citation"> 2403 <div class="title"><a href="/pub/gd/">Analysis of the Green Dam Censorware System</a></div> 2404 <div class="author">Scott Wolchok, Randy Yao, and J. Alex Halderman</div> 2405 <div class="ref"><i>University of Michigan Technical Report</i>, June 11, 2009</div> 2406 <div class="abstract"> 2407 <p>We have discovered remotely-exploitable vulnerabilities in Green Dam, 2408 the censorship software reportedly mandated by the Chinese government. 2409 Any web site a Green Dam user visits can take control of the PC. 2410 According to press reports, China will soon require all PCs sold in the 2411 country to include Green Dam. This software monitors web sites visited 2412 and other activity on the computer and blocks adult content as well as 2413 politically sensitive material. We examined the Green Dam software and 2414 found that it contains serious security vulnerabilities due to 2415 programming errors. Once Green Dam is installed, any web site the user 2416 visits can exploit these problems to take control of the computer. This 2417 could allow malicious sites to steal private data, send spam, or enlist 2418 the computer in a botnet. In addition, we found vulnerabilities in the 2419 way Green Dam processes blacklist updates that could allow the software 2420 makers or others to install malicious code during the update process. We 2421 found these problems with less than 12 hours of testing, and we believe 2422 they may be only the tip of the iceberg. Green Dam makes frequent use of 2423 unsafe and outdated programming practices that likely introduce numerous 2424 other vulnerabilities. Correcting these problems will require extensive 2425 changes to the software and careful retesting. In the meantime, we 2426 recommend that users protect themselves by uninstalling Green Dam 2427 immediately.</p> 2428 </div> 2429 </div> 2430 2431 <div class="citation"> 2432 <div class="title"><a href="/pub/papers/avc-tr08.pdf">AVC Advantage: Hardware Functional Specifications</a></div> 2433 <div class="author">J. Alex Halderman and Ariel J. Feldman</div> 2434 <div class="ref"><i>Princeton University Computer Science Technical Report TR-816-08</i>, March 8, 2008</div> 2435 <div class="abstract"> 2436 <p>This report describes the hardware design of the AVC Advantage 2437 direct-recording electronic (DRE) voting machine. We developed these 2438 functional specifications by reverse engineering a government-surplus 2439 system.</p> 2440 </div> 2441 </div> 2442 2443 <div class="citation"> 2444 <div class="title"><a href="/pub/papers/diebold-ttbr07.pdf">Source Code Review of the Diebold Voting System</a></div> 2445 <div class="author">Joseph A. Calandrino, Ariel J. Feldman, J. Alex Halderman, David Wagner, Harlan Yu, and William Zeller</div> 2446 <div class="ref">Part of the California Secretary of State’s <a href="https://www.sos.ca.gov/elections/ovsta/frequently-requested-information/top-bottom-review">“Top-to-Bottom” Voting Systems Review</a>, July 2007</div> 2447 <div class="spacer"><!-- No abstract --></div> 2448 </div> 2449 2450 <div class="citation"> 2451 <div class="title"><a href="/pub/papers/drm-sp06.pdf">Digital Rights Management, Spyware, and Security</a></div> 2452 <div class="author">Edward W. Felten and J. Alex Halderman</div> 2453 <div class="ref"><i>IEEE Security and Privacy</i>, January/February 2006</div> 2454 <div class="spacer"><!-- No abstract --></div> 2455 </div> 2456 2457 <div class="citation"> 2458 <div class="title"><a href="/pub/cd3/">Analysis of the MediaMax CD3 Copy-Prevention System</a></div> 2459 <div class="author">J. Alex Halderman</div> 2460 <div class="ref"><i>Princeton University Computer Science Technical Report TR-679-03</i>, October 2003</div> 2461 <div class="abstract"> 2462 <p>
2462MediaMax CD3 is a new copy-prevention technique from SunnComm 2463 Technologies that is designed to prevent unauthorized copying of audio 2464 CDs using personal computers. SunnComm claims its product facilitates 2465 “a verifiable and commendable level of security,” but in 2466 tests on a newly-released album, I find that the protections may have no 2467 effect on a large fraction of deployed PCs, and that most users who 2468 would be affected can bypass the system entirely by holding the shift 2469 key every time they insert the CD. I explain that MediaMax interferes 2470 with audio copying by installing a device driver the first time software 2471 from the CD is executed, but I show that this provides only minimal 2472 protection because the driver can easily be disabled. I also examine the 2473 digital rights management system used to control access to a set of 2474 encrypted, compressed audio files distributed on the CD. Although 2475 restrictions on these files are more relaxed than in prior copy 2476 protected discs, they still prohibit many uses permitted by the law. I 2477 conclude that MediaMax and similar copy-prevention systems are 2478 irreparably flawed but predict that record companies will find success 2479 with more customer-friendly alternatives for reducing infringement.</p> 2480 </div> 2481 </div> 2482 </div> 2483 2484</body> 2485</html>
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.