John Gilmore wrote:

IBM donates new privacy tool to open-source
  By  Joris Evers
  Staff Writer, CNET
  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.

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

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

This is also, effectively the X9.59 financial standard

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

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:  Securing financial transactions a 
high priority for 2007  Securing financial transactions a 
high priority for 2007  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

Analyst: Banks Must Make Credit Card Accounts Useless to Data Theives;jsessionid=E34WIOTVAIIHKQSNDLPCKHSCJUNN2JVN?articleID=197000263

this is somewhat related to my periodic references that existing infrastructure 
bury the planet under miles of (information hiding) encryption and still not 
account number linkage ... somewhat related old post about security 
proportional to risk

misc. past posts with reference to FSTC's FAST checks (was S/390 on PowerPC?) Ask about Certification-less Public Key AADS/X9.59 demo & standards at BAI 
(world-wide retail banking) show more on privacy CFP: PKI research workshop CFP: PKI research workshop FSTC to Validate WAP 1.2.1 
Specification for Mobile Commerce DOD prepares for credentialing pilot PKI International Consortium Improving Authentication on the 
Internet More Phishing scams, still no SSL 
being used More Phishing scams, still no SSL 
being used More Phishing scams, still no SSL 
being used X.509 and ssh

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to