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.garl
ic.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://ww
w.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.g
arlic.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.g
arlic.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.g
arlic.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 metzdowd.com
|
