Unforgeable Blinded Credentials

[Anne & Lynn Wheeler]

John Denker wrote:
> The phrase "there are no sensitive secrets today" sounds very strange
> by itself, and doesn't sound much better in context.
> 
> I assume the intended meaning was more along the lines of:
> ==   The set of things you want to keep secret has zero overlap with
> ==   the set of things you might want to use as an identifier.

this is sort of the track of the x9a10 working group activity on x9.59 
... which had been given the requirement to preserve the integrity of 
the financial infrastructure for ALL retail payments.

the analysis was that the account number had become grossly overloaded. 
one hand it was mainstay of normal business process required to be 
widely available and divulged for large number of different business 
processes.  on the other hand, it was also effectively being used for 
authentication; aka knowing the account number was frequently sufficient 
for authenticating the transaction.

the severely conflicting requirement for account number use ... on one 
hand being widely available and divulged for large number of different 
business processes ... and on the other hand needing to be kept private 
and confidential for authentications purposes ... created opportunity 
for numerous compromises. this also somewhat has led to my periodic 
observation that the planet could be buried under miles of cryptography 
(for hiding account numbers) and it still wouldn't be sufficient to 
prevent account numbers from leaking.

this is further aggravated by the long term findings that the majority 
of fraud have involved insiders who have legitimate access to the 
information. it is even further aggravated by account number being 
static data and therefor vulnerable (as an authentication mechanism) to 
skimming and replay attacks.

x9.59 called for dynamic data on the actual transaction for 
authentication (as countermeasure to both replay attacks and mitm 
attacks). x9.59 also called for account numbers used in x9.59 
transactions would not be honored when used in "non-authenticated" 
transactions (countermeasure to skimming, security breaches, and data 
breaches).

the combination of specifications in the x9.59 standard drastically 
reduced the sensitive nature of account numbers. the crooks could have 
all the skimming, security breaches and data breaches involving account 
number sources and it would be insufficient to execute fraudulent 
transaction.

a few recent posts mentioning x9.59 drastically reducing sensitive 
nature of account numbers.
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#16 trusted repositories and 
trusted transactions
http://www.garlic.com/~lynn/aadsm22.htm#1 GP4.3 - Growth and Fraud - 
Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a 
desktop near you

and my old long time standby of security proportional to risk ... with 
regard to the possible large discrepancy involving the value of skimmed 
account number data to the crooks (in the current infrastructure) 
vis-a-vis the worth of account number data to retail merchants
(the crooks can possibly afford to mount a massive attack that merchants 
can't reasonably be expected to afford to defend against)
http://www.garlic.com/~lynn/2001h.html#61

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