News.com: IBM donates new privacy tool to open-source Higgins

[Anne & Lynn Wheeler]

John Gilmore wrote:
> http://news.com.com/IBM+donates+new+privacy+tool+to+open-source/2100-1029_3-6153625.html
> 
> IBM donates new privacy tool to open-source
>   By  Joris Evers
>   Staff Writer, CNET News.com
>   Published: January 25, 2007, 9:00 PM PST

...

> For example, when making a purchase online, buyers would provide an  
> encrypted credential issued by their credit card company instead of  
> actual credit card details. The online store can't access the  
> credential, but passes it on to the credit card issuer, which can  
> verify it and make sure the retailer gets paid.
> 
>   "This limits the liability that the storefront has, because they don't  
> have that credit card information anymore," Nadalin said. "All you hear  
> about is stores getting hacked."
> 
>   Similarly, an agency such as the Department of Motor Vehicles could  
> issue an encrypted credential that could be used for age checks, for  
> example. A company looking for such a check won't have to know an  
> individual's date of birth or other driver's license details; the DMV  
> can simply electronically confirm that a person is of age, according to  
> IBM.

this was somewhat the issue with x.509 identity certificates from the early 90s,
they were being overloaded with personal information ... and then the proposal
that everybody should then "spray" such digital certificates frequently all
over the world. in this period, they were also being touted for use in
electronic driver's licenses, passports, etc.

In the mid-90s, with the realization of the enormous privacy exposures of
such a paradigm ... there was some parties retrenching to relying-party-only
certificates ... basically a record pointer ... which was then used as
reference to the record with the necessary information ... and only the
absolutely necessary information was then divulged.
http://www.garlic.com/~lynn/subpubkey.html#rpo

however, it was trivially possible to demonstrated that the actual
digital certificate was redundant and superfluous ... all that was
necessary was the record pointer, a digital signature ... and the
responsible agency could verify the digital signature with public
key on file ... at the same time they processed the request using
the record pointer.

This was basically the FSTC organizations
http://www.fstc.org/

model for "FAST" (financial authenticated secure transaction). The transaction
is mapped into existing ISO 8583 message and uses the existing infrastructure
operations. Rather then divulging age, a FAST (/8583) transaction ... digital
signed by the individual ... could ask whether the person meets some age
criteria, address criteria, etc ... getting YES/NO response ... w/o divulging
any additional information (like actual date of birth). This was modeled
after existing (ISO 8583, debit, credit, etc) financial transaction which 
effectively asks whether the merchant gets paid or not (simply YES/NO
response).

This is also, effectively the X9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

The X9A10 financial standard working group, in the mid-90s was given the
requirement to preserve the integrity of the financial infrastructure for
all retail payments. The transaction is sent with digital signature,
the responsible agency validates the digital signature, examines the
transaction request and then responds YES/NO regarding whether the
merchant gets paid or not.

The other characteristic of X9.59 was that it included a business rule that
"X9.59" account numbers couldn't be used in non-X9.59 transaction. That
made the associated account numbers (record pointers) unusable w/o the
accompanying digital signature i.e. random people couldn't generate
random (valid) transactions against the account number/record number.
This had the effect of eliminating a lot of the existing skimming/harvesting
exploits
http://www.garlic.com/~lynn/subintegrity.html#harvest

It isn't necessary to have an encrypted credential ... since if it was
purely "static data" ... and simply presenting such static data exposes
the infrastructure to various kinds of replay attack. In that sense,
the static data can be any recognizable information specific to the
responsible agency handling the transaction. The "static data" is used
by the responsible party to lookup the actual information (including,
if necessary the public key)  ... and the digital signature on every 
transaction prevents various kinds of replay attacks ... that might be
possible in an infrastructure relying on only static data. If the 
agency is going to lookup something (rather than have it carried around
in large encrypted packet ...) then it becomes immaterial whether the
actual (static data) record locator is encrypted or not.

related post in this thread:
http://www.garlic.com/~lynn/2007c.html#43  Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#46  Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#51  Securing financial transactions a high priority for 2007

with reference to recent news items somewhat touching on the same subject:

Latest Breach May Force a New Approach to Data Security
http://www.digitaltransactions.net/newsstory.cfm?newsid=1226

Analyst: Banks Must Make Credit Card Accounts Useless to Data Theives
http://www.informationweek.com/showArticle.jhtml;jsessionid=E34WIOTVAIIHKQSNDLPCKHSCJUNN2JVN?articleID=197000263

this is somewhat related to my periodic references that existing infrastructure could
bury the planet under miles of (information hiding) encryption and still not prevent
account number linkage ... somewhat related old post about security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

misc. past posts with reference to FSTC's FAST
http://www.garlic.com/~lynn/99.html#171 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aadsm16.htm#5 DOD prepares for credentialing pilot
http://www.garlic.com/~lynn/aadsm17.htm#19 PKI International Consortium
http://www.garlic.com/~lynn/2005i.html#33 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#42 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com