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 [EMAIL PROTECTED]
