Liudvikas Bukys

“The spammers have discovered the hole.”

Steven Searle succinctly compares and contrasts the Auto-ID and Ubiquitous ID projects in The Auto-ID vs. the Ubiquitous ID vs. ?:

In fact, the Ubiquitous ID and the Auto-ID are very different in their technologies and their scope. The Ubiquitous ID scheme is a “meta code,” i.e., a code of existing and new codes, that gives a 128-bit number to both physical and non-physical things and is intended to operate across multiple network types. The Auto-ID scheme is a “new product code” that gives a 64/96-bit number to physical products and is intended to operate mainly via the Internet. Moreover, they use different scanning frequencies: the Ubiquitous IDs use a dual band, 2.45 GHz for RFID and 13.56 MHz for eTRON smart cards; while the Auto-IDs use 915 MHz for RFID. Here’s a chart of the main differences.

Note that the Auto-ID Center at MIT has evolved into something like a trade group, EPCglobal Inc.

An interesting page: Unique ID – The numbers that control your life, that includes details on how various ID numbers are constructed, including some that embed data in the ID number.

Robert Moskowitz: Wi-Fi Networking News: Weakness in Passphrase Choice in WPA Interface

Carl Hutzler and Ron da Silva, AOL Time Warner, at NANOG:
The Relationship Between Network Security and Spam:

• Large ISPs like AOL have deployed sophisticated blocking, rate
  limiting, and filtering technologies which are forcing spammers
  to find new methods.

• In order to blend in, spammers like finding IP space and/or
  accounts on major ISPs. We are forcing them to the ISPs

• Spammers are likely paying hackers to provide IP space for
  them to utilize with the goal being to spread out the volume
  across many IPs to blend in.
  • Many of the techniques hackers use are more and more criminal
    and disruptive in nature

Network and Application Security are more important than ever.

The presentation’s last slide includes instructions on how owners of networks can register to receive realtime AOL spam complaints (the Complaint Feedback Loop).

Scientific American: Baffling the Bots — Anti-spammers take on automatons posing as humans on
“completely automated public Turing test to tell computers and humans apart” (CAPTCHA):

“This is our arms race,” he says. “There’s no question that bots are going to become more and more sophisticated.”

Image: HENRY S. BAIRD PARC

Note that I’ve heard rumors of (or at least predictions of) CAPTCHA-workaround systems that farm out recognition work to pools of humans, e.g. by presenting them to users of other heavily-trafficed sites. If anybody has a specific example of that, I’d like to know.

Update: Thanks to Yakov Shafranovich for pointing out
Matt McCay’s weblog pointing to a
Pittsburgh Post-Gazette article citing Luis von Ahn at CMU as the source of this:

But at least one potential spammer managed to crack the CAPTCHA test. Someone designed a software robot that would fill out a registration form and, when confronted with a CAPTCHA test, would post it on a free porn site. Visitors to the porn site would be asked to complete the test before they could view more pornography, and the software robot would use their answer to complete the e-mail registration.

EFF: Trusted Computing: Promise and Risk summarizes the features and dangers of “trusted computing” frameworks, and proposes an “owner override” modification to fix the “unacceptably grave design flaw” of attestations without any owner control.

[via Ed Felten: Freedom to Tinker]

Eric Rescorla points out:
Peter Gutmann’s dissection of Linux VPN tools CIPE, vtun, and tinc

Geer, Bace, Gutmann, Metzger, Pfleeger, Quarterman, Schneier:
CyberInsecurity: The Cost of Monopoly (PDF)

[via
CCIA
(Computer & Communications Industry Association, advocating
“open markets, open systems,
open networks, and full, fair, and open competition”)]

Note:
Author Dan Geer got fired by @Stake for publishing this report.

MacDonald, Smith, Marchesini, Wild (Dartmouth):
Bear: An Open-Source Virtual Secure Coprocessor based on TCPA:

This paper reports on our ongoing project to use TCPA to transform a desktop Linux machine into a virtual secure coprocessor: more powerful but less secure than higher-end devices. We use TCPA hardware and modified boot loaders to protect fairly static components, such as a trusted kernel; we use an enforcer module—configured as Linux Security Module—to protected more dynamic system components; we use an encrypted loopback filesystem to protect highly dynamic components.