<?xml version="1.0" encoding="iso-8859-1" ?>
<rss version="2.0">

<channel>

<title>Matt Blaze's Exhaustive Search</title>
<link>http://www.crypto.com/blog</link>
<description>Science, Security, Curiosity</description>
<language>en-us</language>
<docs>http://blogs.law.harvard.edu/tech/rss</docs>
<generator>First Person</generator>
<managingEditor>mab@crypto.com</managingEditor>
<webMaster>mab@crypto.com</webMaster>
<item>
   <title>Safecracking at the NSA</title>
   <link>http://www.crypto.com/blog/nsa_safecracking/</link>
   <guid>http://www.crypto.com/blog/nsa_safecracking/</guid>
   <pubDate>Wed, 30 Apr 2008 19:08:24 +0000</pubDate>
   <description>Are you a Stooge, a Dimwit, or a Savant?




	
&lt;p&gt;
&lt;img style=&quot;margin: 10px 0px 10px 13px&quot; src=&quot;http://www.crypto.com/photos/misc/safe600.jpg&quot; alt=&quot;safe lock&quot; align=&quot;right&quot;&gt;
When I published &lt;a href=&quot;http://www.crypto.com/papers/safelocks.pdf&quot;&gt;&lt;em&gt;Safecracking for the Computer Scientist&lt;/em&gt; [pdf]&lt;/a&gt; a few years ago,
I worried that I might be alone in harboring
a serious interest in the cryptologic aspects of physical security.
Yesterday I was delighted to discover that I had been wrong.  It turns out that more than
ten years before I wrote up my safecracking survey, a detailed
analysis of the keyspaces of mechanical safe locks had already been
written, suggesting a simple and practical dictionary attack of which I was completely
unaware.  But I have an excuse for my ignorance: the study was published
in secret, in &lt;em&gt;Cryptologic Quarterly&lt;/em&gt;, a classified technical
journal of the US National Security Agency.
&lt;p&gt;
This month the NSA quietly declassified a number of &lt;a href=&quot;http://www.nsa.gov/public/cryptologicquarterly.cfm&quot;&gt;internal technical and historical documents from the 1980's and 1990's&lt;/a&gt; (this latest batch includes more recent material than the previously-released 1970's papers I mentioned in &lt;a href=&quot;http://www.crypto.com/blog/hardware_security&quot;&gt;last weekend's post here&lt;/a&gt;).  Among the newly-released papers was &lt;a href=&quot;http://www.nsa.gov/public/tele_codes.pdf&quot;&gt;&lt;em&gt;Telephone Codes and Safe Combinations: A Deadly Duo&lt;/em&gt; [pdf]&lt;/a&gt; from Spring 1993, with the author names and more than half of the content still classified and redacted.
&lt;p&gt;
Reading between the redacted sections, it's not too hard to piece together the main ideas of the paper.  First, they observe, as I had, that while a typical three wheel safe lock appears to allow 1,000,000 different combinations, mechanical imperfections coupled with narrow rules for selecting &quot;good&quot; combinations makes the effective usable keyspace smaller than this by more than an order of magnitude.  They put the number at 38,720 for the locks used by the government (this is within the range of 22,330 to 111,139 that I estimated in my &lt;em&gt;Safecracking&lt;/em&gt; paper).
&lt;p&gt;
38,720 is a lot less than 1,000,000, but it probably still leaves safes outside the reach of manual exhaustive search.  However, as the anonymous* [see note below] NSA authors point out, an attacker may be able to do considerably better than this by exploiting the mnemonic devices users sometimes employ when selecting combinations.  Random numeric combinations are hard to remember.  So user-selected combinations are often less than completely random.  In particular (or at least I infer from the title and some speculation about the redacted sections), many safe users take advantage of the standard telephone keypad encoding (e.g., A, B, and C encode to &quot;2&quot;, and so on) to derive their numeric combinations from (more easily remembered) six letter words.  The word &quot;SECRET&quot; would thus correspond to a combination of 73-27-38.
&lt;p&gt;
This &quot;clever&quot; key selection scheme, of course, greatly aids the attacker, reducing the keyspace of probable combinations (after &quot;bad&quot; combinations are removed) to only a few hundred, even when a large dictionary is used. The paper further pruned the keyspaces for targets of varying vocabularies, proposing a &quot;stooge&quot; list of 176 common words, a &quot;dimwit&quot; list of 166 slightly less common words, and a &quot;savant&quot; list of 244 more esoteric words.
It would take less than two hours to try all of these combinations by hand, and less than two minutes with the aid of a &lt;a href=&quot;http://web.mit.edu/kvogt/www/safecracker.html&quot;&gt;mechanical autodialer&lt;/a&gt;; on average, we'd expect to succeed in half that time.
&lt;p&gt;
Dictionary attacks aren't new, of course, but I've never heard of them being applied to safes before (outside of the folk wisdom to &quot;try birthdays&quot;, etc).  Certainly the net result is impressive -- the technique is much more efficient than exhaustive search, and it works even against &quot;manipulation resistant&quot; locks.  Particularly notable is how two only moderately misguided ideas -- the use of words as key material plus overly restrictive (and yet widely followed) rules for selecting &quot;good&quot; combinations -- combine to create a single terrible idea that cedes enormous advantage to the attacker.
&lt;p&gt;
Although the paper is heavily censored, I was able to reconstruct most of the missing details without much difficulty.  In particular, I spent an hour with an online dictionary and some simple scripts to create a list of 1757 likely six-digit word-based combinations, which is available at &lt;a href=&quot;http://www.crypto.com/papers/cc-5.txt&quot;&gt;&lt;tt&gt;
www.crypto.com/papers/cc-5.txt&lt;/tt&gt;&lt;/a&gt; .  &lt;em&gt;(Addendum:&lt;/em&gt; A shorter list of 518 combinations based on the more restrictive combination selection guidelines apparently used by NSA can be found at &lt;a href=&quot;http://www.crypto.com/papers/cc-15.txt&quot;&gt;&lt;tt&gt;www.crypto.com/papers/cc-15.txt&lt;/tt&gt;&lt;/a&gt; ). If you have a safe, you might want to check to see if your combination is listed.
&lt;p&gt;
As gratifying as it was to discover kindred sprits in the classified world, I found the recently released papers especially interesting for what they reveal about the NSA's research culture.  The papers reflect curiosity and intellect not just within the relatively narrow crafts of cryptology and SIGINT, but across the broader context in which they operate.  There's a wry humor throughout many of the documents, much like what I remember pervading the old Bell Labs (the authors of the safe paper, for example, propose that they be given a cash award for efficiency gains arising from their discovery of an optimal safe combination, which they suggest everyone in the government adopt).
&lt;p&gt;
It must be a fun place to work.
&lt;p&gt;
&lt;p&gt;
&lt;em&gt;Postscript (7-May-2008):&lt;/em&gt;  Several people asked what makes the combinations proposed in the appendix of the NSA paper &quot;optimal&quot;.  The paper identifies 46-16-31 as the legal combination with the shortest total dialing distance, requiring moving the dial a total of 376 graduations.  (Their calculation starts after the entry of the first number and includes returning the dial to zero for opening.)  However, this appears to assume an unusual requirement that individual numbers be at least fifteen graduations apart from one another, which is more restrictive than the five (or sometimes ten) graduation minimum recommended by lock vendors. Apparently the official (but redacted) NSA rules for safe combinations are more restrictive than mechanically necessary.  If so, the NSA has been using safe combinations selected from a much smaller than needed keyspace.  In any case, under the NSA rule the fastest legal word-based combination indeed seems to be 52-22-37, which is derived from the word &lt;span class=&quot;censored&quot;&gt;&quot;JABBER&quot;&lt;/span&gt;, although &lt;span class=&quot;censored&quot;&gt;this was, for some reason, redacted from the released paper&lt;/span&gt;.  However, I found an even faster word-based combination that's legal under the conventional rules: 37-22-27, derived from the word &quot;FRACAS&quot;.  It requires a total dial movement of only 347 graduations.
&lt;br/&gt;
&lt;br/&gt;
&lt;p&gt;
* &lt;em&gt;Well, somewhat anonymous.  Although the authors' names are redacted in the released document, the paper's position in a previously released and partially redacted alphabetical index &lt;a href=&quot;http://www.thememoryhole.org/nsa/nsa_cq_1982-96.pdf&quot;&gt;[pdf]&lt;/a&gt; suggests that one of their names lies between Campaigne and Farley and the other's between Vanderpool and Wiley.&lt;/em&gt;</description>
</item>
<item>
   <title>What lies beneath?</title>
   <link>http://www.crypto.com/blog/hardware_security/</link>
   <guid>http://www.crypto.com/blog/hardware_security/</guid>
   <pubDate>Sun, 27 Apr 2008 21:01:38 +0000</pubDate>
   <description>From the turtles-all-the-way-down department.




	
&lt;p&gt;
Computer security depends ultimately on the security of the computer -- it's an indisputable tautology so self-evident that it seems almost insulting to point it out.  Yet what may be obvious in the abstract is sometimes dangerously under-appreciated in practice.  Security people come predominantly from software-centric backgrounds and we're often predisposed to relentlessly scrutinize the things we understand best while quietly assuming away everything else.  But attackers, sadly, are under no obligation to play to our analytical preferences.  Several recent research results make an eloquent and persuasive case that a much broader view of security is needed.  A bit of simple hardware trickery, we're now reminded, can subvert a system right out from under even the most carefully vetted and protected software.
&lt;p&gt;
Earlier this year, Princeton graduate student Alex Halderman and seven of his colleagues discovered &lt;a href=&quot;http://citp.princeton.edu/memory/&quot;&gt;practical
techniques for extracting the contents of DRAM memory, including cryptographic keys, after a computer has been turned off [link]&lt;/a&gt;.  This means, among other worries, that if someone -- be it a casual thief or a foreign intelligence agent --  snatches your laptop, the fact that it had been &quot;safely&quot; powered down may be insufficient to protect your passwords and disk encryption keys.  And the techniques are simple and non-destructive, involving little more than access to the memory chips and some canned-air coolant.
&lt;p&gt;
If that's not enough, this month at the USENIX workshop on Large-Scale Exploits and Emergent Threats, Samuel T. King and five colleagues at the University of Illinois Urbana-Champaign described a &lt;a href=&quot;http://www.usenix.org/event/leet08/tech/full_papers/king/king_html/&quot;&gt;remarkably efficient approach to adding hardware backdoors to general-purpose computers&lt;/a&gt; &lt;a href=&quot;http://www.usenix.org/event/leet08/tech/full_papers/king/king.pdf&quot;&gt;[pdf]&lt;/a&gt;.  Slipping a small amount of malicious circuitry (just a few thousand extra gates) into a CPU's design is sufficient to enable a wide range of remote attacks that can't be detected or prevented by conventional software security approaches.  To carry out such attacks requires the ability to subvert computers wholesale as they are built or assembled.  &quot;Supply chain&quot; threats thus operate on a different scale than we're used to thinking about -- more in the realm of governments and organized crime than lone malfeasants -- but the potential effects can be absolutely devastating under the right conditions.
&lt;p&gt;
And don't forget about your keyboard.  At USENIX Security 2006, Gaurav Shah, Andres Molina and I introduced &lt;a href=&quot;http://www.crypto.com/papers/jbug-Usenix06-final.pdf&quot;&gt;&lt;em&gt;JitterBug&lt;/em&gt; attacks [pdf]&lt;/a&gt;, in which a subverted keyboard can leak captured passwords and other secrets over the network through a completely uncompromised host computer, via simple covert timing channel.
The usual countermeasures against keyboard sniffers -- virus scanners, network encryption, and so on -- don't help here.  JitterBug attacks are potentially viable not only at the retail level (via a surreptitious &quot;bump&quot; in the keyboard cable), but also wholesale (by subverting the supply chain or through viruses that modify keyboard firmware). 
&lt;p&gt;
Should you actually be worried?  These attacks probably don't threaten all, or even most, users, but the risk that they might be carried out against any particular target isn't really the main concern here.  The larger issue is that they succeed by undermining our assumptions about what we can trust.  They work because our attention is focused elsewhere.
&lt;p&gt;
An encouraging (if rare) sign of progress in Internet security over the last decade has been the collective realization that even when we can't figure out how to exploit a vulnerability, someone else eventually might.
Thankfully, it's now become (mostly) accepted practice to fix newly discovered software weaknesses even if we haven't yet worked out all the details of how to use them to conduct attacks.  We know from hard experience that when &quot;theoretical&quot; vulnerabilities are left open long enough, the bad guys eventually figure out how to make them all too practical.
&lt;p&gt;
But there's a different attitude, for whatever reason, toward the underlying hardware.  Even the most paranoid among us often take the integrity of computer hardware as an article of faith, something not to be seriously questioned.  A common response to hardware security research is bemused puzzlement at how us overpaid academics waste our time on such impractical nonsense when there are so many real problems we could be solving instead.  (Search the comments on Slashdot and other message boards about the papers cited above for examples of this reaction.)
&lt;p&gt;
Part of the disconnect may be because hardware threats are so unpleasant to
think about from the software perspective; there doesn't seem to be much we can do about them except to hope that they won't affect us.  Until, of course, they eventually do.
&lt;p&gt;
Reluctance to acknowledge new kinds of threats is nothing new, and it isn't limited to causal users.  Even the military is susceptible.  For example, &lt;em&gt;Tempest&lt;/em&gt; attacks against cryptographic processors, in which sensitive data radiates out via spurious RF and other emanations, were first discovered by Bell Labs engineers in 1943.  They noticed signals that correlated with the plain text of encrypted teletype messages coming from a certain piece of crypto hardware.  According to &lt;a href=&quot;http://www.nsa.gov/public/pdf/tempest.pdf&quot;&gt;a recently declassified NSA paper on Tempest [pdf]&lt;/a&gt;:
&lt;blockquote&gt;
Bell Telephone faced a dilemma.  They had sold the equipment to the military with the assurance that it was secure, but it wasn't.  The only thing they could do was to tell the Signal Corps about it, which they did.  There they met the charter members of a club of skeptics who could not believe that these tiny pips could really be exploited under practical field conditions.  They are alleged to have said something like: &quot;Don't you realize there's a war on?  We can't bring our cryptographic operations to a screeching halt based on a dubious and esoteric laboratory phenomenon.  If this is really dangerous, prove it.&quot;
&lt;/blockquote&gt;
Some things never change.  Fortunately, the Bell Labs engineers quickly set up a persuasive demonstration, and so the military was ultimately convinced to develop countermeasures.  That time, they were able to work out the details before the enemy did.
&lt;p&gt;
&lt;p&gt;
&lt;em&gt;Thanks to Steve Bellovin for pointing me to &lt;a href=&quot;http://www.nsa.gov/public/crypt_spectrum.cfm&quot;&gt;&lt;tt&gt;www.nsa.gov/public/crypt_spectrum.cfm&lt;/tt&gt;&lt;/a&gt;, a small trove of declassified NSA technical papers from the 1970's and 1980's, all of which are well worth reading.  And no discussion of underlying security would be complete without a reference to Ken Thompson's famous Turing award lecture, &lt;a href=&quot;http://cm.bell-labs.com/who/ken/trust.html&quot;&gt;Reflections on Trusting Trust&lt;/a&gt;.
&lt;/em&gt;</description>
</item>
<item>
   <title>Wiretapping the RSA Conference</title>
   <link>http://www.crypto.com/blog/rsa_extravaganza/</link>
   <guid>http://www.crypto.com/blog/rsa_extravaganza/</guid>
   <pubDate>Wed, 16 Apr 2008 01:28:42 +0000</pubDate>
   <description>I'm ready for my close-up now, Mr. Bizdos.




	
&lt;p&gt;
I was part of a panel on warrantless wiretapping at last week's
&lt;a href=&quot;http://www.rsaconference.com&quot;&gt;RSA Conference&lt;/a&gt; in San Francisco.
The keynote session, which was moderated by the NY Times' Eric Lichtblau and which included former NSA official Bill Crowell, CDT's Jim Dempsey, attorney
David Rivken, and me, focused on the role of the judiciary in
national security wiretaps.    Ryan Singel covered the proceedings in
a brief piece on
&lt;a href=&quot;http://blog.wired.com/27bstroke6/2008/04/wiretapping-pow.html&quot;&gt;Wired's Threat Level blog&lt;/a&gt;.
&lt;p&gt;
There's a tendency to view warrantless wiretaps in strictly legal or political terms and to assume that the interception technology will correctly implement whatever the policy is supposed to be.  But the reality isn't so simple.   I found myself the sole techie on the RSA panel, so my role was largely to to point out that this is as much an issue of engineering as it is legal oversight.  And while we don't know all the details about how NSA's wiretaps are being carried out in the US, what we do know suggests some disturbing architectural choices that make the program especially vulnerable to over-collection and abuse.  In particular, assuming &lt;a href=&quot;http://www.eff.org/cases/att&quot;&gt;Mark Klein's AT&amp;amp;T documents&lt;/a&gt; are accurate, the NSA infrastructure seems much farther inside the US telecom infrastructure than would be appropriate for intercepting the exclusively international traffic that the government says it wants.  The taps are apparently in domestic backbone switches rather than, say, in cable heads that leave the country, where international traffic is most concentrated (and segregated).  Compounding the inherent risks of this odd design is the fact that
the equipment that pans for nuggets of international communication in the stream of (off-limits) domestic traffic is apparently made up entirely of hardware provided and configured by the government, rather than the carriers.   It's essentially equivalent to giving the NSA the keys to the phone company central office and hoping that they figure out which wires are the right ones to tap.
&lt;p&gt;
Technical details matter here.  A recent paper I published with some colleagues goes into more depth about some of these issues; see &lt;a href=&quot;http://www.crypto.com/blog/wiretap_risks&quot;&gt;a previous blog entry (linked here) about our paper&lt;/a&gt;.
&lt;p&gt;
The RSA conference itself is quite the extravaganza of commerce and technology, about as far as I care to venture from the lower-budget academic and research gatherings that comprise my natural habitat.  There were something like 18,000 attendees at RSA last week, many willingly paying upwards of $2000 for the privilege.  The scale is just staggeringly huge, with a level of overproduction and polish more typically associated with a Hollywood movie, or maybe a Rolling Stones concert.  Some of the speakers had private dressing rooms backstage.  (I didn't have one to myself, but they did lay out a nice cheese spread for us in the green room.)  They made us stop at the makeup trailer before they let us on stage (I'm mildly allergic, it turns out).
&lt;p&gt;
If there's a silver lining under all this bling it's that digital security is unquestionably considered serious business these days.  Now we just have to figure out the technical part.</description>
</item>
<item>
   <title>USENIX to make all its conference proceedings freely available</title>
   <link>http://www.crypto.com/blog/free_usenix/</link>
   <guid>http://www.crypto.com/blog/free_usenix/</guid>
   <pubDate>Thu, 13 Mar 2008 09:40:56 +0000</pubDate>
   <description>Free, as in software.




	
&lt;p&gt;
I'm delighted to report that &lt;a href=&quot;http://www.usenix.org/&quot;&gt;USENIX&lt;/a&gt;,
probably the most important technical society at which I publish (and on whose board I serve), has taken a long-overdue lead toward openly disseminating scientific research.  Effective immediately, &lt;a href=&quot;http://www.usenix.org/publications/library/proceedings/&quot;&gt;all USENIX proceedings and papers will be freely available on the USENIX web site as soon as they are published [link]&lt;/a&gt;.  (Previously, most of the organization's proceedings required a member login for access for the first year after their publication.)
&lt;p&gt;
For years, many authors have made their papers available on their own web sites, but the practice is haphazard, non-archivial, and, remarkably, actively discouraged by the restrictive copyright policies of many journals and conferences.  So USENIX's step is important both substantively and symbolically.   It reinforces why scientific papers are published in the first place: not as proprietary revenue sources, but to advance the state of the art for the benefit of society as a whole.
&lt;p&gt;
Unfortunately, other major technical societies that sponsor conferences and journals still cling to the antiquated notion, rooted in a rapidly-disappearing print-based publishing economy, that they naturally &quot;own&quot; the writings that volunteer authors, editors and reviewers produce.   These organizations, which insist on copyright control as a condition of publication, argue that the sale of conference proceedings and journal subscriptions provides an essential revenue stream that subsidizes their other good works.  But this income, however well it might be used, has evolved into an ill-gotten windfall.   We write scientific papers first and last because we want them read.  When papers were actually printed on paper it might have been reasonable to expect authors to donate the copyright in exchange for production and distribution.  Today, of course, such a model seems, at best, quaintly out of touch with the needs of researchers and academics who can no longer tolerate the delay or expense of seeking out printed copies of far-flung documents they expect to find on the web. 
&lt;p&gt;
Organizations devoted to computing research should recognize this not-so-new reality better than anyone.  It's time for &lt;a href=&quot;http://www.acm.org/&quot;&gt;ACM&lt;/a&gt; and &lt;a href=&quot;http://www.ieee.org/&quot;&gt;IEEE&lt;/a&gt; to follow USENIX's leadership in making scientific papers freely available to all comers.  Please join me in urging them to do so.</description>
</item>
<item>
   <title>Encrypting history at the NSA</title>
   <link>http://www.crypto.com/blog/mcconnell_clipper/</link>
   <guid>http://www.crypto.com/blog/mcconnell_clipper/</guid>
   <pubDate>Thu, 28 Feb 2008 02:54:07 +0000</pubDate>
   <description>18 20 13 3 8  26 14 24 20  14 23 1 16 17 13 3 5.




	
&lt;p&gt;
&lt;a href=&quot;http://www.flickr.com/photos/21746901@N08/sets/72157603948664464/&quot;&gt;&lt;img style=&quot;margin: 10px 0px 10px 13px&quot; src=&quot;http://www.crypto.com/photos/blog/clipper350.jpg&quot; alt=&quot;MYK-78T Clipper chip&quot; align=&quot;right&quot;&gt;&lt;/a&gt;
In the month since its publication, Lawrence Wright's &lt;a href=&quot;http://www.newyorker.com/reporting/2008/01/21/080121fa_fact_wright?printable=true&quot;&gt;&lt;em&gt; New Yorker&lt;/em&gt; profile of National Intelligence Director Mike McConnell&lt;/a&gt; has been widely picked apart for morsels of insight into the current administration's attitudes on the finer points of interrogation, wiretaps and privacy.  I was just re-reading the piece, and, questions of waterboarding and torture aside, I was struck by this unchallenged retelling of the recent history of US cryptography regulation:
&lt;blockquote&gt;
In the nineties, new encryption software that could protect telephone conversations, faxes, and e-mails from unwarranted monitoring was coming on the market, but the programs could also block entirely legal efforts to eavesdrop on criminals or potential terrorists. Under McConnell's direction, the N.S.A. developed a sophisticated device, the Clipper Chip, with a superior ability to encrypt any electronic transmission; it also allowed law-enforcement officials, given the proper authority, to decipher and eavesdrop on the encrypted communications of others. Privacy advocates criticized the device, though, and the Clipper was abandoned by 1996.  &quot;They convinced the folks on the Hill that they couldn't trust the government to do what it said it was going to do,&quot; Richard Wilhelm, who was in charge of information warfare under McConnell, says.
&lt;/blockquote&gt;
&lt;p&gt;
But that's not actually what happened.  In fact, almost everything about this quote -- the whos, the whys and the whens -- is not merely slanted in its interpretation, but factually contradicted by the public record.
&lt;p&gt;
First, the Clipper Chip itself was abandoned not because of concerns about privacy (although it certainly became a lightning rod for criticism on that front), but rather because it was found to have serious technical vulnerabilities that had escaped the NSA's internal review process and that rendered the system ineffective for its intended purpose.  I discovered and published in the open literature the first of these flaws at the ACM CCS conference in 1994, about a year after Clipper's introduction.  (Technically inclined readers can see &lt;a href=&quot;http://www.crypto.com/papers/eesproto.pdf&quot;&gt;&lt;em&gt;Protocol Failure in the Escrowed Encryption Standard&lt;/em&gt; [pdf link]&lt;/a&gt; for details.)
&lt;p&gt;
More generally, while Congress (presumably the Hill on which the folks referred to above resided) held several hearings on the subject, it never actually enacted (or even voted on) any cryptography legislation during the 1990's.  Instead, the relaxation of cryptography export regulations (the lever through which the government controlled US encryption software and hardware) was entirely a product of the executive branch.  Department of Commerce export regulations that took effect at the beginning of 2000 effectively eliminated the major controls on mass-market and open source encryption products, and in 2004 &lt;a href=&quot;http://www.bis.doc.gov/encryption/default.htm&quot;&gt;the rules were relaxed even further&lt;/a&gt;.  In other words, the current policy promoting widely available encryption has been actively supported not just by the previous administration, but by the present one as well.
&lt;p&gt;
Government attempts in the 1990's to control cryptography were ultimately doomed not by some kind of weak-kneed policy capitulation (even if some in the national security community might now find it convenient to portray it as such), but by inexorable advances in technology (particularly what &lt;a href=&quot;http://codev2.cc/&quot;&gt;Larry Lessig calls &quot;west coast code&quot;&lt;/a&gt;).
Even before the hardware-only Clipper program was announced, the performance of software-based encryption on general purpose computers had become competitive with that of expensive purpose-built encryption chips.  At the same time, growth in the largely open-source-based networked computing world increasingly depended on reliable and inexpensive communications security,  something fundamentally incompatible with the key escrow scheme underlying Clipper.  Coupled with the inherent risk that a central encryption key database would itself become a target for foreign intelligence agents, it became apparent to just about everyone by the end of the decade that decontrol was the only viable policy option.
&lt;p&gt;
Tellingly, even after the attacks of September 11th, 2001 the Bush administration made no serious attempt to control or otherwise reign in the public availability or use of strong encryption.  Indeed, its only action on cryptography policy came in 2004, &lt;a href=&quot;http://www.bis.doc.gov/encryption/default.htm&quot;&gt;when it further liberalized the few remaining export controls on the technology&lt;/a&gt;.
&lt;p&gt;
It's unfortunate that the &lt;em&gt;New Yorker&lt;/em&gt; failed to check the facts about Clipper, but that's not the central concern here.  Intelligence agencies (and their officials) largely operate under a thick veil of legally enforced secrecy,  carrying with it a special obligation to be scrupulously truthful in their analysis.  Should we trust them to be more forthright than the former official quoted in the excerpt when the facts are not so easily checked?  We often have no choice.
&lt;p&gt;
When I published my Clipper paper in 1994, the NSA -- to its great credit at the time -- immediately acknowledged the problems, despite the embarrassment the whole affair no doubt caused them.  And that is precisely how we must expect our intelligence agencies to behave.  Intelligence spun to serve a political narrative isn't intelligence, it's just politics.
&lt;p&gt;
&lt;em&gt;Photo above: Mykotronx MYK-78T Clipper Chip, as installed in an AT&amp;amp;T TSD-3600E encrypting telephone.  More Clipper photos &lt;a href=&quot;http://www.flickr.com/photos/21746901@N08/sets/72157603948664464/&quot;&gt;&lt;u&gt;here&lt;/u&gt;&lt;/a&gt;.&lt;/em&gt;</description>
</item>
<item>
   <title>E-Voting talk at Penn Thursday 2/14/08</title>
   <link>http://www.crypto.com/blog/penn_voting_talk/</link>
   <guid>http://www.crypto.com/blog/penn_voting_talk/</guid>
   <pubDate>Thu, 14 Feb 2008 00:58:05 +0000</pubDate>
   <description>The perfect Valentine's day activity




	
&lt;p&gt;I'll be giving a talk tomorrow (Thursday 14 February) about the review of electronic voting systems we conducted last fall here at U. Penn.  For those in the Philadelphia area, the talk is on the Penn Campus in the Levine Hall Auditorium from
3:00-4:15pm.   Sorry for not getting this up on the blog earlier.&lt;p&gt;
&lt;a href=&quot;http://www.crypto.com/blog/penn_voting_talk/&quot;&gt;See the rest of this entry for the talk announcement...&lt;/a&gt;</description>
</item>
<item>
   <title>Warrantless wiretaps, redux</title>
   <link>http://www.crypto.com/blog/wiretap_risks/</link>
   <guid>http://www.crypto.com/blog/wiretap_risks/</guid>
   <pubDate>Thu, 24 Jan 2008 06:06:41 +0000</pubDate>
   <description>They've got computers. They're tapping phone lines.  They know that may be allowed.




	
&lt;p&gt;
&lt;img style=&quot;margin: 10px 0px 10px 13px&quot; src=&quot;http://www.crypto.com/photos/blog/secrecy500.jpg&quot; alt=&quot;Bell System Secrecy of Communications poster&quot; align=&quot;right&quot;&gt;
A recurring theme in this blog
over the last year
has been how the sweeping surveillance technology envisioned by
the 2007 US &lt;em&gt;Protect America Act&lt;/em&gt; introduces fundamental technical
vulnerabilities into the nation's communications infrastructure.
These risks should worry law enforcement and the national security
community at least as much as they worry civil liberties advocates.  &lt;a href=&quot;http://www.crypto.com/blog/comsec_hazards&quot;&gt;A post last October&lt;/a&gt; mentioned an
analysis that I was writing with Steve Bellovin,
Whit Diffie, Susan Landau, Peter Neumann and Jennifer Rexford.
&lt;p&gt;
The final version of our paper, &quot;Risking Communications Security: Potential Hazards of the Protect America Act,&quot; will be published in the January/February 2008 issue of &lt;em&gt;IEEE Security and Privacy&lt;/em&gt;, which hits the stands in a few weeks.  But you can download a preprint of our article today at
&lt;a href=&quot;http://www.crypto.com/papers/paa-ieee.pdf&quot;&gt;
&lt;tt&gt;http://www.crypto.com/papers/paa-ieee.pdf&lt;/tt&gt; [PDF]&lt;/a&gt;.  Remember, you saw it here first.
&lt;p&gt;
This week the Senate takes up whether to make the warrantless wiretapping
act permanent, so the subject is extremely timely.  The technical
risks created by unsupervised
wiretapping on this scale are enormously serious (and reason enough
to urge Congress to let this misguided law expire).  But safety and
security may be
subordinated in the debate to more entrenched interests.  In particular,
AT&amp;amp;T and other communications carriers have been lobbying hard for an
amendment that gives them retroactive immunity from any
liability they might have had for turning over Americans' communications
and call records to the government, legally or not, before the act passed.
&lt;p&gt;
As someone who began his professional career in the Bell System (and who stayed
around through several of its successors),
the push for telco immunity represents an especially bitter disillusionment
for me.
Say what you will about the old Phone Company,
but respect for customer privacy was once a deeply rooted point of pride in the
corporate ethos.
There was no faster way to be fired (or worse) than to snoop into call records
or facilitate illegal wiretaps, well intentioned or not.  And it was genuinely
part of the culture; we believed in
it, even those of us ordinarily disposed toward a skeptical view of the
official company line.  Now it all seems like just another bit of
cynical, focus-group-tested PR.
&lt;p&gt;
&lt;p&gt;
&lt;em&gt;Apologies to
&lt;a href=&quot;http://journal.davidbyrne.com/&quot;&gt;&lt;u&gt;David Byrne&lt;/u&gt;&lt;/a&gt; for
paraphrasing his hauntingly prescient
&lt;a href=&quot;http://www.talking-heads.net/lyrics_fear.html&quot;&gt;lyrics&lt;/a&gt;.
And thanks to Eric Cronin for discovering and scanning the now
sadly nostalgic reminder reproduced at right.&lt;/em&gt;</description>
</item>
<item>
   <title>Photography, publishing and Flickr</title>
   <link>http://www.crypto.com/blog/flickr_and_photography/</link>
   <guid>http://www.crypto.com/blog/flickr_and_photography/</guid>
   <pubDate>Sun, 30 Dec 2007 22:37:15 +0000</pubDate>
   <description>I take pictures because I can't draw.




	
&lt;p&gt;
I've dabbled with photography for most of my life, defiantly regressing toward bulkier equipment and more cumbersome technique as cameras become inexorably smaller and easier to use with each successive generation.  Lately, I've settled on a large format camera with a tethered digital scanning back, which is about as unwieldy as I'd likely want to endure, at least without employing a pack mule.
&lt;p&gt;
But for all the effort I'm apparently willing to expend to take pictures, I'm pathologically negligent about actually doing anything with them once they've been taken.  Scattered about my home and office are boxes of unprinted negatives and disk drives of unprocessed captures (this is, admittedly, overwhelmingly for the best).  So it was somewhat against my natural inclinations that a few years ago I started making available an idiosyncratic (that is to say, random) selection of images &lt;a href=&quot;http://www.crypto.com/photos/&quot;&gt;&lt;u&gt;elsewhere on this web site&lt;/u&gt;&lt;/a&gt;.
&lt;p&gt;
Publishing photos on my own server has been a mixed bag.  It maximizes my control over the presentation, which appeals to the control freak in me, but it also creates lot of non-photographic work every time I want to add a new picture --  editing html, creating thumbnails, updating links and indexes.  I've got generally ample bandwidth, but every now and then someone hotlinks into an image from some wildly popular place and everything slows to a crawl.  I could build better tools and install better filters to fix most of these shortcomings, but, true to my own form I suppose, I haven't.  So a few weeks ago I finally gave in to the temptations of convenience and opened an &lt;a href=&quot;http://www.flickr.com/photos/21746901@N08/&quot;&gt;&lt;u&gt;account on Flickr&lt;/u&gt;&lt;/a&gt;.
&lt;p&gt;
I'm slowly (but thus far, at least, steadily) populating my Flickr page with everything from &lt;a href=&quot;http://www.flickr.com/photos/21746901@N08/2149806566/&quot;&gt;&lt;u&gt;casual snapshots&lt;/u&gt;&lt;/a&gt; to &lt;a href=&quot;http://www.flickr.com/photos/21746901@N08/2146705925/&quot;&gt;&lt;u&gt;dubiously artistic abstractions&lt;/u&gt;&lt;/a&gt;.  It's still an experiment for me, but a side effect has been to bring into focus (sorry) some of what's good and what's bad about how we publish on the web.
&lt;p&gt;
Flickr is a mixed bag, too, but it's different mix than doing everything on my own has been.  It's certainly easier.  And there's an appeal to being able easily link photos into communities of other photographers, leave comments, and attract a more diverse audience.  So far at it seems not to have scaled up unmanageably or become hopelessly mired in robotic spam.  They make it easy to publish under a &lt;a href=&quot;
http://www.creativecommons.org/&quot;&gt;&lt;u&gt;Creative Commons license&lt;/u&gt;&lt;/a&gt;, which I use for most of my pictures.  But there are also small annoyances.  The thumbnail resizing algorithm sometimes adds too much contrast for my taste -- I'd welcome an option to re-scale certain images myself.  The page layout is inflexible.   There's no way to control who can view (and mine data from) your social network.  And they get intellectual property wrong in small but important ways.  For example, every published photo is prominently labeled &quot;this photo is &lt;b&gt;public&lt;/b&gt;&quot;, risking the impression that copyrighted and CC-licensed photos are actually in the public domain and free for any use without permission or attribution.  
&lt;p&gt;
I wonder how most people feel about that; do we think of our own creative output, however humble, as being deserving of protection?  Or do we tend to regard intellectual property as legitimately applying only to &quot;serious&quot; for-profit enterprises (with Hollywood and the music industry rightfully occupying rarefied positions at the top of the socio-legal hierarchy)?  A couple of years ago I led a small discussion group for incoming students at my overpriced Ivy-league university. The topic was Larry Lessig's book &lt;em&gt;Free Culture&lt;/em&gt;, and I started by asking what I thought was a softball question about who was exclusively a content consumer and who occasionally produced creative things deserving protection and recognition.  To my surprise, everyone put themselves squarely in the former category.  These were talented kids, mostly from privileged background -- hardly a group that tends to be shy about their own creativity.   Maybe it was the setting or maybe it was how I asked.   But perhaps their apparent humility was symptomatic of something deeply rooted in our current copyright mess.  Until we can abandon this increasingly artificial distinction -- &quot;consumers&quot; and &quot;content producers&quot;, us against them -- our lopsided copyright laws seem bound to continue on their current draconian trajectory, with public disrespect for the rules becoming correspondingly all the more flagrant.</description>
</item>
<item>
   <title>Ohio Voting Security Review Released</title>
   <link>http://www.crypto.com/blog/ohio_voting/</link>
   <guid>http://www.crypto.com/blog/ohio_voting/</guid>
   <pubDate>Fri, 14 Dec 2007 19:32:39 +0000</pubDate>
   <description>&lt;p&gt;
Today Ohio Secretary of State Jennifer Brunner &lt;a href=&quot;http://www.sos.state.oh.us/sos/info/everest.aspx&quot;&gt; released the results&lt;/a&gt; of a comprehensive security review of the electronic voting systems used in her state.  The study was similar in scope to the &lt;a href=&quot;http://www.crypto.com/blog/ca_voting_report/&quot;&gt;California top-to-bottom review&lt;/a&gt; conducted this summer (with which I was also involved), covering the systems used in Ohio.  The project contracted several academic teams and others to examine the election procedures, equipment and source code used in that state, with the aim of identifying any problems that might render elections vulnerable to tampering under operational conditions.
&lt;p&gt;
The ten-week project examined in detail the touch-screen, optical scan, and election management technology from e-voting vendors ES&amp;amp;S, Hart InterCivic and Premier Election Systems (formerly Diebold).  Project PI &lt;a href=&quot;http://www.patrickmcdaniel.org/&quot;&gt;Patrick McDaniel&lt;/a&gt; (of Penn State) coordinated the academic teams and led the study of the Hart and Premier Systems (parts of which had already been reviewed in the California study).  Giovanni Vigna (of WebWise Security and UCSB) led the team that did penetration testing of the ES&amp;amp;S system.
&lt;p&gt;
I led the University of Pennsylvania-based team, which examined the ES&amp;amp;S source code.  This was particularly interesting, because, unlike Hart and Premier, the full ES&amp;amp;S source code suite hadn't previously been studied by the academic security community, although ES&amp;amp;S products are used by voters in 43 US states and elsewhere around the world.  The study represented a rather unique opportunity to contribute to our understanding of e-voting security in practice, both inside and outside Ohio.
&lt;p&gt;
My group -- Adam Aviv, Pavol Cerny, Sandy Clark, Eric Cronin, Gaurav Shah, and Micah Sherr -- worked full-time with the source code and sample voting machines in a secure room on the Penn campus, trying to find ways to defeat security mechanisms under various kinds of real-world conditions.  (Our confidentiality agreement prevented us from saying anything about the project until today, which is why we may have seemed especially unsociable for the last few months.)
&lt;p&gt;
As our report describes, we largely succeeded at finding exploitable vulnerabilities that could affect the integrity of elections that use this equipment.
&lt;p&gt;
The report is long and detailed, and speaks for itself far better than I can here.   A brief statement from Patrick McDaniel and me can be found (PDF format) &lt;a href=&quot;http://www.crypto.com/papers/ohio-stmt.pdf&quot;&gt;here&lt;/a&gt;.  Our full 334 page report can be downloaded (11MB, PDF format) from the Ohio Secretary of State's web site at &lt;a href=&quot;http://www.sos.state.oh.us/sos/info/EVEREST/14-AcademicFinalEVERESTReport.pdf&quot;&gt;http://www.sos.state.oh.us/sos/info/EVEREST/14-AcademicFinalEVERESTReport.pdf&lt;/a&gt; .
&lt;p&gt;
There were other parts to the study (called &quot;Project EVEREST&quot;) than just the source code analysis, and, of course, there is also the question of how to actually secure elections in practice given the problems we found.  The Ohio Secretary of State's web site, at &lt;a href=&quot;http://www.sos.state.oh.us/sos/info/everest.aspx&quot;&gt;http://www.sos.state.oh.us/sos/info/everest.aspx&lt;/a&gt;, has a nice summary of the review and of the Secretary's recommendations.</description>
</item>
<item>
   <title>Why the Protect America Act may not protect Americans</title>
   <link>http://www.crypto.com/blog/comsec_hazards/</link>
   <guid>http://www.crypto.com/blog/comsec_hazards/</guid>
   <pubDate>Tue, 02 Oct 2007 03:15:16 +0000</pubDate>
   <description>Is this the party on whom I am eavesdropping?




	
&lt;p&gt;
Most of the debate surrounding the &lt;em&gt;Protect America Act&lt;/em&gt; --
hastily passed this summer and eliminating requirements for
court orders for many kinds of government wiretaps -- 
has focused on the perceived need to balance national
security against individual privacy.   And while it's surely true that
wiretap policy strikes at the heart of that balance, the specter
of unrestrained government spying may not be the the most immediate
reason to fear this ill-conceived and dangerous change in US law.
Civil liberties concerns aside, the engineering implications of these new
wiretapping rules, coupled
with what we can discern about how they are being implemented, should be
at least as unsettling to hawks as to doves.
&lt;p&gt;
My colleagues Steve Bellovin, Whit Diffie, Susan Landau, Peter Neumann,
Jennifer Rexford and I just completed a brief analysis of
the Protect America Act from the networking, surveillance and
security engineering perspective.  Our draft technical report,
&lt;a href=&quot;http://www.crypto.com/papers/paa-comsec-draft.pdf&quot;&gt;
&lt;em&gt;Risking Communications Security: Potential Hazards of the &quot;Protect
America Act&quot;&lt;/em&gt; can be found at
&lt;tt&gt;www.crypto.com/papers/paa-comsec-draft.pdf&lt;/tt&gt; [pdf format]&lt;/a&gt;.

&lt;p&gt;
&lt;em&gt;Update 10/13/07:&lt;/em&gt; A less-technical version can be found at
&lt;a href=&quot;http://www.crypto.com/papers/paa-briefing.pdf&quot;&gt;
&lt;tt&gt;www.crypto.com/papers/paa-briefing.pdf&lt;/tt&gt; [pdf format]&lt;/a&gt;.
&lt;p&gt;
&lt;em&gt;Update 10/22/07:&lt;/em&gt; A new (and slighty less drafty) draft
of the full technical report is now online, at
&lt;a href=&quot;http://www.crypto.com/papers/paa-comsec-draft.pdf&quot;&gt;
&lt;tt&gt;www.crypto.com/papers/paa-comsec-draft.pdf&lt;/tt&gt; [pdf format]&lt;/a&gt;.</description>
</item>
<item>
   <title>FBI surveillance technology documents released</title>
   <link>http://www.crypto.com/blog/fbi_wiretaps/</link>
   <guid>http://www.crypto.com/blog/fbi_wiretaps/</guid>
   <pubDate>Wed, 29 Aug 2007 05:31:17 +0000</pubDate>
   <description>This &lt;span class=&quot;censored&quot;&gt;space&lt;/span&gt; intentionally left &lt;span class=&quot;censored&quot;&gt;blank&lt;/span&gt;.



	
&lt;p&gt;
This morning the Electronic Frontier Foundation
&lt;a href=&quot;http://www.eff.org/flag/061708CKK/&quot;&gt;will be releasing the first installment
of many hundreds of scanned pages concerning the FBI's &lt;em&gt;DCS-3000&lt;/em&gt;
surveillance Data Collection System&lt;/a&gt;.  Most of the documents, which were obtained through a Freedom of Information Act (FOIA) lawsuit filed by the EFF, are
heavily (almost laughably) redacted user manuals and internal FBI memos,
with many pages almost entirely devoid of text.  Nonetheless, what remains
provides a rare, if fragmented and cryptic, glimpse of the state of FBI surveillance technology in general and CALEA
wiretapping in particular.  
&lt;p&gt;
Ryan Singel has a
&lt;a href=&quot;http://www.wired.com/politics/security/news/2007/08/wiretap?currentPage=all&quot;&gt;nice summary of the documents in his article on
Wired's web site&lt;/a&gt;.
It will take time to digest the huge volume of incomplete and jargon-laden material in the documents, but interesting tidbits emerge even from a cursory reading.
&lt;p&gt;
Contrary to previous speculation, DCS-3000 is much more
than an updated version of the FBI's
&lt;a href=&quot;http://www.crypto.com/papers/opentap.html&quot;&gt;Carnivore&lt;/a&gt;
Internet interception and collection device first disclosed seven
years ago.  Instead, the DCS system appears to be a comprehensive
software suite
for managing and collecting data from a variety of Title III (law enforcement)
surveillance technologies, including Internet wiretaps, wireline
voice telephony, cellular, &quot;push-to-talk&quot;, and maybe others. 
The system provides a single interface for managing
and collecting evidence from all the different kinds of wiretaps
the FBI uses, connected via a &quot;DCSNet&quot; for getting
tapped traffic to any FBI field office in the US.  There are references
to several other FBI systems as well, most notably the Bureau's ill-fated
&lt;a href=&quot;http://www7.national-academies.org/CSTB/pub_fbi.html&quot;&gt;
&lt;em&gt;Trilogy&lt;/em&gt;&lt;/a&gt; case management system, and also something called
&lt;em&gt;DCS-5000&lt;/em&gt;, which is described as an analogous system for managing
FISA (national security) taps.  The software is definitely large and complex --
there are mentions of multi-week
training courses for the agents who use it.
&lt;p&gt;
That complexity itself raises some difficult security questions. As
my colleague
&lt;a href=&quot;http://www.cs.columbia.edu/~smb/blog/2007-08/2007-08-29.html&quot;&gt;Steve
Bellovin&lt;/a&gt; points out, the new documents suggest that the FBI may have failed to
adequately secure the system against an insider threat.   But aside
from the usual risks that the software could
be subverted or abused, in a wiretapping system there's also
the problem of ensuring that intercepted evidence is faithfully
recorded.  And that, it turns out, can be harder than it sounds.
&lt;p&gt;
Two years ago, my graduate students and I
&lt;a href=&quot;http://www.crypto.com/papers/wiretapping/&quot;&gt;discovered basic
flaws in the in-band signaling mechanisms used for many years in older
analog voice telephone wiretaps&lt;/a&gt;.  The flaws allow a
wiretap target to interfere with a phone tap by playing special tones
that cause interception equipment
to shut down prematurely or record misleading call data.
We speculated, based on the documents available to us then, that
the CALEA-based interception system now used by the FBI
might suffer from similar problems.  The FBI denied this at the time,
claiming that only a few systems remain vulnerable to our attacks.
But sure enough, the EFF's new documents refer in several places to continued
support for in-band &quot;C-tone&quot; signaling in voice line taps (for example, on
&lt;a href=&quot;http://www.eff.org/flag/061708CKK/070207_dcs03.pdf&quot;&gt;page
53 of this pdf document&lt;/a&gt;).  No doubt, these features were included to
provide backward compatibility with older equipment.  And the result is
backward compatibility with older bugs.</description>
</item>
<item>
   <title>The best defense</title>
   <link>http://www.crypto.com/blog/bingo/</link>
   <guid>http://www.crypto.com/blog/bingo/</guid>
   <pubDate>Mon, 06 Aug 2007 22:58:39 +0000</pubDate>
   <description>Ad hominem security engineering.



	
&lt;p&gt;
California Secretary of State Debra Bowen's
&lt;a href=&quot;http://www.sos.ca.gov/elections/elections_vsr.htm&quot;&gt;decision&lt;/a&gt;
on the fate of her state's voting technology was announced just before
midnight last Friday.  The certifications of all three reviewed systems
(Diebold, Hart, and Sequoia) were revoked and then
re-issued subject to a range of
conditions intended to make it harder to exploit some of the problems
we found in the security review
(&lt;a href=&quot;http://www.crypto.com/blog/ca_voting_report/&quot;&gt;see previous entry in this blog&lt;/a&gt;).  The certification of a fourth system, ES&amp;amp;S, was
revoked completely because the vendor failed to submit source code in
time to be reviewed.
&lt;p&gt;
Whether the new conditions are a sufficient security stopgap and whether
the problems with these systems can be properly fixed in the long term will be
debated in the technical and elections communities in the weeks and months
to come.  How to build secure systems out of insecure components is
a tough problem in general, but of huge practical importance here, since
we can't exactly stop holding elections until the technology is ready.
&lt;p&gt;
But that's not what this post is about.
&lt;p&gt;
The traditional role of the vendors in cases like this, where critical
products are found to be embarrassingly or fatally insecure,
is to shoot the messengers.   The reaction is familiar to most anyone
who has ever found a security flaw and tried to do the right thing
by reporting it rather than exploiting it: denials, excuses, and threats.
&lt;p&gt;
Occasionally, though, a company will try to look &quot;responsible&quot; by employing a
different strategy, acknowledging -- and perhaps even actually correcting -- the
underlying problems.  This should be understood as
nothing more than a transparent attempt to pander to customers
by wastefully improving the security of otherwise perfectly good products.
These naive organizations --
a tipoff is that they're often run by engineers rather than
experienced business people -- do enormous damage by shirking their public
relations duty to the community as a whole.  Fortunately, this kind of
unsophistication is rare enough not to have been much of an issue
in the past, although in some circles, it is becoming worrisomely
commonplace.
&lt;p&gt;
To help vendors focus on their obligations here, Jutta Degener and I
present &lt;a href=&quot;http://www.crypto.com/bingo/pr&quot;&gt;Security Problem Excuse
Bingo&lt;/a&gt;.  Usual bingo rules apply, with vendor press releases, news
interviews, and legal notices used as source material.   Cards can be
generated and downloaded from
&lt;a href=&quot;http://www.crypto.com/bingo/pr&quot;&gt;www.crypto.com/bingo/pr&lt;/a&gt;
&lt;p&gt;
Because we follow all industry standard practices,
you can rest assured that there are no bugs in this software.
We take security very seriously.</description>
</item>
<item>
   <title>California voting systems code review now released</title>
   <link>http://www.crypto.com/blog/ca_voting_report/</link>
   <guid>http://www.crypto.com/blog/ca_voting_report/</guid>
   <pubDate>Thu, 02 Aug 2007 18:31:00 +0000</pubDate>
   <description>Almost as eagerly anticipated as the new Harry Potter book.




	
&lt;p&gt;
Readers of this blog may recall that
for the last two months I've been part of
a security review of the electronic voting systems used in
California.
Researchers from around the country (42 of us in all) worked
in teams that examined source code and documents
and performed &quot;red team&quot; penetration tests of election systems made by
Diebold Election Systems, Hart InterCivic and Sequoia Voting Systems.
&lt;p&gt;
The red team reports were released by the California Secretary of State
last week, and have been the subject of much attention in the nationwide
press (and much criticism from the voting machine vendors in whose systems
vulnerabilities were found).   But there was more to the study than
the red team exercises.
&lt;p&gt;
Today the three reports from the source code analysis teams were released.
Because I was participating in that part of the study, I'd been unable
to comment on the review before today.  (Actually, there's still
more to come.  The documentation reviews haven't been released
yet, for some reason.)
Our reports can now be downloaded from
&lt;a href=&quot;http://www.sos.ca.gov/elections/elections_vsr.htm&quot;&gt;http://www.sos.ca.gov/elections/elections_vsr.htm&lt;/a&gt; .
&lt;p&gt;
I led the group that reviewed the Sequoia system's code (that report
is &lt;a href=&quot;http://www.sos.ca.gov/elections/voting_systems/ttbr/sequoia-source-public-jul26.pdf&quot;&gt;here [pdf link]&lt;/a&gt;).
&lt;p&gt;
The California study was, as far as I know, the most comprehensive
independent security evaluation of electronic voting technologies ever
conducted, covering products from three major vendors and investigating
not only the voting machines themselves, but also the back-end systems that
create ballots and tally votes.  I believe our reports now constitute
the most detailed published information available about how these systems
work and the specific risks entailed by their use in elections.
&lt;p&gt;
My hats off to principal investigators Matt Bishop (of UC Davis)
and David Wagner (of UC Berkeley) for their tireless skill in putting
together and managing this complex, difficult -- and I think terribly
important -- project.
&lt;p&gt;
By law, California Secretary of State Debra Bowen must decide by tomorrow
(August 3rd, 2007) whether the reviewed systems will continue to be
certified for use throughout the state in next year's elections,
and, if so, whether to require special security procedures where
they are deployed.
&lt;p&gt;
We found significant, deeply-rooted security weaknesses
in all three vendors' software.   Our newly-released source code
analyses address many of the supposed shortcomings of the red team studies,
which have been (quite unfairly, I think) criticized as being &quot;unrealistic&quot;.
It should now be clear that the red teams were successful
not because they somehow &quot;cheated,&quot; but rather because the built-in
security mechanisms they were up against simply don't work properly.
Reliably protecting these systems under operational conditions will likely
be very hard.
&lt;p&gt;
The problems we found in the code were far more pervasive, and
much more easily exploitable, than I had ever imagined they would be.
&lt;p&gt;
&lt;a href=&quot;http://www.crypto.com/blog/ca_voting_report/&quot;&gt;Our reports (linked above) should speak for themselves, but for
my personal perspective on the review, click here to read on...&lt;/a&gt;</description>
</item>
<item>
   <title>And speaking of wiretapping...</title>
   <link>http://www.crypto.com/blog/wiretapping_for_kids/</link>
   <guid>http://www.crypto.com/blog/wiretapping_for_kids/</guid>
   <pubDate>Sat, 07 Jul 2007 23:29:08 +0000</pubDate>
   <description>Hey kids, let's commit a felony!




	
&lt;p&gt;
&lt;a href=&quot;http://www.cis.upenn.edu/~ecronin/&quot;&gt;Eric Cronin&lt;/a&gt; found this
&lt;a href=&quot;http://www.toysrus.com/product/index.jsp?productId=2322077&amp;cp=2255956.2273442.2792794&quot;&gt;cute little junior phone
bugging kit on sale at Toys 'R Us&lt;/a&gt;.  Recommended for ages 10-14 (presumably because children any older than that are more likely to be prosecuted under
&lt;a href=&quot;http://www.usdoj.gov/criminal/cybercrime/18usc2511.htm&quot;&gt;
18 USC 2511&lt;/a&gt; and
&lt;a href=&quot;http://www.usdoj.gov/criminal/cybercrime/18usc2512.htm&quot;&gt;
18 USC 2512&lt;/a&gt;), the kit is basically a tunable low-power FM radio transmitter
designed to connect to an analog telephone line.  I especially like the way the
&lt;a href=&quot;http://www.elenco.ws/manuals/k-35.pdf&quot;&gt;
instruction sheet [pdf]&lt;/a&gt;
prominently warns of the dangers of eating solder, but only
casually mentions the illegality of listening to other people's
phone calls once you've got the thing built.
(A non-trivial concern, especially considering the trouble
that &lt;a href=&quot;http://www.ramseyelectronics.com/&quot;&gt;
Ramsey Electronics&lt;/a&gt;
&lt;a href=&quot;http://slashdot.org/features/00/01/04/2316228.shtml&quot;&gt;
got into with the US Customs service a few years back for
selling similar kits&lt;/a&gt;.)
&lt;p&gt;
As strongly as I feel about the evils of illegal wiretapping,
I must admit to having decidedly mixed feelings here.  No, kids,
don't tap your neighbor's phone.   But unraveling the once-forbidden
mysteries of telephone electronics has a way of pulling a young
geek into a lifetime of technological exploration.  It certainly
did for me.
&lt;p&gt;
I was at a &lt;a href=&quot;http://wiki.oreillynet.com/foocamp07/index.cgi&quot;&gt;
conference&lt;/a&gt; recently where everyone was asked to recall
their first moment of thinking &quot;I rule!&quot; over some technology.  It's
a surprisingly revealing question; experience the exhilaration of
hacker empowerment at a sufficiently impressionable age and you're
hooked forever. A disproportionately large fraction of the answers seemed
to involve telephony.  (Mine was when I discovered you could dial a phone by
flashing the hookswitch.  I think I was too young to have anyone to call,
though).
&lt;p&gt;
So I suppose if the nerdy kid next door figures out how to hook one of these kits
up to my phone, I won't be too upset.  Just make sure not to eat
the solder.</description>
</item>
<item>
   <title>Debugging the Greek cellphone scandal</title>
   <link>http://www.crypto.com/blog/hellenic_eavesdropping/</link>
   <guid>http://www.crypto.com/blog/hellenic_eavesdropping/</guid>
   <pubDate>Sat, 07 Jul 2007 01:31:13 +0000</pubDate>
   <description>It's still called wiretapping even when the phones are wireless.




	
&lt;p&gt;
Vassilis Prevelakis and Diomidis Spinellis just published (in the July '07
&lt;em&gt;IEEE Spectrum)&lt;/em&gt; a terrific
&lt;a href=&quot;http://www.spectrum.ieee.org/print/5280&quot;&gt;technical analysis [link]&lt;/a&gt;
of the recent Greek cellular eavesdropping scandal.   In 2005, it was
discovered that over a hundred Athens cellphones, mostly belonging to
politicians (ranging from the mayor to the prime minister), were being
illegally wiretapped.  The culprit hasn't been found, but there's
plenty of fodder for speculation, including mysteriously missing records,
suspicious suicide, and, as Prevelakis and Spinellis point out,
an intriguing technological mystery.
&lt;p&gt;
This would all be interesting enough for its stranger-than-spy-fiction
elements alone, but what makes the story essential reading here is how
definitively it illustrates something that many of us in the security and
privacy community have been warning about for years: so-called &quot;lawful
interception&quot; interfaces built in to network infrastructure become inviting
targets for abuse.  (See, for example, this point made
&lt;a href=&quot;http://www.crypto.com/papers/escrowrisks98.pdf&quot;&gt;in 1998 [pdf]&lt;/a&gt; and
&lt;a href=&quot;http://www.cs.columbia.edu/~smb/papers/CALEAVOIPreport.pdf&quot;&gt;in 2006 [pdf]&lt;/a&gt;).
And, as this case shows, those targets can be rich indeed.
&lt;p&gt;
For some reason, wiretapping interfaces don't seem to get much technical
scrutiny, and we're starting to see how easy it can be to
exploit them to nefarious ends.
Vulnerabilities here can cut both ways, too, sometimes making it easier
for real criminals to evade legal surveillance.  A couple
of years ago, Micah Sherr, Eric Cronin, Sandy Clark and I
&lt;a href=&quot;http://www.crypto.com/papers/wiretapping/&quot;&gt;discovered basic
weaknesses in the interception technologies used for decades to tap
wireline telephones&lt;/a&gt;.  Many of the vulnerabilities have found their way, in the name of &quot;backward compatibility&quot;,
into the latest eavesdropping standards, now implemented just about everywhere.
Maybe even in Greek cellular networks.
&lt;p&gt;
&lt;em&gt;Addendum:&lt;/em&gt; I just noticed that
&lt;a href=&quot;http://www.cs.columbia.edu/~smb&quot;&gt;Steve Bellovin&lt;/a&gt; has
a &lt;a href=&quot;http://www.cs.columbia.edu/~smb/blog/2007-07/2007-07-06.html&quot;&gt;
blog post on the same subject here&lt;/a&gt;, with some interesting comments and
links.</description>
</item>
</channel>
</rss>
