Failure of PKI in messaging

Anne & Lynn Wheeler lynn at garlic.com
Fri Feb 16 11:28:17 EST 2007


John Levine wrote:
> It doesn't do anything about the obvious attack path of phishing
> credentials from the users to stick bogus trusted entries into their
> accounts.  My examples showed all sorts of benign looking situations
> in which users provide their credentials to parties of unknown
> identity or reliability.

part of x9.59 financial standard
http://www.garlic.com/~lynn/x959.html
http://www.garlic.com/~lynn/subpubkey.html#x959

was to consistently require (digital signature) strong authentication and integrity on all transactions. as a result, phishing, data breaches, security breaches (with regard to account numbers) was eliminated as risk vector (account numbers could be divulged, phished, breached, etc ... but couldn't be used for fraudulent purposes). this also eliminated needing SSL for electronic commerce transactions (as part of hiding account numbers). in the online model ... don't require independent stand-alone/offline paradigm credentials ... just need a reliable authentication mechanism that is reasonably resisted to attacks. 

sort of as part the x9.59 effort ... in the later half of the 90s, was the aads chip strawman 
http://www.garlic.com/~lynn/x959.html#aads

as countermeasure to software private keys being easily compromised ... i.e. digital signature becomes a "something you have" authentication operation ... i.e. it represents having unique hardware token containing the private key that generates the digital signature. 

the next issue was hardware token costs ... both the costs of individual hardware tokens ... as well as the aggregate infrastructure costs related to institutional centric model with each institution issuing their own hardware token.

the first part was addressed by eliminating everything thing from the chip that wasn't in direct support of (security) of "something you have" authentication ... and the other was moving from a "institution centric" hardware token to a "person centric" hardware token. Moving to a "person centric" hardware token also turns out to eliminate a bunch of institutional hardware token personalization costs.  The objective was aggressive cost reduction gaining possibly two orders of magnitude on per chip .... and instead of requiring a unique hardware token effectively replacing every password a person currently uses ... just have one (or a small few) tokens per person. Institutional specific credentials go away ... since the increase the per chip issuing costs and  tend to eliminate person-centric operation (resulting in unique chips per institution).

This makes the hardware token ("something you have") authentication much more analogous to biometrics ("something you are") authentication. The hardware token for digital signature ... is presented in very much the same way a RFID chip (with static number vulnerable to replay attacks) might be presented ... or a fingerprint is sensed (again w/o being subject to replay attacks) .... but not requiring any other infrastructure, institutional, or application specific processing (it becomes a single function ... authentication, unlimited multi-app ... for whatever apps require authentication ... implementation).

A couple of the remaining vulnerabilities are

1) social engineering attacks getting victim to directly perform operations on behalf of
the attacker.
2) direct chip attacks to give up private key

current phishing tends to be convincing the person that they have to divulge some piece of information to verify and/or in support of other operations. the attacker then uses the information to perform fraudulent transactions w/o the victims knowledge. social engineering to perform operations on behalf of the attacker would tend to raise alarms in more peoples minds and possibly has less fraud ROI ... since it would presumably require more effort on the attacker's behalf for each fraudulent transactions. another possible social engineering operation is to convince the individual to "return" their hardware token (possibly as part of some required exchange operations). This would be easier done with the institutional-centric model ... since the victims would associate the token with the institution ... rather than believing they "owned" the token (in a person-centric model).

the issue in direct chip attacks is attempting to keep the cost of the attack somewhat higher than reasonable expected returns for the attacker ... i.e. part of this is parameterized risk management. the other is try and have the various chip attacks reasonably take longer than the typical lost/stolen reporting interval ... i.e. associated with an online transaction model. 
If the chip attacks cost more than the reasonable return to the attacker ... or the attack typically takes longer than avg. remaining lifetime before a lost/stolen report deactivates the chip.
In the parameterized risk management scenario ... the risk profile is registered for each kind of chip ... while there is possibility of a single kind of chip serving all possible operations ... there may be a case for multiple kinds of chips that have different costs and risk profiles. Some scenarios might require an individual to have a (person-centric) chip with a significantly better risk profile (being able to perform transactions with values up to the limit of a particular kind of chip risk profile). 

This may not provide extensive countermeasures to the possible kinds of attacks ... but it may be sufficient to provide countermeasures to 99percent of the current attacks (and make many of the remaining kinds of attacks financially unattractive).

In the past, i've somewhat facetiously stated that the aads chip strawman with person-centric approach and aggressive end-to-end cost reduction could reduce fully loaded hardware token infrastructure deployment costs by four orders of magnitude (reducing both per chip costs as well as total aggregate number of chips for scenario where hardware token authentication becames pervasive, say replacement for all existing password/pin operations).

One of the scenarios is that there is currently a significant amount of operations around hardware token paradigm that approach it from the profit perspective ... as opposed to approaching it from the cost perspective ... suggesting that total, fully loaded hardware token deployment costs are potentially reduced by four orders of magnitude has downside effect on many visions of profit.

disclaimer ... neither of us are associated with the owners of the aads chip strawman
patent portfolio
http://www.garlic.com/~lynn/aadssummary.htm

misc. past posts mentioning person-centric hardware token authentication paradigm
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
http://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
http://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
http://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
http://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing

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



More information about the cryptography mailing list