As a CITP fellow last year, one of my goals was to get a new project on digital activism off the ground. With support from the US Institutes of Peace and a distributed network of researchers we pulled together an event dataset of hundreds of instances where people tried using information and communication technologies to achieve […]
The New Ambiguity of "Open Government"
February 29, 2012 by
David Robinson and I have just released a draft paper—The New Ambiguity of “Open Government”—that describes, and tries to help solve, a key problem in recent discussions around online transparency. As the paper explains, the phrase “open government” has become ambiguous in a way that makes life harder for both advocates and policymakers, by combining the politics of transparency with the technologies of open data. We propose using new terminology that is politically neutral: the word adaptable to describe desirable features of data (and the word inert to describe their absence), separately from descriptions of the governments that use these technologies.
Clearer language will serve everyone well, and we hope this paper will spark a conversation among those who focus on civic transparency and innovation. Thanks to Justin Grimes and Josh Tauberer, for their helpful insight and discussions as we drafted this paper.
Abstract:
“Open government” used to carry a hard political edge: it referred to politically sensitive disclosures of government information. The phrase was first used in the 1950s, in the debates leading up to passage of the Freedom of Information Act. But over the last few years, that traditional meaning has blurred, and has shifted toward technology.
Open technologies involve sharing data over the Internet, and all kinds of governments can use them, for all kinds of reasons. Recent public policies have stretched the label “open government” to reach any public sector use of these technologies. Thus, “open government data” might refer to data that makes the government as a whole more open (that is, more transparent), but might equally well refer to politically neutral public sector disclosures that are easy to reuse, but that may have nothing to do with public accountability. Today a regime can call itself “open” if it builds the right kind of web site—even if it does not become more accountable or transparent. This shift in vocabulary makes it harder for policymakers and activists to articulate clear priorities and make cogent demands.
This essay proposes a more useful way for participants on all sides to frame the debate: We separate the politics of open government from the technologies of open data. Technology can make public information more adaptable, empowering third parties to contribute in exciting new ways across many aspects of civic life. But technological enhancements will not resolve debates about the best priorities for civic life, and enhancements to government services are no substitute for public accountability.
On digital TV and natural disasters
September 12, 2008 by
As I’m writing this, the eye of Hurricane Ike is roughly ten hours from landfall. The weather here, maybe 60 miles inland, is overcast with mild wind. Meanwhile, the storm surge has already knocked out power for ten thousand homes along the coast, claims the TV news, humming along in the background as I write this, which brings me to a thought.
Next year, analog TV gets turned off, and it’s digital or nothing. Well, what happens in bad weather? Analog TV degrades somewhat, but is still watchable. Digital TV works great until it starts getting uncorrectable errors. There’s a brief period where you see block reconstruction errors and, with even a mild additional amount of error, it’s just unwatchable garbage. According to AntennaWeb, most of the terrestrial broadcast towers are maybe ten miles from my house, but that’s ten miles closer to the coast. However, I get TV from Comcast, my local cable TV provider. As I’ve watched the HD feed today, it’s been spotty. Good for a while, unwatchable for a while. The analog feed, which we also get on a different channel, has been spot on the whole time.
From this, it would appear that Comcast is getting its feed out of the air, and thus has all the same sorts of weather effects that I would have if I bothered to put my own antenna on the roof. Next year, when the next hurricane is bearing down on the coast, and digital TV is the only TV around, it’s an interesting question whether I’ll get something useful on my TV during a disaster. Dear Comcast, Engineering Department: please get a hard line between you and each of the local major TV stations. Better yet, get two of them, each, and make sure they don’t share any telephone poles.
[Sidebar: In my old house, I used DirecTV plus a terrestrial antenna for HD locals, run through a DirecTV-branded HD TiVo. Now, I’m getting everything from Comcast, over telephone poles, into a (series 3) TiVo-HD. In any meaningful disaster, the telephone poles are likely to go down, taking out my TV source material. I get power and telephone from the same poles, so to some extent, they make a single point of failure, and thus no meaningful benefit from putting up my own antenna.
Once the storm gets closer, I’ll be moving the UPS from my computer to our, umm, shelter-in-place location. I don’t expect I’d want to waste precious UPS battery power running my power-hungry television set. Instead, I’ve got an AM/FM portable radio that runs on two AA’s. Hopefully, the amount of useful information on the radio will be better than the man-on-the-street TV newscasters, interviewing fools standing along the ocean, watching the pretty waves breaking. Hint: you can’t “ride through” a storm when the water is ten feet over your head.]
Government Data and the Invisible Hand
June 2, 2008 by
David Robinson, Harlan Yu, Bill Zeller, and I have a new paper about how to use infotech to make government more transparent. We make specific suggestions, some of them counter-intuitive, about how to make this happen. The final version of our paper will appear in the Fall issue of the Yale Journal of Law and Technology. The best way to summarize it is to quote the introduction:
If the next Presidential administration really wants to embrace the potential of Internet-enabled government transparency, it should follow a counter-intuitive but ultimately compelling strategy: reduce the federal role in presenting important government information to citizens. Today, government bodies consider their own websites to be a higher priority than technical infrastructures that open up their data for others to use. We argue that this understanding is a mistake. It would be preferable for government to understand providing reusable data, rather than providing websites, as the core of its online publishing responsibility.
In the current Presidential cycle, all three candidates have indicated that they think the federal government could make better use of the Internet. Barack Obama’s platform explicitly endorses “making government data available online in universally accessible formats.” Hillary Clinton, meanwhile, remarked that she wants to see much more government information online. John McCain, although expressing excitement about the Internet, has allowed that he would like to delegate the issue, possible to a vice-president.
But the situation to which these candidates are responding – the wide gap between the exciting uses of Internet technology by private parties, on the one hand, and the government’s lagging technical infrastructure on the other – is not new. The federal government has shown itself consistently unable to keep pace with the fast-evolving power of the Internet.
In order for public data to benefit from the same innovation and dynamism that characterize private parties’ use of the Internet, the federal government must reimagine its role as an information provider. Rather than struggling, as it currently does, to design sites that meet each end-user need, it should focus on creating a simple, reliable and publicly accessible infrastructure that “exposes” the underlying data. Private actors, either nonprofit or commercial, are better suited to deliver government information to citizens and can constantly create and reshape the tools individuals use to find and leverage public data. The best way to ensure that the government allows private parties to compete on equal terms in the provision of government data is to require that federal websites themselves use the same open systems for accessing the underlying data as they make available to the public at large.
Our approach follows the engineering principle of separating data from interaction, which is commonly used in constructing websites. Government must provide data, but we argue that websites that provide interactive access for the public can best be built by private parties. This approach is especially important given recent advances in interaction, which go far beyond merely offering data for viewing, to offer services such as advanced search, automated content analysis, cross-indexing with other data sources, and data visualization tools. These tools are promising but it is far from obvious how best to combine them to maximize the public value of government data. Given this uncertainty, the best policy is not to hope government will choose the one best way, but to rely on private parties with their vibrant marketplace of engineering ideas to discover what works.
To read more, see our preprint on SSRN.
CD DRM: Attacks on the Player
January 31, 2006 by
Alex and I are working on an academic paper, “Lessons from the Sony CD DRM Episode”, which will analyze several not-yet-discussed aspects of the XCP and MediaMax CD copy protection technologies, and will try to put the Sony CD episode in context and draw lessons for the future. We’ll post the complete paper here later in the week. Until then, we’ll post drafts of a few sections here. We have two reasons for this: we hope the postings will be interesting in themselves, and we hope your comments will help us improve the paper.
Today’s excerpt is the last one we will post. By now, you have seen drafts of the all sections of the paper except the introduction, conclusion, and discussion of related work. The deadline for submission is (late) tomorrow night.
Please note that this is a draft and should not be formally quoted or cited. The final version of our entire paper will be posted here when it is ready.
Attacks on the Player
Increasingly, personal computers—and portable playback devices that attach to them—are users’ primary means of organizing, transporting, and enjoying their music collections. Sony and its DRM vendors recognized their trend when they designed their copy protection technologies. Rather than inhibit all use with PCs, as some earlier anti-copying schemes did~cite{}, XCP and MediaMax allow certain limited uses subject to restrictions imposed by DRM software.
XCP and MediaMax facilitate use on PCs using their own proprietary media players that are shipped on each protected CD. The schemes use active (and, with XCP, passive) protection to block other applications from accessing the CD audio, but a back door allows the scheme’s own player to bypass the protections.
The XCP and MediaMax players launch automatically using autorun when a protected disc is inserted into a PC. Both players have similar feature sets. They provide a rudimentary player interface, allowing users to listen to protected albums, and they allow access to “bonus content,” such as album art, liner notes, song lyrics, and links to artist web sites. [Footnote: Curiously, this bonus content is seldom copy protected, perhaps because it is of little value.]
XCP and MediaMax both permit users to burn copies of the entire album a limited number of times (typically 3). These copies are create using a proprietary burning application integrated into the player. They include the player applications and active (and passive, for XCP) protection as the original album, but they do not allow any subsequent generations of copying.
Another feature of the player applications allows users to rip the tracks from the CD to their hard disks, but only in DRM-protected audio formats. Both schemes support the Windows Media Audio format by using a Microsoft product, the Windows Media Data Session Toolkit [citation[, to deliver DRM licenses that are bound to the PC where the files were ripped. The licenses allow the music to be transferred to portable devices that support Windows Media DRM scheme or burned onto CDs, but the Windows Media files will not be usable if they are copied to another PC.
Attacks on Player DRM
The XCP and MediaMax players were designed to enforce usage restrictions specified by content providers. In practice, they provide minimal security, because there are a number of ways that users can bypass the limitations.
Perhaps the most interesting class of attacks targets the limited number of burned copies permitted by the players. Both players are designed to enforce this limit without communicating with any networked server; therefore, the player must keep track of how many allowed copies remain by storing state on the local machine.
It is well known that DRM systems like this are vulnerable to rollback attacks. In a rollback attack, the state of the machine is backed up before performing the limited operation (in this case, burning the copy). When the operation is complete, the old system state is restored, and the DRM software is not able to determine that the operation has occurred. This kind of attack is easy to perform with virtual machine software like VMWare, which allows the entire state of the system to be saved or restored in a few clicks. The XCP and MediaMax both fail under this attack, which allows unlimited copies to be burned with their players.
A refined variation of this attack targets only the specific pieces of state that the DRM system uses to remember the number of copies remaining. The XCP player uses a single file, %windir%system32$sys$filesystem$sys$parking, to record how many copies remain for every XCP album that has been used on the system. [Footnote: We did not determine how the MediaMax player stores the number of copies remaining.] This file is hidden and protected by the XCP rootkit. With the rootkit disabled, a user can back up the file, copy the album, and then restore the backup to set the remaining copy counter back to its original value.
A more advanced attacker can go further and modify the $sys$parking file to set the counter to an arbitrary value. The file consists of a 16 byte header followed by a series of 177 byte records. For each XCP disc used on the machine, the file contains a whole-disc record and an individual record for each track. Each disc record stores the number of permitted copies remaining for the disc as a 32-bit integer beginning 100 bytes from the start of the record.
The file is protected by primitive encryption. Each record is XORed with a repeating 256-bit pad. The pad—a single one is used for all records—is randomly chosen when XCP is first installed and stored in the system registry in the key HKLMSOFTWARE$sys$referenceClassID. Note that this key, which is hidden by the rootkit, is intentionally misnamed “ClassID” to confuse investigators. Instead of a ClassID it contains the 32 bytes of pad data.
Hiding the pad actually doesn’t increase the security of the design. An attacker who knows only the format of the $sys$parking file and the current number of copies remaining can change the counter to an arbitrary value without. Say the counter indicates that there are x copies remaining and the attacker wants to set it to y copies remaining. Without decrypting the record, she can XOR the padded bytes where the counter is stored with the value (x XOR y). If the original value was padded with p, the new value is (x XOR p) XOR (x XOR y) = (y XOR p), which is just y padded with p.
iPod Compatibility
Ironically, Sony itself furnishes directions for carrying out another kind of attack on the player DRM.
Conspicuously absent from the XCP and MediaMax players is support for the Apple iPod—by far the most popular portable music player with more than 80% of the market [citation]. A Sony FAQ blames Apple for this shortcoming and urges users to direct complaints to them:”Unfortunately, in order to directly and smoothly rip content into iTunes it requires the assistance of Apple. To date, Apple has not been willing to cooperate with our protection vendors to make ripping to iTunes and to the iPod a simple experience.” [citation]. Strictly speaking, it is untrue that Sony requires Apple’s cooperation to work with the iPod. They ship thousands of albums that work “smoothly” with iTunes every day: unprotected CDs. What Sony has difficulty doing is moving music to the iPod while keeping it wrapped in copy protection. This is because Apple has so far refused to license its proprietary DRM, a system called FairPlay.
Yet so great is consumer demand for iPod compatibility that Sony gives out—to any customer who fills out a form on its web site [citation] —instructions for working around its own copy protection and transforming the music into a DRM-free format that will work with iTunes. The procedure is simple but cumbersome: users are directed to use the player software to rip the songs into Windows Media DRM files; use Windows Media Player to burn the files to a blank CD, which will be free of copy protection; and then use iTunes to rip the songs once more and transfer them to the iPod.
XCP’s Hidden iPod Support
A further irony came to light in the weeks following the public disclosure of the XCP rootkit when it was discovered that XCP itself apparently infringes on the copyrights to several open source software projects. In one case, Sam Hocevar found strong evidence that part of XCP’s code was copied from a program called DRMS, which he co-authored with Jon Lech Johansen and released under the terms of the GPL open source license. This was particularly curious, because the purpose of DRMS is to break Apple’s FairPlay DRM. Its presence is interesting enough to warrant a brief diversion from our discussion of player-related attacks.
We discovered that XCP utilizes the DRMS code not to remove Apple DRM but to add it, as part of a hidden XCP feature that provides iTunes and iPod compatibility. This functionality shipped on nearly every XCP CD, but it was never enabled or made visible in the XCP user interface. Despite being inactive, the code appears to be fully functional and was compatible with the current version of iTunes when the first XCP CDs were released. [Footnote: XCP’s FairPlay-compatibility code works with iTunes up to iTunes version 4.8. iTunes 4.9, released June 28, 2005, included changes unrelated to FairPlay that cause the XCP code to fail. XCP CDs released after this date do not appear to contain an updated version of the code.] This strongly suggests that the apparently infringing DRMS code was deliberately copied by XCP’s creator, First4Internet, rather than accidentally included as part of a more general purpose media library used for other functions in the copy protection system.
This isn’t the first time another vendor has tried to make its DRM compatible with FairPlay. FairPlay is the only DRM compatible with iPod, and Apple has declined to license it to rival music distributors, effectively locking rivals out from the iPod platform (at least as long as the rivals insist on using DRM). In 2004, RealNetworks attempted to work around Apple and reverse engineered FairPlay so that Real Player could create FairPlay files for use with the iPod [citation]. Apple responded by making vague legal threats and updating iTunes to break this compatibility. The evidence suggests that First4Internet wanted to create their own iPod compatibility system, but rather than take the time to reverse engineer FairPlay themselves, they copied critical pieces of code from DRMS in violation of the GPL license.
Understanding how XCP uses code from DRMS requires a some background information about FairPlay. When a customer purchases a song from the iTunes Music Store, she receives a FairPlay encrypted audio file that can only be played with knowledge of a secret key assigned to her by Apple. iTunes retrieves this key from an Apple server and stores it on the hard drive in an encrypted key database (a file called SC Info.sidb). When the user plays the song again, or if she copies it to an iPod, iTunes reads her key from the database instead of reconnecting to the server.
FairPlay’s security depends on the encrypted key database being difficult anyone but Apple to decipher, so it is protected using a proprietary encryption method and a system-dependent secret key. [Footnote: As security experts predicted, this protection was quickly broken. Today DRMS is able to defeat FairPlay because Jon Lech Johansen reverse engineered the database decryption code in iTunes.] iTunes encrypts the key database using a two step process. First it pads the plaintext database by XORing it with the output of a proprietary pseudorandom number generator (PRNG) using a system-dependent seed; then it applies AES encryption in ECB mode with a system-dependent key. As a consequence of this design, the code for the PRNG is exactly the same whether the file is being encrypted or decrypted. To decrypt, iTunes applies AES decryption, then XORs the same PRNG output again. This explains why parts of the DRMS code—in particular, a function called DoShuffle, which computes the PRNG’s output—are useful for encryption as well as their original purpose, decryption.
The proprietary PRNG must have been especially difficult to reverse engineer. Rather than expend this effort themselves, XCP’s authors appear to have lifted the DoShuffle code verbatim from DRMS. XCP uses this code to manipulate the iTunes key database in the process of adding FairPlay protection. Starting with an unencrypted audio file, such as a track from a protected CD, XCP applies AAC compression in memory, then encrypts using the same algorithm as FairPlay. Instead of using an Apple-assigned user key, XCP creates a new random user key and, with the help of the DRMS code, adds it to the iTunes key database. This ensures that the song file can only be used on the computer where it was created.
The XCP FairPlay compatibility code is contained in a file named ECDPlayerControl.ocx that is installed the first time an XCP CD is played. The code can be tested by jumping to a function at debugger offset 0x10010380 (apparently the start of a thread for transferring music to iTunes). This function takes one parameter, a wide character string of the form <m P 3>< "C:test.mp3">. This syntax causes the function to convert an MP3 file to a FairPlay-protected AAC file. Variations can be used to specify other audio sources: WAV files, raw audio files, standard unprotected audio CDs, and XCP copy-protected CDs. Before calling the function, you must initialize a Windows CriticalSection object and set the ECX register to the object’s address minus 0x6C.
The parent function calls a subroutine (offset 0x10027D20) that converts an audio file into a FairPlay-protected AAC file. A second subroutine (offset 0x1008A470) reads the iTunes key database, decrypts it, and, if necessary, adds the XCP user key to the database and re-saves it in encrypted form. The iTunes database encryption function
(0x1008A0C0) and decryption function (0x1008A300) both made use of the DoShuffle routine (0x10089E00) taken from DRMS.
MediaMax Player Security Risks
Besides suffering from several kinds of attacks that expose the music content to copying, the MediaMax player make the user’s system more vulnerable to attack. When a MediaMax CD is inserted into a computer, Windows autorun launched an installer from the disc. Even before the installer displays a license agreement, it copies almost 12 megabytes of files and data related to the MediaMax player to the hard disk and stores them in a folder named
%programfiles%Common FilesSunnComm Shared. Jesse Burns and Alex Stamos of iSec partners first discovered that the MediaMax installer sets insecure permissions on this directory and the files and programs it contains [citation]. The installer grants “Everyone” (all users) the “Full Control” privilege. Normally, application files shared by all users on a Windows system can only be modified by members of the “Administrators” and “Power Users” groups.
As Burns and Stamos realized, this misconfiguration could lead to a dangerous privilege escalation attack. The incorrect permissions allow a non-privileged user to replace the executable code in the MediaMax player files. A user might plant malicious code deliberately in order to attack the system, or accidentally as the result of an email virus. The next time a user plays a MediaMax-protected CD, the attack code will be executed with that user’s security privileges. The MediaMax player requires Power User or Administrator privileges to run, so it’s likely that the attacker’s code will run with almost complete control of the system.
Normally, this problem could be fixed by manually correcting the errant permissions. However, MediaMax aggressively updates the installed player code each time the software on a protected disc autoruns or is launched manually. As part of this update, the permissions on the installation directory are reset to the insecure state.
We discovered a variation of the attack suggested by Burns and Stamos that allows the attack code to be installed and triggered even more easily—simply by inserting MediaMax CDs without ever consenting to the software’s installation. In the original attack, the user needed to accept the MediaMax license agreement before attack code could be inserted or executed, because the code was placed in a file called MMX.EXE that was not copied to the system until after the agreement was accepted. In our version, the attacker modifies a different file, MediaMax.dll, which MediaMax installs even before displaying a license agreement, and places attack code in the file’s DllMain() procedure. The next time a MediaMax CD is inserted, the installer autoruns and immediately attempts to check the version of the installed MediaMax.dll file. The installer calls the Windows LoadLibrary function on the DLL file, which causes the file’s DllMain() procedure to execute, together with any attack code inserted there.
This problem was exacerbated because part of the MediaMax software are installed automatically and without consent. Users who declined the license agreement would likely assume that MediaMax was not installed, and so most were unaware that they were vulnerable. The same installer code performs the dangerous version check as soon as the CD is inserted. A CD that prompted the user to accept a license before installing would give the user a chance to head off the attack.
Fixing the problem permanently without losing the use of protected discs requires applying a patch from MediaMax. Unfortunately, we discovered, the initial patch released by Sony in response to the iSec report was capable of triggering precisely the kind of attack it attempted to forestall. In the process of updating MediaMax, the patch checks the version of MediaMax.dll just like the MediaMax installer does. If this file has already been booby trapped by an attacker, the process of applying the security patch could execute the attack code. Prior versions of the MediaMax uninstaller had the same vulnerability, though both the uninstaller and the patch have since been replaced with versions that do not suffer from this problem.
