Re: about SecuriID on mobile devices
- From: Vin McLellan <vin.mclellan@xxxxxxxxx>
- Date: Sat, 11 Apr 2009 21:25:27 -0700 (PDT)
Vin McLellan <me> wrote:
)> The real topic here is the trade-offs involved in
)> implementing most security devices, balancing
)> between maximum security, cost, ease-of-use, and
)> other operational requirements.
Paul Rubin dismissed this with a sniff:
$> That is marketing spin. "Something you have" is
$> physical by definition.
What, you didn't drink the Kool-Aid? ;-)
Tokens to assert identity or status were widely used long before the
electron was discovered. There are simple tokens today, like a police
badge, which indubitably confer authority. And it is not that they are
so hard to copy that keeps people from flashing a phony police badge.
The now classic three-factor paradigm is a simplified abstract model
for asserting *legitimacy* in human interactions with a computer. It's
been very useful, a great marketing success, but it's beginning to
show its age.
AAA 101: A remote computer uses these "factors," and others, to
determine if the person providing them -- or evidence clearly derived
from them -- is on its list of pre-registered legitimate users who can
be allowed to execute a specific transaction, or be given access to
restricted resources and services.
Anyone who can grasp the idea of a conceptual model -- and make a
distinction between the abstract categories of the model, and real
implementations that fit within them -- ought to be able to understand
the difference between the three assertions of legitimacy, of
identity, and a subset of security attributes that can potentially
enhance them to make the process more robust, viable in more
environments.
Metrics for the relative security or insecurity of each
"factor" (something known, something held, or a biometric, something
one is) are useful, sometimes vitally necessary -- but they are
complementary attributes, and are not logically or inherently critical
to fulfilling any one of them.
If you memorize both a three-digit PIN and a long complex password, is
one any more a valid expression of "something you know?"
For the simple three-factor paradigm, to fulfill abstract category #2,
any unique physical artifact, "held," fits the model. Mr. Rubin
disputed this:
#> If a token is copyable, then it is not a "something you
#> have" factor in two-factor authentication, since two
#> people might have it. The idea of tokens is that they
#> are uncopyable,or at least difficult to copy (e.g.
#> something like a smart card).
If an artifact is physical -- it helps that it be unique, or nearly
so, and legitimately in my possession -- it qualifies, by simple
logic, as "something held."
If I can display it -- or otherwise prove, to a relying party at a
distance, that I have it in my possession -- it is certainly a valid
second factor for 2FA.
In the model's requirement for a second factor, "something held," the
physical artifact's inherent or relative resistance to being copied is
only a very useful, not essential, characteristic. The relative
uniqueness of the token -- and here I use the word as Webster might,
something held or displayed as an assertion of authority, rights, or
identity -- is much more important.
Most important, of course, is the manner in which any "token holder"
holds, carries, protects, and uses her token. Possession, to our
advantage, inevitably gets bound up with ego, values,
responsibilities, authority: the legitimacy of a personal or
professional persona.
Any of the three factors can be enhanced with security attributes -- a
password can be more complex; derivative evidence of "something held"
can be time-bound, valid only once and briefly; a biometric can be for
a body-party not readily accessible to guy you meet in a bar -- but
varying those attributes doesn't change the fundamental nature of the
model, nor the logical distinctions between the three categories. That
is, each ideally can only be captured or corrupted in separate
dimensions, with distinct attacks upon the mind, the individual's
personal space, or the body's flesh or direct expressions.
Ideally, to obtain my guarded artifact, "something held," an attacker
would have to physically accost me. Which is why, in an earlier
message that mentioned (utterly Xeroxable) Grid Cards and S/Key lists,
I tossed in the quip: "To get mine, you'll have to come after me,
personally."
To which Mr. Rubin replied:
...> That's silly. You could give me a copy without me
...> having to come after you, either on purpose or because
...> you made a backup copy for your own purposes that
...> somehow escaped while you kept the original in your
...> pocket.
Not silly at all. Human misconduct, or error, or negligence, can
corrupt the model at either end. No surprise. That's why the multi-
factor model, expressed in infrastructure, can only be implemented in
a bounded and managed environment, where someone with a big club is
responsible for developing and enforcing policy, and educating all
parties on how it works, and why care and responsible behavior is
critical to using it successfully.
There are four classes of physical artifacts widely used for 2FA in IT
today:
• Physical OTP tokens (fobs or display cards)
• Printed PIN/TAN cards or OTP grid cards
• Devices hosting embedded token-emulation (and PKI) software apps
• Smart cards
In the enterprise, and now in many consumer-oriented networks, there
have been several additional and complementary "factors" which have
seen widespread implementation:
• Machine authentication
• Out-of-Band authentication (SMS, voice, even postal)
• Knowledge-based authentication
• IP-based geolocation
(The last reminds us graybeards of the hard-wired terminals of an
earlier era of "EDP," when location and access to a guarded room was a
"factor.")
Any OTP token or smart card, obviously, can be "something held," but
there are probably tens of millions of people around the globe who
today still use printed cards of PIN/TAN numbers for 2FA, or Grid
Cards for creating an OTP on the fly, in response to a challenge from
their banks. All are valid 2FA.
OTP generators in software, embedded in PDAs and phones, etc., have
special problems, and require innovative defensive measures -- the
topic of our discussion -- but hardware OTP tokens and smart cards,
while they were designed to be (and sometimes are) inherently quite
secure, are still only relatively more secure from illicit copying and
cloning. Some more than others.
Smart card vendors have their own war stories of new attacks and new
defenses in silicon and in the card-readers.
(I mentioned earlier the apparently unexpected decertification of the
old X9.9 standard ten years ago, when a viable attack on the DES-MAC
was found, which shocked some OTP vendors and their customers. That
threat left tens of millions of OTP hardware tokens potentially at
risk of being rather easily cracked and cloned, the nightmare scenario
for OTP vendors. The token-holders still used them in 2FA, and validly
so -- but there was an additional risk that had to be addressed in
both training and technology.)
DPA and other side-channel attacks have been discussed many times in
this forum. Why should it be a surprise to learn that millions of
tokens and smart cards are still vulnerable to this attack -- if a
token can be stolen or worst, surreptitiously "borrowed" for a few
hours -- in the hands of a sophisticated attacker? Many OTP vendors,
and their customers, have lived with this risk for a decade too.
(The first factor, the PIN or password, could save the day, which is
why they are taken more seriously in 2FA today. Consumer 2FA apps
often use full passwords, rather than the abbreviated PIN once common
in corporate environments. Everywhere, PINs are often longer and
alphanumeric.)
The market adapts. Security is always relative and imperfect; so
layered security measures are the only practical response.
"Everything holds a risk. Welcome to life," as Bruce Schneier once put
it. "The trick is to minimize the risk to the point where accepting it
is a reasonable business model."
Suerte,
_Vin
.
- References:
- Re: about SecuriID on mobile devices
- From: Vin McLellan
- Re: about SecuriID on mobile devices
- From: Paul Rubin
- Re: about SecuriID on mobile devices
- Prev by Date: Re: about SecuriID on mobile devices
- Next by Date: Re: Joint Thin Tile Cipher – Batch and Real Time.
- Previous by thread: Re: about SecuriID on mobile devices
- Next by thread: Re: about SecuriID on mobile devices
- Index(es):
Relevant Pages
|
