SDR
Last week, Fred recounted a conversation with John Gilmore about software-defined radio, or SDR. The prospects of that technology are just mind-blowing in their implications for the kinds of things people could do with radio communications -- it seems that almost all aspects of radio could be converted from electrical engineering problems into software programming problems. (That includes tuning, demodulation, decoding, and DSP in general -- and the reverse if you wanted to use SDR for transmitting.)
The idea, as Fred explained it (and I may be getting a distorted view, because Fred keeps saying that he's not a technologist), is that you have some raw uninterpreted RF signal input directly into a very high speed DAC connected to a very fast microprocessor. So there's no tuning in hardware; the microprocessor just gets the bits which represent the actual RF waveforms (within a certain band), to interpret as it chooses, or as it's instructed by software. Thus instead of having an "FM radio" you might have an antenna connected to a DAC, and an "FM tuning" and "FM demodulating" software program!
This spells trouble for the legal regulation of radio receivers: it can be made illegal to manufacture a device which receives a certain kind of signal (for example, cell phone conversations), but it's not clear that it can be made illegal to publish software which instructs a computer how to extract a cell phone conversation from a recorded broadband signal.
When I saw Bruce Perens at the CPTWG meeting, he suggested that the laws against radio equipment capable of receiving certain bands (passed when it was first discovered that cell phone calls were being overheard by parties other than their intended recipients) constituted a sort of precedent for the DMCA -- you have some technology which is completely inadequate for the kind of security you would like to achieve, so you simply ban technology which implements the trivial steps necessary to do whatever it is you don't like. Thus, with cell phones, there was no suggestion that it was the responsibility of cell phone vendors to deploy genuinely secure phones (partly, some say, because law enforcement didn't actually want that to happen!). Instead, the tools of the technically sophisticated were attacked and driven underground.
In some sense, it's easy to ban some item of hardware -- it has to be manufactured somewhat, it has to be sold somewhere, it has to be publicized somehow. Furthermore, nobody will bring facial or as-applied constitutional challenges to regulations of hardware (unless the hardware in question is some sort of weapon, I suppose). So Congress can pass laws saying that certain "black boxes" and even certain kinds of open and documented hardware are going to be illegal, and it may be awful but it's not clearly unconstitutional. And it's not clearly impossible to enforce.
Banning software is much trickier. First, constitutional challenges to legislation which outlaws the publication of software are likely. So far, EFF is running 1 and 1 on this (we won against the ITAR but lost against the DMCA). Second, software is information, and need not be manufactured or sold in any observable location. It can be printed in books; it can be transmitted by private e-mail; it can be memorized. (For example, the CipherSaber project has attempted to produce a huge group of programmers who have individually memorized how to implement RC4 in their respective favorite programming languages. If only anti-crypto legislation were still floating around Capitol Hill, the fact that strong crypto algorithms and implementations are texts resident in many indviduals' minds would be a fascinating point to inject into that discussion.) It can be disseminated by means of any channel by which information is disseminated -- taught in university classes, published as poems, studied in mathematics or electrical engineering journals, reprinted in textbooks, placed on FTP sites (in any jurisdiction).
If SDR really allows you to make any kind of radio device you like, just by loading a new program, it really is a serious challenge to the regulation of radio communications. I don't mean that "pirate radio" or unlicensed transmissions will be helped by SDR, although that's true. It's still theoretically possible to trace a transmission to its physical source, if it's powerful enough to interfere with other licensed communications, and if somebody complains. I'm talking about regulation of radio receiving equipment: cell phones, televisions, scanners, and so on. A purely passive device can't be detected (although radio experts would surely add a footnote here), and yet such devices -- when assumed to be hardware -- are routinely regulated.
Some of the things you could make in software with a high-quality generic SDR interface include
- a radio capable of receiving any band, all in software
- a multichannel analyzer
- a receiver for spread-spectrum and frequency-hopping transmitters (without the technical assistance of the creators of those transmitters)
- a scanner which can intercept cell phone conversations, and decode and log many conversations at once
- generalized surveillance equipment which can monitor a wide frequency band, and, in software, detect and decode multiple communications on multiple frequencies with multiple multiplexing schemes and multiple modulation schemes (sorting and logging all of the received data to disk)
- an NTSC television (all in software)
- an ATSC television (all in software)
- a PVR which can record multiple ATSC signals from the air at once, as opposed to tuning to a single channel at a time
What am I missing?
Each of these purely passive devices upsets somebody's interest or assumptions, whether it's the assumption that it ought to be expensive to build a particular device, or that manufacturers of a particular device should be licensed, or that a device should be illegal or only available to law enforcement and intelligence agencies. But, with these features in software, they could be available to everyone!
If you want to take it further and think about SDR transmitters, which I mentioned above, it seems that you can have all of the aspects of transmission, including the selection of frequency and power, under the control of software. Some of the web sites on SDR suggest that you can make a repeater which can have arbitrary kinds of inputs and outputs, all of which are just a matter of programming.
Fred is interested in the blurring distinction between hardware and software in general. FPGAs and VHDL are one of the interesting factors here; you can write schematics in a high-level language (which may be nearly indistinguishable from software), and then instantly fabricate a chip based on a given schematic.
This blurring has definitely made the development of new and custom hardware faster, easier, and cheaper -- not to mention more accessible to individuals, who can now conceivably "fabricate" chips of their own designs in the privacy of their own homes, by programming FPGAs.
The future of technology seems to be one in which more and more operations are performed in software (or by means of a software-like step). If we can formulate a sufficiently precise description of the behavior we would like a general-purpose device to adopt, then we need only say so, and that device will become a machine behaving in exactly the way we've described.
Second week, more advanced,
And we had to
Be a table,
Be a sportscar,
Ice-cream cone.
("Nothing", from A Chorus Line)
We could say that every feature wants to be implemented in software, and that trend is well-known to people who design or follow embedded systems. An increasing number of embedded systems are actually general-purpose systems loaded with software dedicating them (for the moment, at least) to one particular function. (This is why we have "TiVo hacking".) Now languages and hardware are sophisticated enough that, in some contexts, specifying a machine precisely enough is sufficient to realize it automatically in the physical world. (Fred mentioned CAM in this context -- you can also make a blueprint for a physical device and have computer-controlled lathes cut the requisite parts out of sheet metal for you, with no further human intervention.)
For example, logic synthesis tools have been around for quite a while. I can write a truth table for a function of several Boolean variables, which can also be seen as a description of (not necessarily a plan for) a machine which performs some function. Logic synthesis software can analyze the truth table and write it in terms of elementary gates combined in some way -- and then write the gates directly into a PAL or FPGA without even showing me the intermediate gate-level representation. The end result is a chip, a digital machine, which performs (or calculates) the function I described, and the internal operation of which might be a complete mystery to me. VHDL, which I've never used, can be like this, only more so. Indeed, EFF published an entire book, Cracking DES, which can be seen as a description of a machine that would perform extremely fast brute force searches against DES. But with a VHDL compiler, that description can be turned into a schematic, loaded into chips, and you'll immediately be in possession of such a machine.
Returning to SDR, I can imagine a very general and high-quality DAC (and maybe some kind of software-controlled tuner or filter so that the conversion doesn't need to have an absurdly high bandwidth), operating as an SDR, for which people have written various "modules", each of which performs some kind of signal-processing function on an input from an earlier stage. I can then imagine "writing a television" or "writing a PVR" by giving a brief high-level description of the way in which the modules are combined to cause a computer to emulate a particular device. Adding new features to the television thus constructed could be as easy as adding a single line of code.
If this seems ridiculous, just think of the kinds of operations we do on computers today compared to the operations computers performed not long ago. Once, sorting was a major operation, requiring substantial programming effort (perhaps different programs for each sorting task). Today, hardly thinking about it, I can sort a text file by absentmindedly including "| sort" in a shell script, or sort elements in a Python datastructure with a single call to "foo.sort()", implemented for me by someone else in a high-level library I've never even looked at. Cryptographic primitives, high-level reliable and unreliable networking over a worldwide public network, compression and decompression, and other "infrastructural" matters, have all been encapsulated for me inside shell tools or libraries.
I remember reading a book which discussed the reactions of telephone industry folks, during the heyday of phreaking, before the public switched telephone network had much of a security infrastructure to speak of, when computers with sound cards were introduced. "We thought it was really risky and irresponsible to give the general public this much DSP capability" is approximately what I remember one of the telco people saying. And of course SDR is really much like any other kind of DSP, conceptually -- it just uses antennas for analog I/O instead of speakers and microphones. But "risky and irresponsible to give this capability to the general public"? Maybe the "capability" in question is not SDR or phreaking software but sound cards, oscilloscopes, fast general purpose computers, and ADC. I've met people recently who seemed to have that attitude about ADCs!
