Defeating RIAA-released Trojans/Viruses on Filesharing Networks


by Alex Kirk

Introduction

After reading of the RIAA's plans to attack filesharing networks with trojans, viruses, and corrupt files, I decided something needed to be done to protect those networks and their legitimate uses. Since my programming skills are mediocre at best, and my free time is practically nonexistent these days, I figured the best way for me to contribute to this effort was to write this document suggesting a method of protection, and then encouraging skilled programmers with the time on their hands to implement it.

The underlying concept in my plan relies on basic cryptography, in the form of MD5 signatures. In short, affected networks need to simply add MD5 checking to their clients, to allow users to filter out bad files.

How can this be done? It should actually be pretty simple to implement. The steps involved are: adding a reporting feature to clients, to allow for identification of bad files; the distribution and verification of the MD5 signatures of these files; and the cross-checking of shared files against the blacklists that would be created. I believe that, if done properly, this process can safeguard users against the vast majority of unwanted material without blocking desired material.

Reporting Unwanted Files

This step is the simplest part of the process. Each client can have a button (or in the case of non-GUI clients, a switch) that says "Report This File." The user simply chooses that option when they have discovered a file that contains a virus, is corrupt -- or possibly even when a file just plain sucks. To help verify that a file is being blacklisted for good reason, the client should also give the user a small menu of reasons for blacklisting, i.e.: As you can see by the last option, this system also has the potential benefit of helping people screen out material besides RIAA-sponsored attacks, such as child porn.

Distribution and Verification

Once a file has been identified by the client, it needs to be added to a list of bad files. This can be done in one of two ways: either by being sent to a centralized group of servers, or by being broadcast to all local network nodes. In either case, the list can be maintained much like lists of local network nodes are maintained currently; indeed, most clients could implement the sharing of identified files through a simple extension of their node identificaiton systems.

The verification part of the process is where things get tricky. When sharing a list of network nodes, there is no potential for harm or abuse by identifying nonexistent or stale nodes. However, with a blacklist, it's quite possible that the RIAA or any other individual/group that wished to harm the network could simply set up nodes that spewed out blacklists full of perfectly legitimate files. Thus, safety measures should be set up to guard against this possibility. While I am certain that a roomful of intelligent programmers could think up even better measures than this, I propose to at least begin with the concept of safety in numbers -- i.e., before a file is blacklisted, it must be reported a certain number of times, such as 500. While this idea lends itself better to the centralized-server method, it could likely work with decentralized control, by adding a "count" value to each MD5 signature that was passed along. A measure to ensure that this value is not tampered with, however, should probably be implemented as well.

Cross-Checking

Once these blacklists existed, it would be a relatively simple matter for client programs to check files against them. In order to get the best possible protection, the uploading client would first pass an MD5 signature of the file to be downloaded, which the downloading client could check before even beginning a transfer. This would work amongst "legitimate" peers to help stop the spread of virii, etc. To ensure that the RIAA does not simply send along a fake MD5 signature with their files, the client software could compute said signature against the downloaded file instantly after transfer, double-checking integrity. If the MD5 signatures matched, and were not blacklisted, the file would have been verified as "clean"; if the signatures disagreed, and the second showed up on a blacklist, it would at that point be simple to add the IP of the "lying" machine to yet another blacklist, which could be passed around the network much as the "bad file" blacklist was. This second "liar machine" blacklist would serve as evidence in any potential court case or other retaliatory action (i.e. ISP notification) against the RIAA; additionally, clients could choose to ignore those nodes on the network entirely.

Of course, since this method is not foolproof, users should be given the option of configuring their level of protection. They could either not participate at all; implement this scheme entirely; or skip out on certain parts, such as reporting, the pre- or post-download checks, etc.

Conclusion

While this method is by no means perfect, I believe it would represent a meaningful step forward in the defense of filesharing networks. I hope that, once a number of capable programmers have read this paper, it will be implemented in a widespread fashion, and improved upon where necessary. Anyone who is interested in doing so should feel free to proceed immediately, though I would appreciate notification if you used my idea, and would be happy to expand upon it and/or answer questions related to it. Additionally, anyone at all may copy/post this document in its entireity anywhere they wish, so long as my name remains attached as the author. Lastly, I volunteer my resources to act as a centralized "blacklist" server if anyone wishes to implement one.