March 28, 2006

Call for Nominations - 2006 PET AWARD

You are invited to submit nominations to the 2006 PET Award.

The PET Award is presented annually to researchers who have made an outstanding contribution to the theory, design, implementation, or deployment of privacy enhancing technology. It is awarded at the annual Privacy Enhancing Technologies Workshop (PET). The PET Award carries a prize of 3000 Euros thanks to the generous support of Microsoft.

Any paper by any author written in the area of privacy enhancing technologies is eligible for nomination. However, the paper must have appeared in a refereed journal, conference, or workshop with published proceedings in the period that goes from the end of the penultimate PET Workshop (the PET workshop prior to the last PET workshop that has already occurred: i.e. June 2004) until April 15th, 2006. The complete Award rules including eligibility requirements can be found at http://petworkshop.org/award/.

Anyone can nominate a paper by sending an email message containing the following to award-chairs06@petworkshop.org:

- Paper title
- Author(s)
- Author(s) contact information
- Publication venue
- A nomination statement of no more than 250 words.

All nominations must be submitted by April 15th, 2006. A seven-member Award committee will select one or two winners among the nominations received. Winners must be present at the PET workshop in order to receive the Award. This requirement can be waived only at the discretion of the PET Advisory board.

2006 Award Committee:

- Alessandro Acquisti (chair), Carnegie Mellon University, USA
- Roger Dingledine (co-chair), The Free Haven Project, USA
- Ram Chellappa, Emory University, USA
- Lorrie Cranor, Carnegie Mellon University, USA
- Rosario Gennaro, IBM Research, USA
- Ian Goldberg, Zero Knowledge Systems, Canada
- Markus Jakobsson, Indiana University at Bloomington, USA

More information about the PET award (including past winners) is available at http://petworkshop.org/award/.

More information about the 2006 PET workshop is available at http://petworkshop.org/2006/.


-----------------------
Alessandro Acquisti
Heinz School, Carnegie Mellon University
(P) 412 268 9853
(F) 412 268 5339
http://www.heinz.cmu.edu/~acquisti
-----------------------

Posted by iang at 01:32 PM | Comments (0) | TrackBack

March 26, 2006

How does the dominatrix of the open source world encourage her clients to pay for their pain?

OpenBSD asks for more contributions coz it's running at a loss. Mozilla asks for help in giving away money coz it's washing in funds. What a funny world.

Humour aside it is worthwhile to analyse these differences. Mozilla delivers browsers and email clients to the great masses of Internet users. Yours and my mom might use Firefox. BSD is an obscure operating that gets used by people who know what it is for, and probably have more than a passing ability to read and hack the code. Hard-core geeks in other words.

Mozilla stresses community and tries to get along, CEO Mitchell talks about personal lessons from falling off the trapeze; in contrast Theo de Raadt has a reputation for not getting along and frequently stars in flame wars over some security issue or other.

What's the core difference here? It's in the mission. Mozilla's software is standing in front of the user, and offering her an experience. Indeed, they say that part of the mission is improving the experience, which of necessity means getting all close and cozy with the users - all of them. You cannot improve your users' experiences unless you get into their hearts, their souls, their minds.

OpenBSD's mission in contrast is security, which isn't close and cozy anywhere anytime. Quite the opposite - for OpenBSD, the user is as much a threat as a beneficiary. In the hard security world, everything and everyone is treated with suspicion until proven otherwise. And even then, we have our doubts...

Which means that on first, second and third blush the OpenBSD project is unfriendly. The nicest thing you could say about those guys is that they are uncompromising, whereas the Mozilla guys are quite compromising. So here's where it all comes together: to cut a deal with Yahoo or Google that is worth 8 figures in revenue (numbers not available but widely speculated) you do need to be compromising - very compromising. Yahoo and Google want serious compromises for their dosh.

OTOH, you can imagine what would happen if Google turned up with a suggestion of, say, putting their disk searching technology into OpenBSD. (For a fee, of course.) We want an uncompromising response to that, forsooth, the nastier the better. I feel quite comfortable when I hear of the latest security spat - because I know that an uncompromising attitude is essential to security.

I wouldn't go so far as to say you have to be downright nasty to be secure. But it is certainly very hard to be secure when you have a mission of embracing all. A nice trick to pull off, if you can do it, and please tell us about it.

Getting back to OpenBSD. Just how does an open source project that makes a mission of being, ahem, uncompromising, go about doing some deals to get some revenue? Just who in business wants to pay for pain? Tough one, that. Those who solicit the dominatrix's services aren't saying, either.

Posted by iang at 03:19 PM | Comments (6) | TrackBack

March 20, 2006

Digital Money 29th, 30th

Digital Money is coming up, 29th and 30th March. Always good for a visit.

The goal of the Forum is to encourage discussion and debate around the real issues at the heart of electronic identity [sic - must be digital money] in all its forms. In addition to this Forum, every autumn we organise the annual Digital Identity Forum (see the web site at www.digitalidforum.com for more details), the sister event to the Digital Money Forum.

There are several great things about the Hyperion conferences. Firstly, Dave and the team work hard to keep the commercial presentations down to a minimum. Next, he casts out looking for up and coming trends including the wild and woolly social experiments. Lastly, there's usually a great book giveaway!

Talks I'd travel some distance for, if I could:

Replacing Cash with Mobile Phones
Susie Lonie, Vodafone
A case study on the African M-PESA scheme

Currency for Kids
Jonathan Attwood, Swap-it-Shop UK
The UK's "eBay for kids"

Cross-Border Funds Transfer before the Internet - The ransom of King Richard
David Boyle, Author of "Blondel's Song"

Posted by iang at 01:22 PM | Comments (3) | TrackBack

March 15, 2006

Just another day in the office of Identity Control

Over at CeBIT I spent some time at the CAcert booth checking out what they were up to. Lots of identity checking, it seems. This process involves staring hard at government Id cards and faces, which gets a bit tricky when the photo is a decade or two out of date. What do you say to the heavy-set matron about the cute skinny teenager on her identity card?

One artist chap turned up and wanted to sign up as an artist. This turns out to be a 'right' in Germany. Lo and behold, on his dox there is a spot for his artist's identity name. Much debate ensued - is CAcert supposed to be upstream or downstream of the psuedonymous process?

In this case, the process was apparently resolved by accepting the artist's name, as long as the supporting documentation provided private clarification. Supporting nymous identities I think is a good idea - and age old scholars of democracy will point out the importance of the right to speak without fear and distribute pamphlets anonymously.

CAcert is probably downstream, and over in Taiwan (which might be representative of China or not) we discover more government supported nymous identities: passport holders can pick their own first names for their passport. Why? The formal process of translating (Kanji) Han into Latin for passports - (popumofu?) pinyin! - so mangles the real sense that letting a person pick a new name in Latin letters restores some humanity to the process.

This development is not without perverse results. It places CAcert in the position of supporting nyms only if they are government-approved yet frowning on nyms that are not. Hardly the result that was intended - should CAcert apply to sponsor the Big Brother awards - for protecting privacy - or to receive one - for supporting government shills?

Most people in most countries think Identity is simple, and this was evident in spades at the booth. For companies, one suggestion is to take the very strong German company scheme and make it world standard. This won't work, simply because it is built on certain artifacts of the German corporate system. So there is a bit of a challenge to build a system that makes companies look the same the world over.

Not that individuals are any easier. Some of the Assurers - those are the ones that do the identity verification - are heading for the Phillipines to start up a network. There, the people don't do government issued identity, not like we do in the West. In fact, they don't have much Id at all it seems, and to get a passport takes 4 visits to 4 different offices and 4 different pieces of paper (the last visit is to the President's Office in Manila...).

The easy answer then is to just do that - but that's prohibitively expensive. One of the early steps is visiting a notary, which is possibly a reliable document and a proxy for a government ID, but even that costs some substantial fraction of the average monthly wage (only about 40 Euros to start with).

A challenge! If you have any ideas about how to identify the population of a country that isn't currently on the identity track, let us know. Psuedonymously, of course.

Posted by iang at 04:07 PM | Comments (1) | TrackBack

March 14, 2006

NIST opens new DSA format for comments

In what looks like a surprise announcement, NIST has published a request-for-comments on a new Digital Signature Algorithm that expands the hash size to the newer SHA-2 family.

March 13, 2006: Draft Federal Information Processing Standard (FIPS) 186-3 - Digital Signature Standard (DSS)

Draft FIPS 186-3 is the proposed revision of FIPS 186-2. The draft defines methods for digital signature generation that can be used for the protection of messages, and for the verification and validation of those digital signatures. Three techniques are allowed: DSA, RSA and ECDSA. This draft includes requirements for obtaining the assurances necessary for valid digital signatures. Methods for obtaining these assurances are provided in Draft NIST Special Publication 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications. (see write-up for draft SP 800-89 below)

David Shaw notes the larger sizes:

In the OpenPGP context, probably the most interesting bit is that the 160-bit hash limit has been removed. The sizes supported are:
  • 1024-bit key, 160-bit hash (the current DSA)
  • 2048-bit key, 224-bit hash (presumably aimed at SHA-224)
  • 2048-bit key, 256-bit hash (presumably aimed at SHA-256)
  • 3072-bit key, 256-bit hash (presumably aimed at SHA-256)

It also adds the concept of using a larger hash than will fit by taking the leftmost bits.

More later ...

Posted by iang at 12:59 PM | Comments (0) | TrackBack

March 05, 2006

"doing the CA statement shuffle" and other dances

The much discussed CA branding model has apparently been adopted by Microsoft, implemented in the InfoCard system, if the presentation by Cameron and Jones is anything to go by. I reviewed and critiqued that presentation last week, including relevant screenshots.

Now, the statement as the core reason for the CA's existance is becoming more clearly accepted. It's something that got thrown out with the bath water back in 1995 or so, but it seems to be heading for something of a revival. Cameron and Jones say:

In many cases, all that having a standard site certificate guarantees is that someone was once able to respond to e-mail sent to that site. In contrast, a higher-value certificate is the certificate authority saying, in effect, “We stake our reputation on the fact that this is a reputable merchant and they are who they claim to be”.

I also found an RFC by Chokhani, et al, called Internet X.509 Public Key Infrastructure (RFC 3647) which throws more light on the statement:

3.1. Certificate Policy

When a certification authority issues a certificate, it is providing a statement to a certificate user (i.e., a relying party) that a particular public key is bound to the identity and/or other attributes of a particular entity (the certificate subject, which is usually also the subscriber). The extent to which the relying party should rely on that statement by the CA, however, needs to be assessed by the relying party or entity controlling or coordinating the way relying parties or relying party applications use certificates. Different certificates are issued following different practices and procedures, and may be suitable for different applications and/or purposes.

The CA's statement is that the the key is bound to attributes of an entity (including Identity). So we are all agreed that the cert has or is a statement of the CA saying something. But consider the caveat there that I emphasised: the authors have recognised that relying parties typically do not control or coordinate their use of certificates. There is typically an intermediate entity that takes responsibility for this. To the extent that this entity controls or coordinates the root list, they are in the driver's seat.

For browsing, this is the browser manufacturer, and thus the browser manufacturer is the relying party of ultimate responsibility. What this does is put browser manufacturers in a sticky position, whether they admit to it or not (and notice how you won't find any browser manufacturer clarifying who makes the statement from a manufacturered cert).

Microsoft's position may be weak in understanding and implementation, or maybe they know full well where this is going, and are implementing an intermediate step. Leaving that aside, it does leave the interesting question as to why they have only partially implemented the model. Not only does the high-assurance program prove the point that the CA has to be branded (thanks for that!) but it also confirms that the browser is on the hook for all the other certs in the other, default, poor man's certificate regime.

Either way, we are on the move again...

Posted by iang at 06:23 PM | Comments (4) | TrackBack

March 02, 2006

Google strives for hard cold cash

Viking reads the terms of service for Google Payments (discussed here) and discovers:

Here is the really interesting part though. Google Payments is set up like the DGC industry in regards to user responsibility & payment repudiability.
"Buyer is responsible for any and all transactions by persons that Buyer gives access to or that otherwise use such username or password and any and all consequences of use or misuse of such username and password."

"all Payment Transactions processed through the Service are non-refundable to Buyer and are non-reversible [...] fraud and other disputes regarding transactions shall not entitle Buyer to a refund of the Payment Amount or a reversal of a Payment Transaction"

This ought to be very interesting to watch as they are completely violating the May Scale. They facilitate cc payments from the buyer, but the seller "gets paid & stays paid".

Indeed. Although, if they can hold the line on that issue, and keep their user base clean, this would mean that they would be well placed for the future. Margins in transactions in non-reversable payment systems range from 0.1% to 0.5% whereas reversible payments charge around 4-5%. Easy meat.

Posted by iang at 12:05 PM | Comments (2) | TrackBack

News on payments: mobile/cell, Skype, Google

America moves a bit closer to using cells (mobiles outside the US) for payment. What I find curious is why banks don't simply use their customer's phones as two-factor tokens. It can't be any more sophisticated than selling a ring tone, surely?

Skype signs up with Click&Buy and seemingly others. Again curious, given they are owned by eBay these days.

Google reveals more, as spotted over on PaymentNews. Basically, move the billing systems over to an internal money.

If you take a look at the history of Google's advertising programs and online services, one thing you notice is that online billing and payments have been a core part of our offerings for some time. To run our ad programs, Google receives payments every day from advertisers, and then pays out a portion of those funds to advertising partners. Over the past four years, Google has billed advertisers in 65 countries more than $11.2 billion in 48 currencies, and made payments to advertising partners of more than $3.9 billion. When one of our consumer services requires payment to us, we've also provided users a purchase option.

As the number of Google services has increased, we've continued to build on our core payment features and migrate to a standard process for people to buy our services with a Google Account. Examples of this migration include enabling users to buy Google Video content, Google Earth licenses, and Google Store items with their Google Accounts. We also just began offering similar functionality on Google Base.

If only more companies issued their own internal money and used it for the billing systems. Expect Microsoft to scratch its collective heads and wonder "why didn't we think of that?" It's actually not that much a leap, more a mental twist than a business change. From there, integrating credit card collection is easy. (Credits: I first did this a few years back, but the idea has been around for yonks, I recall Lucky Green explaining it as a potential direction for DigiCash sales, around 1997.)

For buyers, this feature will provide a convenient and secure way to purchase Google Base items by credit card. For sellers, this feature integrates transaction processing with Google Base item management.

And if they do it carefully enough, they won't walk into the minefield of regulatory interference.

The Mountain View, California-based search giant made sure the test got off to a quiet start. Google launched a video store last month, and shoppers found that they could buy videos by signing into their Google accounts. People have also been using their accounts to buy mapping-related products from Google Earth, information on Google Answers, and keywords on AdWords, Google's advertising program, in some cases for more than a year now.

Huh. Scary but true - hype is not the same thing as strategy. We'll see. Elsewhere, Technews says that Google is a direct shot at eBay and Paypal. I agree, it's on the agenda, but it's a shot across the bows, the actual broadsides will come later. Paypal is very vulnerable, Google won't need to rush. Also see lots of screen shots there, and also see buyer's terms.

Posted by iang at 08:54 AM | Comments (1) | TrackBack