Risks Digest 23.27

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Tuesday 16 March 2004  Volume 23 : Issue 27

   FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at http://www.risks.org as
  http://catless.ncl.ac.uk/Risks/23.27.html
The current issue can be found at
  http://www.csl.sri.com/users/risko/risks.txt

  Contents:
DARPA robot race is a bust (NewsScan)
Re: DARPA robot race (PGN)
Can Software Kill? (Debbie Gage and John McCormick via Dan Scherer)
P2P legal defense by separation of content and key? (Brent J. Nordquist)
PPI delayed by "computer problems" (Bill Hopkins)
Microsoft Word reveals document's author -- again (George W. Harris)
Lost e-votes could flip Napa County race (PGN)
California voters turned away (PGN)
Googling Up Passwords, Scott Granneman excerpt (Monty Solomon)
SSL is being severely stressed by phishing expeditions (Alistair McDonald)
When is a decimal point not a decimal point? (Darryl Smith)
Merger Mania (Mike Albaugh)
New twist to social engineering in virus transmission (John Sawyer)
Re: An interesting airplane user interface (A.M. Passy)
People are not as conservative as some think! (Jonathan de Boyne Pollard)
Re: Buffer overflows (Mike Albaugh)
2004 IEEE Symposium on Security and Privacy (Steve Tate)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Mon, 15 Mar 2004 09:14:24 -0700
From: "NewsScan" <newsscan () newsscan com>
Subject: DARPA robot race is a bust

The highly touted robot race staged by the Pentagon in an effort to boost
R&D in driverless vehicles has ended with all 15 self-navigating devices
petering out within a few miles of the starting gate -- victims of technical
glitches, barbed wire fences and rough terrain. The Defense Advanced
Research Projects Agency had spent $13 million on its Grand Challenge, which
offered a $1 million prize to the creators of the vehicle that could
complete a 150-mile race across the Mojave Desert within 10 hours. Team
members were not allowed to touch or steer the vehicles and most of the
robots stalled, overturned, or ran off the course shortly after taking
off.  Defense officials foresee using such autonomous robotic vehicles to
ferry supplies in war zones.  [AP 15 Mar 2004: NewsScan Daily, 15 Mar 2004]
  http://apnews.excite.com/article/20040315/D81AQ3M00.html

------------------------------

Date: Tue, 16 Mar 2004 11:12:14 PST
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: Re: DARPA robot race

For RISKS readers, it should be no surprise that none of the competitors got
very far in the first robotic Grand Challenge of such scope.  This challenge
is a fine example of an *overall system* problem where *everything* counts,
not just mechanical and electrical robustness, software reliability, fault
tolerance, vision processing, incredible foresight in choosing system
requirements, good software engineering, sound programming languages, design
for survivability, etc., but also real-time awareness of and reactiveness to
the surrounding physical and logical environments.  Furthermore, security
was not even a concern this time around -- although it would be absolutely
critical in any real military deployment.  In actual battle conditions,
defending against and responding to all sorts of denial- of-service attacks
would have to be in scope, including electromagnetic jamming, remote
penetrations, sabotage, and so on.  (Here, each vehicle had a remote manual
trigger that would cause it to halt in case human lives -- or even a
protected tortoise -- were about to be threatened.  Of course, such a
safety-contingency mechanism could also be potentially misused by
competitors, although I presume there might have been rules against such
actions in this case -- or at least suppositions that an eventual winner
might be disqualified for having engaged in such tactics.)

Knowing what we know about RISKS and human frailty, I am always concerned
about people overendowing a sense of operational certainty toward fully
automated vehicles.  (For example, think about the completely automated
highway and what might happen in the event of noncompliant participants or
unanticipated events.)  At any rate, the prize remains a Grand Challenge for
the future -- or, actually, a kilogrand Grand Challenge, because *one grand*
is *one thousand dollars*.  (Note for foreign readers: American slang!)
Incidentally, after commenting on watching the event, Paul Saffo called it
``Woodstock for Warlords''.  PGN

------------------------------

Date: Wed, 10 Mar 2004 00:46:58 -0800
From: "Dan Scherer" <dans () oz net>
Subject: Can Software Kill?  Debbie Gage and John McCormick, Baseline

An article out at eWeek.com that RISKS readers can relate to all too well:
http://www.eweek.com/article2/0,1759,1543652,00.asp?kc=EWNWS030804DTX1K0000599

It reviews the risks of software/human interactions that have lead to
injuries or death of the human component of the equation.  A fairly
comprehensive summary of what has been covered here many times in the past.

------------------------------

Date: Tue, 16 Mar 2004 15:55:11 -0600
From: "Brent J. Nordquist" <brent () nordist net>
Subject: P2P legal defense by separation of content and key?

Bruce Schneier's CRYPTO-GRAM for March 2004 had a pointer to this
article: http://zdnet.com.com/2100-1104_2-5164413.html  from which
I quote:

  Spanish developer Pablo Soto, whose Blubster and Piolet software have
  attracted several hundred thousand users, is taking a decidedly different
  tack. [...]

  Information such as an MP3 song will still be downloaded from its original
  source, he said. But a song will be scrambled, and downloaded simply as
  raw, unintelligible data. This means that no actual copy of a song is
  being exchanged, he contends.

  If downloaders want to turn that data into usable music, their software
  must seek elsewhere on the file-swapping network for the encryption "keys"
  that will unlock the data, transforming it back into an MP3. Separating
  the download of the data and the keys may help protect file sharers from
  lawsuits, making it more difficult for courts to say exactly which party
  is responsible for copyright infringement, Soto said.

This reminded me immediately of my favorite RISKS article, "The source of
semantic content" (Gat, RISKS-16.87).  Perhaps Gat's questions "Has the law
been broken?  Who broke it?" will soon be tested in court.

------------------------------

Date: Fri, 12 Mar 2004 14:05:31 -0500
From: "Bill Hopkins" <whopkins () wmi com>
Subject: PPI delayed by "computer problems"

The Bureau of Labor Statistics (BLS) has been unable to compute the Producer
Price Index (PPI) for January or February due to delays in implementing a
change in the way data is organized.  The switch of the industry
classification system used has already been done for most BLS data,
according to a Reuters report, but the "PPI had to remap some 40,000
industry units and about 120,000 items before re-aggregating the data into
four indexes" in the PPI.  The assistant commissioner responsible for the
PPI said "God knows when" the January numbers will be out.  He blamed "aging
computers" which could not handle a dry run before pulling the plug on the
old system, and "30-year-old systems" that are not conversion-friendly.

The PPI measures wholesale prices and is an early indicator of inflationary
trends, future corporate profitability and hiring, etc.  A report on public
radio's morning MarketPlace Report on Friday March 12 alluded to business
contracts with prices based on the current PPI.

Source: Reuters, "U.S. Blames Aging Computers for PPI Delay" by Andrea
Hopkins (no relation), 9 Mar 2004, found on Yahoo.  

  [Andrea may be no direct relation, but Bill may have many other
  one-hop-kins-men.  PGN]

------------------------------

Date: Tue, 16 Mar 2004 03:04:32 -0500
From: "George W. Harris" <gharris () mindspring com>
Subject: Microsoft Word reveals document's author -- again

California's Attorney General circulated a document to fellow state
attorneys general outlining a strategy for a legal attack on the makers of
peer-to-peer software.  However, the document was in Microsoft Word, and the
metadata revealed that the document's actual author was "stevensonv",
apparently Vans Stevenson, the MPAA's Senior Vice President for State
Legislative Affairs.
  http://www.wired.com/news/digiwood/0,1412,62665,00.html?tw=wn_tophead_1

------------------------------

Date: Mon, 15 Mar 2004 13:45:11 PST
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: Lost e-votes could flip Napa County race

One Sequoia Optech electronic machine used to count optical-scan paper
absentee ballots in the 2 March 2004 California primary in Napa County
failed to record votes on some ballots.  This was detected by chance in a
random 1% recount.  As a result, the county will re-scan over 11,000
ballots, which could possibly change the results of some close local races.
The machine was miscalibrated to detect carbon-based ink, but not dye-based
ink commonly used in gel pens.  (The pre-test was done only with
carbon-based ink.)  [Of course, the random test might not have noticed other
machines that were similarly miscalibrated.  PGN]

Kim Alexander said the county was lucky that the problem occurred on a
system with a paper trail.  "If the problem had occurred with their
electronic ballots or with the tabulation software (which sits on the County
server), they would have been hard pressed to reconstruct their election.
Or, they might not have ever known there was a problem at all.  If they were
doing the manual count on the electronic ballots there would be no record to
look at to determine what the accurate vote count should be."
[Source: Kim Zetter, Wired News, 12 Mar 2004; PGN-ed]
  http://www.wired.com/news/politics/0,1283,62655,00.html

------------------------------

Date: Mon, 15 Mar 2004 13:45:11 PST
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: California voters turned away

In the 2 March 2004 California in Alameda and San Diego Counties, some
voters were delayed or turned way from polling places.  In Alameda County,
about 200 of their 1,096 voting precincts experienced problems with the
precinct-control module encoder machines that provide voters with an access
card for Diebold touch-screen machines.  Some voters were able to fill out
provisional paper ballots.  However, apparently many voting places ran out
of paper ballots, and voters were turned away in at least 25 polling places.
[Sources: Ian Hoffman, Electronic-voting machine snafus leave votes in limbo
*The Argus* (Fremont, CA), 4 Mar 2004, and Thomas Peele and Sam Richards,
Voters turned away by encoder problems, *Contra Costa Times*, 12 Mar 2004;
PGN-ed.]

The Argus article had this quote: Alameda County elections officials ``were
swamped Tuesday morning by some 200 calls for help from poll workers in all
parts of the county.  Diebold representatives said part of the problem
seemed to be a low battery charge in the voter-card encoders, causing them
to boot up into an unfamiliar Windows screen.''

As we noted earlier (RISKS-23.07), in the 17 counties in which Diebold
systems were used, none of the versions of those systems actually used was
the version that had been certified.

There were numerous reports in the past weeks of malfunctions and
irregularities elsewhere as well.  I would have to spend more time than I
have to catalogue them all in RISKS.  But I think you get the idea from what
we have included here that there are vastly too many problems that could
influence the results of close elections, often with no recourse to find out
what was really intended.

------------------------------

Date: Fri, 12 Mar 2004 00:45:13 -0500
From: Monty Solomon <monty () roscom com>
Subject: Googling Up Passwords, Scott Granneman excerpt

Google is in many ways the most useful tool available to the bad guys, and
the most dangerous Web site on the Internet for many, many thousands of
individuals and organizations.

By Scott Granneman, 9 Mar 2004

In my last column, I provided a checklist for Windows users that would help
them secure their computers. I created that checklist because it has become
increasingly and painfully obvious to me that most home users -- and most
small businesses and organizations -- have substandard security practices in
place, if they have any at all. The checklist was designed to help secure
things on the perimeters: on client computers and at the edges of home and
business networks. This week, I want to talk about servers.

Specifically, let's talk about the stuff that people are serving without
realizing it. Security pros have known about this problem for years, but
most computers users still have no idea that they may be revealing far more
to the world than they would want. In fact, it wouldn't be far from the
truth to say that Google is in many ways the most useful tool available to
the bad guys, and the most dangerous Web site on the Internet for many, many
thousands of individuals and organizations.  [...]
  http://www.securityfocus.com/columnists/224

------------------------------

Date: Tue, 9 Mar 2004 20:30:34 -0000 (GMT)
From: "Alistair McDonald" <alistair () inrevo com>
Subject: SSL is being severely stressed by phishing expeditions

Netcraft reports that phishers are using real and fake SSL certificates to
fool computer users into thinking that they are using the site they hope to
be using instead of the phisher's site.

The report is here:
  http://news.netcraft.com/archives/2004/03/08/
  ssls_credibility_as_phishing_defense_is_tested.html
and is worth a read even if, like me, you've been a regular RISKS reader for
years. The phishers must be on to something, as they are putting a lot of
research and effort into this scam.

One thing I didn't know: SSL allows a "plain text" encoding, that doesn't
require a signed certificate, yet browsers show a locked padlock as a site
using encryption would display.  I'm not sure whether I should whack the
browser authors, the SSL implementors or the SSL designers on the head for
this.

My advice on phishing avoidance: never click on a link in an e-mail from a
financial institution, always navigate from a bookmark. If possible, avoid
typing in web addresses too, in case you misspell and a phisher has taken
the misspelled site hoping to catch unlucky typists. And never, ever use a
public terminal such as in a cyber cafe or library to enter *any* password
at all, due to physical or software keyboard sniffers.

Alistair McDonald    +44 (0)7017-467386  http://www.inrevo.com

------------------------------

Date: Thu, 11 Mar 2004 23:40:51 +1100
From: "Darryl Smith" <Darryl () radio-active net au>
Subject: When is a decimal point not a decimal point?

As part of a hobby, I write vehicle tracking software that plugs into cheap
external mapping software to create an entire application without me needing
to worry about dealing with maps - I just need to tell the mapping program
where to display positions, and it just goes and does it.

Now, I use two interfaces to the mapping software - one using API calls
sending the positions as parameters of the API call for adding points to the
map. The second interface involves creating a dummy GPS data line (starting
with $GPRMC), and sending this to the application for use with the moving
map functions.

In the last few days I have been exchanging e-mail with a user in Canada who
has been complaining that the positions on the map for the mappoint are
correct at about 48N and 71W, whereas the moving map functions are saying
about 80N and 0W. Of course the points should be identical.

My software sends the mappoint through the API, and then generates and sends
the fake GPS position. The software is written in Visual Basic version 6.
Some of my code appears below.

  lat = Abs(lat)
  nmeastring = Format(Int(lat), "00")
  lat = lat - Int(lat)
  lat = lat * 60
  nmeastring = nmeastring & Format(lat, "00.000")

On most systems this correctly encodes the latitude into degrees followed by
decimal minutes.

Unfortunately on systems where the locale has been changed to have a comma
as a decimal place, then Visual Basic ignores the fact that I have
specifically stated that I want to use a decimal point when I format the
number into a string, and changes it to a comma. To be fair to Microsoft
this is listed in the manual Visual Basic 6.

Of course since the NMEA sentence I am generating uses commas as field
delimiters, the fields are getting totally messed up. And the mapping
software is making its best effort to display the obviously incorrect
position.

The risk: using the same character to denote decimal places as for denoting
different fields is not a good idea.

Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
www.radio-active.net.au - www.radio-active.net.au\web\tracking

------------------------------

Date: Tue, 9 Mar 2004 09:20:52 -0800 (PST)
From: albaugh () spies com
Subject: Merger Mania

My bank has decided that two trusts for which I am a trustee are in fact
"the same", despite being "for the benefit of" different individuals, and
having different Taxpayer Identification Numbers. Or, at least, the trusts
have different TINs, and the accounts _used_ to have different TINs, but the
first of two lines on the bank's forms is the same for the two trusts, and
my address is, naturally, the same for both, and that's "close enough" for
them to decide to report all income for both trusts as being paid to one
TIN.

I am now at four weeks calendar time, four hours phone-log time directly
interacting with them, and three forms signed in duplicate. So far, all it
has gotten me is that they issued _another_ 1099 (report to the IRS of
interest paid), now reporting all income to the _other_ TIN.  Plus an
oddly-formatted (no spaces between words) e-mail claiming that they would
"take care of it and issue another 1099" (note: _an_other, I shudder to
think...) Meanwhile, April 15th is closer than it appears...

Risks? Obviously, someone, or something, at the bank was able to change the
TIN on an account without the permission, or even notification, of the
account holder.  Yet enormous effort is required (so far unsuccessfully) to
correct the mistake. This scheme (easy to break, hard to fix) is
breathtakingly wrong.

I would go to another, perhaps more competent bank, but every time I do,
they get bought by the likes of these incompetents. Hence the double meaning
to "Merger Mania".

------------------------------

Date: Fri, 12 Mar 2004 08:49:34 +0000 (GMT)
From: John Sawyer <jpgsawyer () btopenworld com>
Subject: New twist to social engineering in virus transmission

It seems that the Beagle virus is doing the rounds again with a new
interesting twist to the social engineering used previously. In this case it
seems to send you an e-mail saying that your mailing system will be out of
action for two days and to follow the instructions in the attachment.

> Dear user of "Btopenworld.com" mailing system, Our main mailing server
> will be temporary unavailable for next two days, to continue receiving 
> mail in these days you have to configure our free auto-forwarding service.
>
> For further details see the attach.
>
> Cheers,
>     The  Btopenworld.com team
> http://www.btopenworld.com

It's fairly transparent to RISKS readers, but to someone less savvy it might
seem quite plausible.  Of course, given btopenworlds recent conjoining of
its services with Yahoo! and the confusion that caused some users, people
should be forgiven if they fall for this.  The risk of a well-timed and
well-written e-mail of this sort should not be underestimated.

------------------------------

Date: Sun, 14 Mar 2004 23:07:10 -0600
From: "A.M. Passy" <marc () passy us>
Subject: Re: An interesting airplane user interface (Magda, RISKS-23.26)

> With the multitude of gauges in a cockpit this is a brilliant way to
  quickly scan the status of the various components of the airplane.

This should not be remarkable, and it is certainly not original.  When I
served aboard Nuclear Submarines more than 10 years ago, all the instruments
in the Engineering control room were designed such that at roughly normal
operation, all needles pointed up (all analog instruments).  There were a
few that weren't pointing up, due to their nature -- we used to talk about
the Beauty of analog -- you could take a mental "picture" of normal, and
identify off-nominal very rapidly, much more so than if you had to process
each number.

In the 1980s, the B-1 Lancer bomber was remarkable for a similar
"innovation" -- they used LED bargraphs lined up next to each other for
engine instrumentation, and when all was normal at cruise, there was a
straight line across several (~10, I think) instruments.

------------------------------

Date: Thu, 11 Mar 2004 11:14:44 +0000
From: Jonathan de Boyne Pollard <J.deBoynePollard () Tesco NET>
Subject: People are not as conservative as some think! (Re: Maziuk, R 23.21)

DM> On the other hand, there's no reason to believe anyone will rush to
DM> implement new and improved SMTP when/if ever that comes along.

It is "when", not "if ever".  Two projects for replacing SMTP-based Internet
mail, IM2000 and "mail-ng", exist right now.

DM> nobody's in a hurry to switch to IPv6, are they?

Actually, IP version 6 is a good example, because it is a bad example.  It
doesn't actually support that point at all.  In a U.S.-centric view of the
world, perhaps nobody is in a hurry to implement IP version 6.  But there
are other parts of the world that are quite enthusiastic about implementing
it, because they are significantly inconvenienced by IP version 4.

The same is true of a replacement for SMTP-based Internet mail.  There will
be those who, because they have reached the stage where SMTP-based Internet
mail is simply unusable, will be enthusiastic about adopting a suitable
replacement.

------------------------------

Date: Thu, 4 Mar 2004 19:13:45 -0800 (PST)
From: Mike Albaugh <albaugh () spies com>
Subject: Re: Buffer overflows (Quayle and Hopkins, RISKS-23.24)

> From: "Stanley F. Quayle" <stan () stanq com>
> Subject: Re: Buffer overflows and VMS

> C programmers moving to OpenVMS quickly discover what the ACCVIO error
> message means.

BTW: SYS III Lint core-dumped when I first ran it on itself, under VMS :-)

> From: "Bill Hopkins" <whopkins () wmi com>
> Subject: Re: Buffer overflows and Burroughs/Unisys

> Since C's memory abstraction is basically the hardware address, and
> addresses can be manipulated arbitrarily, [...]

Anybody else note the dissonance here? In fact the C language, while not as
"tight" as, e.g. Ada, does provide sufficient opacity of pointers to
accomplish pretty good bounds-checking. Of course, not much "alleged C" code
would run on such a system. I submit it is _because_ too many implementors
accepted the notion that "C has pointers that are no more than tarted-up
machine addresses" and didn't even consider implementing _real_ C pointers
on machines which would support them. The original "oh, cut them some slack"
led to a generation of programmers who actually believe such dreck as
"packed structs" and "result of a cast is a modifiable lvalue" _is_ part of
C.

The risk: If you take a sufficiently dim view of your ability to enforce
language specs, and give up at the start, you'll get, well, the current
situation, and risks...

------------------------------

Date: Tue, 9 Mar 2004 09:18:43 -0600 (CST)
From: Steve Tate <srt () cs unt edu>
Subject: 2004 IEEE Symposium on Security and Privacy

             2004 IEEE Symposium on Security and Privacy
    May 9-12, 2004, The Claremont Resort, Oakland, California, USA
                             sponsored by
  IEEE Computer Society Technical Committee on Security and Privacy
                         in cooperation with
    The International Association for Cryptologic Research (IACR)

For more information, see http://www.ieee-security.org/TC/SP-Index.html
For registration, see http://www.cics.unt.edu/ieeereg/register.php
[Info on registration/local arrangements at www.ieee-security.org.]

Monday MORNING

Session:  Attacks and Defenses
* Keyboard Acoustic Emanations, Dmitri Asonov, Rakesh Agrawal (IBM Research)
* Effects of Mobility and Multihoming on Transport-Protocol Security
  Tuomas Aura (Microsoft Research), Pekka Nikander (Ericsson Research),
  Gonzalo Camarillo (Ericsson Research)
* Analysis of an Electronic Voting System
  Tadayoshi Kohno (UC San Diego), Adam Stubblefield (Johns Hopkins Univ.),
  Aviel D. Rubin (Johns Hopkins Univ.), Dan S. Wallach (Rice Univ.)

Session:  Theory of Access Control
* Access Control By Tracking Shallow Execution History
  Philip W. L. Fong (U. Regina)
* A Layered Design of Discretionary Access Controls with Decidable
  Safety Properties, Jon A. Solworth, Robert Sloan (U. Illinois, Chicago)

Monday AFTERNOON

Invited Talk

Session:   Cryptography
* Symmetric encryption in automatic analyses for confidentiality against
  active adversaries, Peeter Laud (Tartu University)
* Automatic Proof of Strong Secrecy for Security Protocols
  Bruno Blanchet (Ecole Normale Superieure)

5-minute work-in-progress talks

Tuesday MORNING

Session:  Denial of service
* An empirical analysis of target-resident DoS filters
  Michael Collins (CERT), Michael Reiter (CMU)
* Large-Scale IP Traceback in High-Speed Internet: Practical Techniques
  and Theoretical Foundation, Jun Li, Minho Sung, Jun (Jim) Xu (Georgia Tech),
  Li (Erran) Li (Bell Labs)
* An Endhost Capability Mechanism to Mitigate DDoS Flooding Attacks
  Abraham Yaar, Dawn Song, Adrian Perrig (CMU)

Session:  Access Control and Privacy
* Safety in Automated Trust Negotiation
  William H. Winsborough (George Mason Univ.), Ninghui Li (Purdue Univ.)
* Securing OLAP Data Cubes Against Privacy Breaches
  Lingyu Wang, Sushil Jajodia, Duminda Wijesekera (George Mason Univ.)

Tuesday AFTERNOON

Panel Session

Session:  Static Analysis
* Run-time Principals in Information-flow Type Systems
  Stephen Tse, Steve Zdancewic (U. Pennsylvania)
* Formalizing Sensitivity in Static Analysis for Intrusion Detection
  Henry Hanping Feng (U. Mass., Amherst), Jonathon T. Giffin (U. Wisconsin,
  Madison), Yong Huang (U. Mass., Amherst), Somesh Jha (U. Wisconsin
  Madison), Wenke Lee (Georgia Tech.), Barton P. Miller (U. Wisconsin Madison)

Wednesday MORNING

Session:  Network Security
* Fast Portscan Detection Using Sequential Hypothesis Testing, Jaeyeon
  Jung (MIT), Vern Paxson (ICIR), Arthur W. Berger, Hari Balakrishnan (MIT)
* On-the-Fly Verification of Rateless Erasure Codes for Efficient Content 
  Distribution, Maxwell N. Krohn (MIT), Michael J. Freedman,
  David Mazieres (NYU)
* Multicast Authentication in Fully Adversarial Networks
  Anna Lysyanskaya, Roberto Tamassia, Nikos Triandopoulos (Brown Univ.)

Session:  Security Against Physical Attacks
* An Interleaved Hop-by-Hop Authentication Scheme for Filtering False
  Data Injection in Sensor Networks, Sencun Zhu, Sanjeev Setia,
  Sushil Jajodia (George Mason Univ.), Peng Ning (NC State Univ.)
* SWAtt: Software-based Attestation for Embedded Devices, Arvind Seshadri,
  Adrian Perrig (CMU), Leendert van Doorn (IBM and CMU), Pradeep Khosla (CMU)

------------------------------

Date: 28 Jan 2004 (LAST-MODIFIED)
From: RISKS-request () csl sri com
Subject: Abridged info on RISKS (comp.risks)

 The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.  Alternatively, via majordomo,
 send e-mail requests to <risks-request () csl sri com> with one-line body
   subscribe [OR unsubscribe]
 which requires your ANSWERing confirmation to majordomo () CSL sri com .
 If Majordomo balks when you send your accept, please forward to risks.
 [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
 this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
 Lower-case only in address may get around a confirmation match glitch.
   INFO     [for unabridged version of RISKS information]
 There seems to be an occasional glitch in the confirmation process, in which
 case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
   .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> The INFO file (submissions, default disclaimers, archive sites,
 copyright policy, PRIVACY digests, etc.) is also obtainable from
   http://www.CSL.sri.com/risksinfo.html
 The full info file may appear now and then in future issues.  *** All
 contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks () CSL sri com with meaningful SUBJECT: line.
 *** NEW: Including the string "notsp" at the beginning or end of the subject
 *** line will be very helpful in separating real contributions from spam.
 *** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
 http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
   Lindsay has also added to the Newcastle catless site a palmtop version
   of the most recent RISKS issue and a WAP version that works for many but
   not all telephones: http://catless.ncl.ac.uk/w/r
 http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
    http://www.csl.sri.com/illustrative.html for browsing,
    http://www.csl.sri.com/illustrative.pdf or .ps for printing

------------------------------

End of RISKS-FORUM Digest 23.27
************************