SDR, forwarded message from John Gilmore
Maitland Bottoms
aa4hs@amrad.org
Sat, 14 Sep 2002 22:45:17 -0400
--RuwM0md9lt
Content-Type: text/plain; charset=us-ascii
Content-Description: message body text
Content-Transfer-Encoding: 7bit
Perhaps the reason ham radio manufacturers do not give hams I&Q
digital outputs is that they also want to manufacture radios for other
markets. Markets which would like to operate in a world where owning a
scanner would be a felony.
This attached message appeared on the GNU Radio project list.
"John is an EFF co-founder, with a strong interest in encryption
issues" - http://www.eff.org/Publications/John_Gilmore/
-Maitland
enc:
--RuwM0md9lt
Content-Type: message/rfc822
Content-Description: forwarded message
Content-Transfer-Encoding: 7bit
Return-Path: <bottoms@airborne.nrl.navy.mil>
Received: from airborne.nrl.navy.mil (airborne.nrl.navy.mil [132.250.182.112])
by rockytop.rf.org (8.12.3/8.12.3/Debian -4) with ESMTP id g8E5hx90030615
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
for <bottoms@rockytop.rf.org>; Sat, 14 Sep 2002 01:44:00 -0400
Received: from airborne.nrl.navy.mil (localhost [127.0.0.1])
by airborne.nrl.navy.mil (8.12.6/8.12.6/Debian-4) with ESMTP id g8E5hrEG015308
for <bottoms@rockytop.rf.org>; Sat, 14 Sep 2002 01:43:53 -0400
Received: (from bottoms@localhost)
by airborne.nrl.navy.mil (8.12.6/8.12.6/Debian-4) id g8E5hrQw015305
for bottoms@rockytop.rf.org; Sat, 14 Sep 2002 01:43:53 -0400
Received: from mail1.nrl.navy.mil (smail1.nrl.navy.mil [132.250.1.115])
by airborne.nrl.navy.mil (8.12.6/8.12.6/Debian-4) with ESMTP id g8E5hqEG015300
for <bottoms@airborne.nrl.navy.mil>; Sat, 14 Sep 2002 01:43:52 -0400
Received: from 0.0.0.0 (localhost [127.0.0.1])
by mail1.nrl.navy.mil (8.10.2/8.10.2) with SMTP id g8E5hqg10189
for <bottoms@airborne.nrl.navy.mil>; Sat, 14 Sep 2002 01:43:52 -0400 (EDT)
Received: from atanasoff.rf.org (atanasoff.rf.org [204.29.138.196]) by smail.nrl.navy.mil with SMTP (MailShield v2.04 - SOLARIS/SPARC Jul 18 2001 17:16:48); Sat, 14 Sep 2002 01:43:13 -0400
Received: from monty-python.gnu.org (monty-python.gnu.org [199.232.76.173])
by atanasoff.rf.org (8.12.1/8.12.1/Debian -5.1) with ESMTP id g8E5gQ7m031705
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
for <aa4hs@amrad.org>; Sat, 14 Sep 2002 00:42:48 -0500
Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
by monty-python.gnu.org with esmtp (Exim 4.10)
id 17q5gx-0005EC-00; Sat, 14 Sep 2002 01:42:03 -0400
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10)
id 17q5gI-0005Cw-00
for discuss-gnuradio@gnu.org; Sat, 14 Sep 2002 01:41:22 -0400
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10)
id 17q5g7-0005Bx-00
for discuss-gnuradio@gnu.org; Sat, 14 Sep 2002 01:41:20 -0400
Received: from dsl-65-188-214-229.telocity.com ([65.188.214.229] helo=new.toad.com)
by monty-python.gnu.org with esmtp (Exim 4.10)
id 17q5g4-0005BM-00
for discuss-gnuradio@gnu.org; Sat, 14 Sep 2002 01:41:08 -0400
Received: from toad.com (localhost.localdomain [127.0.0.1])
by new.toad.com (8.11.6/8.11.6) with ESMTP id g8E5exC13710;
Fri, 13 Sep 2002 22:41:00 -0700
Message-Id: <200209140541.g8E5exC13710@new.toad.com>
In-reply-to: <20020913211529.D4716@pig.die.com>
Errors-To: discuss-gnuradio-admin@gnu.org
X-BeenThere: discuss-gnuradio@gnu.org
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:discuss-gnuradio-request@gnu.org?subject=help>
List-Post: <mailto:discuss-gnuradio@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/discuss-gnuradio>,
<mailto:discuss-gnuradio-request@gnu.org?subject=subscribe>
List-Id: GNU Radio, a free software defined radio <discuss-gnuradio.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/discuss-gnuradio>,
<mailto:discuss-gnuradio-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/discuss-gnuradio/>
X-Scanned-By: MIMEDefang 2.19 (www . roaringpenguin . com / mimedefang)
From: John Gilmore <gnu@toad.com>
Sender: discuss-gnuradio-admin@gnu.org
To: die@die.com (Dave Emery), discuss-gnuradio@gnu.org
Cc: cryptography@wasabisystems.com
Subject: Re: [Discuss-gnuradio] SDR Forum Report on Security
Date: Fri, 13 Sep 2002 22:40:59 -0700
http://www.sdrforum.org/public/approved/02_a_0003_v0_00_fcc_rpt_08_31_02.pdf
Thanks to Dave Emery for pointing us at this report.
This 121-page report on "How to secure Software Defined Radios",
written to help the FCC decide how to handle software radios, is very
slanted toward monopoly-industry viewpoints. The whole focus is on
giving the system operator lots of flexibility to do whatever they
want, while giving customers, experimenters, competitors, and citizens
zero flexibility or opportunity. They managed to suppress the few
pages of actual information about the paucity of any actual threat to
public safety (see last paragraph of this review).
The document reminds me of those eco-terror reports about how the
world is falling to shit (whether it really is or not). On the page
numbered 14 at the bottom (page 21 in the PDF -- I wish Adobe could
get this straight), it says:
The impending widespread use of software changes, whether to add or
improve user services or to reconfigure RF parameters of a wireless
device, presents substantial new challenges to manufacturers and
operators, particularly in the face of a youthful "digital generation"...
Having a whole generation of young people grow up full of knowledge
about engineering, computers, and networking is a wonderful advance in
the state of humanity. The authors of the paper apparently see it as
a drawback, since they depend on their customers being ignorant.
The report pays little attention to the huge opportunities offered by
separating the development of hardware from the development of
software. If you look at the history of computers, the people who
built great hardware tended to suck at software. The people who built
great communications hardware built the worst networking software.
IBM mainframes are the most obvious example in computers. Not only
the PC, but the 1970's minicomputer and the 1980's engineering
workstation were great examples of how open hardware could allow
software innovation to flourish.
Welded-shut systems tend to be terrible, compared to the innovation
and cost reduction available in systems where one vendor supplies
hardware, another supplies more plug-in hardware, and four or five
more supply various bits of software (the OS, the applications, custom
scripting, etc). The Bell System telephone is the obvious example of
a welded-shut system that it took a 1950's FCC decision to open (the
Carterfone decision), unleashing vendors to supply *modems* which
permitted *data* traffic which permitted *computer-mediated
communication* and eventual *networking*, eventually creating the
public *internet* about forty years later. The US got a head start in
creating the Internet because of the Carterfone decision and
subsequent decisions on access to leased lines, while almost every
other country's telephones were still run by a monopoly PTT whose
interest was in preventing competing forms of communication.
Today's cellphones and Cable TV systems are similarly welded shut,
resulting in endless lock-in that profits the vendors while beggaring
the society; they provide only the minimal amount of innovation that
keeps the vendors alive. (As a small example, there's still no decent
mobile data networking; the one company that temporarily provided it,
Metricom, grew out of the ham radio fraternity rather than the
cellphone companies.)
The report's focus on "Wireless Threats" is obsessive about threats to
their revenue models or to their "systems" or their control. For
example, a software modification that would permit cellphones to talk
directly to each other when in range of each other, without the use of
a base station or its network, would be considered a threat to the
integrity of the system ("unauthorized access to services"). However,
it would be considered a positive feature by end users, who would be
happy to pay third parties to write such software; it would serve more
total users by reusing the spectrum locally; etc.
A really useful SDR communication device would have a jack that would
take either an Ethernet or a phone line; if neither was plugged in, it
would look for 802.11 local connectivity, or Metricom wide-area
connectivity, or its own networking protocol if any similar station
was in range, or failing that, would be able to use a terrible and
expensive cellular data or voice network. All of this would be
transparent to the user. None of the vendors who authored this report
would ever build such a device, because the majority of the time it
would not force users to pay them by the minute. And user or
competitor attempts to reprogram existing devices to do this, or any
part of it, would be warded off as "attacks" by "malicious hackers".
The report is followed by the individual company reports that were
submitted to it. They make interesting if duplicative reading, since
they reveal that the whole SDR Forum report just seems to be a
stitching-together of the most self-serving parts of the documents
submitted by various companies.
Wow! There's even an Appendix H (PDF page 100) that is a verbatim
copy of a Digital Restrictions Management report from the Copy
Protection Technical Working Group, which talks about how "Securing
adequate protection for copyrighted works in the digital environment
will allow development of viable business models. Viable business
models will in turn help drive adoption of broadband ... and expanded
consumer choices ..." Of course, it's full of horseshit; DRM is all
about preventing UN-VIABLE monopoly business models from going extinct
when they have been obsoleted by technology. This is even the report
that talks about how the "broadcast flag" will save digital broadcasts
that happen "in the clear". It's particularly incongruous in a report
full of glowing public-key crypto recommendations.
PDF page 102 is a great overview of some companies that deserve
cypherpunk scrutiny. E.g. "Signum Technology" provides iPak that lets
you print packaging labels with "sophisticated invisible watermarking
that allows incorporation of hidden identifying data" which can be
revealed "in a matter of seconds" with "an inexpensive scanning
device".
The report in general also follows the "academic paper" model of
security: See, we're using public key algorithms. Therefore our
systems will be secure. The impact of bugs, protocol design failures,
social engineering, breach of trust, undersized keys, revelation or
government appropriation of private keys, etc, are all ignored.
On page 8 (PDF 15) it mischaracterizes the problems with 802.11 and
WEP. First, it leads off with Adam Stubblefield's break of WEP --
failing to start with the 30-year history of trivial-to-crack wireless
network protocols that were built under the guidance of the FCC and
with active help and legal threats by the National Security Agency.
WEP uses 40-bit keys because they were the largest available in
exportable products until EFF's lawsuit cracked the unconstitutional
export controls. Securing wireless networks has always been a second
priority to making it trivial for the government to illegally wiretap
them. This tension isn't going to go away.
Second, its 802.11 discussion directly lies that the popular practice
of recreational listening for open wireless networks results from the
ability to crack WEP-secured networks -- rather than the public's
tendency to leave 802.11 networks unsecured because the industry and
the vendors only provided painful hand-configured ways to secure them.
I know of no "wardriving" that seeks and cracks WEP-secured nets; it's
all merely probes for networks that people have left open, either by
default or by intent. (The idea that someone would intentionally
PERMIT the nearby public to freely use their wireless network
infrastructure is apparently heresy to the authors of the report.)
The report also looks approvingly on digital-restrictions-management
systems (DRM) as the solution. E.g. no SDR will be able to run code
unless it has been digitally certified by the vendor. Like every
other restrictions-management system, this will be deliberately used
to cement established monopolies and prevent innovation. It even rates
part of the "threat model" consequences as "Digital Rights Violation" --
defined not as a violation of the user's rights or privacy, but as
"unauthorized access to, or theft of, digital content and software".
The report's focus is also inappropriately largely focused on
"cellphones". It reminds me of a Motorola emp who told me in the
early '90s "car phone" era that offering wireless data networking
would be irresponsible because "you should keep your eyes on the
road", implying that (1) only people in cars would want wireless data
networking, and (2) they would use it while driving. This tunnel
vision mindset doesn't enable the authors to notice that everything
from car alarms to shipping crates to pets to ballpoint pens to
automotive light bulbs already today, or soon will, come with data
networking built in. Software-defined radios will be broadly useful
throughout society, not just for "cellphones" but for
****everything****. So if the "SDR Forum" or the FCC denies society
the benefits of rapid innovation, they won't just be denying it to
cellphone users, but to auto owners, package shippers, pet owners,
doctors, writers, lightbulb users, and everyone else.
Page 23 (PDF 30) jocularly reports that "Eavesdropping on user data
(Breach of security, public safety has some experience in this
scenario)". I think they meant that they have some experience being
intercepted, but of course "public safety" agencies systematically
intercept private citizen communications. The report goes on to
suggest that:
Sophisticated encryption techniques should be made available to public
safety users of SDR technology. AES voice encryption and 128-bit data
encryption should be considered minimum standards for public safety
SDR devices. Devices can be lost or stolen and, therefore, must be
capable of remote revocation of service.
One would hate for the *citizens* to get access to AES voice
encryption or 128-bit data encryption, therefore we had better only
give those devices to cops, and "remotely revoke" them if they leak
outside the Government Trust Barrier to ordinary untrustworthy voters
or citizens.
Page 25 (PDF 32) lauds the "Trusted Computing Platform Alliance",
Intel's fuck-the-customers-for-Hollywood initiative, as being a model
for SDR companies to follow. As usual, they completely obscure the
critical question, which is "Who trusts who?". Their "Trusted"
systems are trusted by monopolists to not be susceptible to
unauthorized competition. This word game deceives people who
foolishly think they're trying to build "systems the consumer can trust".
Page 29 (PDF 36) even pushes the "NTRUEncrypt" snake oil encryption system.
Page 30 and 31 (PDF 37 and 38) discuss GSM security, without bothering
to mention that they kept their snake oil algorithm secret for years
so that consumers would not find out how insecure it was. It bleats
that the "Security Group has realized two important initiatives over
the past 12 months": introducing AS/3 to replace the faulty algorithms,
and a protocol for "authenticated key agreement", AKA. Until I hear
differently, I'll assume that these are both more proprietary snake oil.
On page 34 (PDF 41) their prime example of how "public safety" users
need priority and reliability is "best illustrated by the SWAT team
commander notifying the sniper with the 'shoot' or 'don't shoot'
command". Given the number of SWAT teams deployed against innocent
civilian drug users, such as the raid on terminal cancer patients made
in Santa Cruz last week by just such a machine-gun-toting SWAT team,
this is an insulting example. Cops need good communication to know
whether they've been ordered by a corrupt higher official to shoot a
citizen from concealment. I see.
Page 40 (47) goes so far astray as to say:
"As a multitude of products and services still uses proprietary
solutions there is no advantage to using secure standards which only
give extra security if everyone else offers them."
The next page points up the monopoly control problem in wireless cellular
networks as a positive feature:
5.2.2 Asymmetry of Information
Unlike the general IT situation where there is varying levels of
control over client devices attached to a network; from closely
controlled private networks, to no control of devices connected to
the internet; commercial handsets must be qualified to operate on an
operators network before they are allowed to connect. Therefore
operators have complete control over the capabilities of devices
they allow to connect to their network. As such there is no
asymmetry of information in the case of handsets deployed on an
operators network.
The report then concludes without saying much more than these terrible
things.
But then come a bunch of interesting submissions from various
companies. Intel's reveals the source of the TCPA paragraphs (copied
directly from Intel propaganda). It again skips over the REASON why
802.11 is insecure, and fails to mention the real cure (standardized
mass-market end-to-end encryption, which is politically disfavored
since it discourages wiretapping).
The paper from the "Mobile Virtual Center of Excellence" in the UK at
least makes explicit the authoritarian model that's implicit
throughout the rest of the document (PDF page 64):
Domains and regulatory bodies. We suppose that the world is divided
into an number of administrative domains, which may correspond to
single nations (e.g. the USA), or groups of nations (e.g. the EU).
In some cases, it may also be the case that nations are sub-divided
into separate domains. Each domain is assumed to have a single
regulatory body, responsible for deciding which software is permitted
to be downloaded and executed in SDR platforms.
Which software citizens will be permitted to download or execute.
What a fascist concept.
The MVCE proceeds on page PDF 71 to say, "Also, issues relating to Digital
Rights Management (DRM) may arise, i.e. where the SV restricts use of
code modules to enforce payment for these modules."
Motorola's submission (PDF pg 74) seemingly ignores Kevin Mitnick's
penetration of North Carolina cell site software, well documented
in several books, when it says:
The data links which connect the OMC to the cell sites are private
data networks controlled by the network operators, and offer no entry
point for remote hackers. Furthermore, there is no internet or other
publicly accessible external data connection into the OMC. The
inherent security of base station equipment is demonstrated by the
fact that second generation (2G) commercial base stations are remotely
programmable, and have been operating in high volume for over ten
years without any significant security issues. The focus of this
report, therefore, will be on security issues surrounding commercial
handsets.
Sorry, Kev, you were insignificant.
The Moto document also has a 5-page slideshow tutorial on encryption,
for the braindead who have nevertheless managed to read that far. (PDF 77)
The Moto document is the source of the "Security Threat Model" that
included that "Digital Rights Violation" example above, and "Example
Threat Scenarios" that are almost uniformly "hacker", "black market",
"unethical", or "disreputable" parties modifying the system. (In one
example, an "inadvertent" bug does not bring the repute or ethics of
the creator into question, presumably since Motorola would be the
originator of the bug.) There's no example of beneficial improvements
made by third parties; of experimentation by scientists or university
students; of innovation by competitors. The system is designed to block
all those things.
Motorola's document surprisingly honestly says that security systems
should be designed to work even when the entire design is known to
opponents (page PDF 83). But then on page PDF 89 it argues for snake
oil, which has served the wireless industry so well in the past:
Finally, it should be stressed that the very nature of the security
challenge is that the "threat" is ever changing. Malicious hackers
make it their business to try and decode the security systems designed
to thwart their unscrupulous efforts. Therefore, regulatory mandate
of specific security methods would be counterproductive. To do so
would provide a blue print for the malicious hacker, and would impede
the industry's responsiveness to an ever-changing security landscape.
Clearly, anyone who might want to put software of their own choice
onto the equipment they have purchased is "malicious" and
"unscrupulous" rather than "an honest competitor" or "a customer".
And we can't have the laws merely say what is required, or that would
provide a "blue print" for people who want to do something else.
The only really sane part of the Motorola document is the page and a
half at PDF 86, which says how tiny the "SDR security threat" really
is. Basically it says that people who design mobile radio gear are
operating in a very tight design space and aren't going to put in a
whole lot of expensive flexibility that would allow operation in
multiple frequency bands, massive increases in output power, etc.
I.e. the whole inquiry is basically a sham. This sensible part of the
language never made it into the final report of the SDR Forum, though.
Typical.
John Gilmore
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://mail.gnu.org/mailman/listinfo/discuss-gnuradio
--RuwM0md9lt--