Lynn and Ann Wheeler -- mining InfoSec history, as they so usefully do,
in their voluminous posts -- reported:
.
> for some topic drift ..... RSA crypto stuff (being done by rsa) was
independent of the
> securid stuff (being done by security dynamics) ... then security dynamics
acquired
> rsa (and eventually consolidated the different products under a single
corporate
> name)

The Wheelers' comments -- a response to my claim that RSA's fabled
crypto savvy influenced the design of the SecurID OTP token -- were
inaccurate and misleading.

I've been using the Wheeler's posts to educate and frighten my clients
for years, so I'm sure the error is unintentional, perhaps even caused
by some lack of clarity in my earlier post. Since the Wheelers'
industrial history archive is likely to be referred to often in the
years to come, however, I did not want even this brief aside to stand
uncorrected.

It should surprise no one, certainly not Lynn Wheeler, that after the
1996 merger of SDI and RSADSI, RSA's new team of cryptographers and
crypto engineers began to urge a completely redesign of the original
SecurID system around stronger (128-bit) cryptosystems.

(The RSADSI folks were not unfamiliar with the SecurID.  The SecurID
client/server protocol had been designed around a proprietary hash
developed for SDI by Ron Rivest, the "R" of RSA.  After the merger,
RSA's crypto engineers pushed to harden the SecurID system -- which
already had a huge installed base, and dominated its market niche --
against new threats from the ubiquitous network and the Web. I was then
a consultant to SDI, as I am now to RSA -- a bit of the proverbial fly
on the wall.

(SDTI's sole cryptographer, John Brainard, happily allied himself with
his new peers, and eventually did much of the redesign himself. The
SecurID 2FA system was originally designed for a point-to-point closed
system, and then adapted to the client/server architecture.  RSADSI --
which had shortly before spun off its VeriSign subsidiary, and was
about to see its cryptographic ciphers implemented in a billion web
browsers -- was obsessively network centric. It was a timely and
synergistic merger.)

A more robust SecurID infrastructure with 128-bit crypto -- RSA
Authentication Agents, the ACE/Server authentication engine, and a new
RC5-based Client/Server protocol (with SSL transport channels) -- was
introduced six or seven years ago.

The SecurID token itself -- originally based on a proprietary 64-bit
hash developed by Brainard, still with RSA Labs -- was upgraded to a
new 128-bit AES design four years ago.  (It probably would have been
out sooner, but RSA decided to wait for the AES competition, in which
it had a contender, Rivest's RC6 block cipher.)

Across the industry, other vendors of competitive OTP tokens -- which
often have millions of tokens in use -- have been glacially slow to
introduce design changes in their OTP tokens, even as the relative
weakness of DES, the vulnerabilities of the X9.9 format, and the threat
of DPA attacks, became more worrisome.

Four years after RSA introduced its family of second-generation
SecurIDs, the SecurID is still, AFAIK, the only widely-used OTP token
which is built around 128-bit AES crypto.

Four years later, the SecurID still, AFAIK, the only OTP personal
authentication token which is hardened against DPA attacks.

(Differential Power Analysis (DPA) is technique used to attack
cryptographic devices. DPA uses side-channel analysis (SCA) -- in this
case, analyzing trace fluctuations in electrical power or battery draw,
as the device encrypts -- to model the cryptographic process for a
statistical "timing attack" that can often reveal the cryptographic key
used to initialize the cipher. SCA was an elegant and often
devastatingly effective breakthrough in cryptanalysis which, over the
past decade, has forced the redesign of most cryptographic devices.
Unfortunately, several prominent OTP token vendors apparently missed
the memo.)

In the worst case scenario for authentication tokens, DPA attacks could
potentially allow a serious attacker to surreptitiously steal or
"borrow" a vulnerable OTP token; crack and clone it within hours; and
then return the original token to the authorized user -- who might be
expected to blithely go to work the next day, none the wiser.

I'm not, of course, saying the sky is falling here. SecurID OTP tokens
are, perhaps uniquely, DPA-resistant -- but all 2FA devices, by
definition, require a second authenticator, usually a user-memorized
password, for authorized access to protected resources.  Hardware OTP
tokens -- even those which are vulnerable to DPA attacks -- probably
have an inherent security roughly equivalent to a PDA running a
software token-emulation application.  The integrity of the
authentication process, in that case, may depend upon the physical
security that the token-holder can offer, 24/7, for the OTP device.

That may be more than sufficient security for some, even most, IT
environments.

It will not suffice for others, where an institution requires, or the
market demands, truly tamper-resistant OTP hardware tokens before the
users are going to move to 2FA.

Although it is typically not the least expensive OTP option for 2FA,
RSA's SecurID is competitive -- and it is usually the OTP token chosen
by institutions where security standards are high. (Which is why I
expect Tom Kern will soon be carrying a SecurID -- and grouching about
it, as any licensed curmudgeon is required to do.)  ;-)

As with any InfoSec purchase, a threat and risk assessment is useful,
even imperative, before an organization invests in 2FA.  Some forget
the due diligence basics, when the marketing noise rises to a deafening
din.

Tony Harminc <[EMAIL PROTECTED]>, an articulate applications developer
for Vasco Data Security International (VDSI), offered a list of
questions for prospective OTP token buyers. Some were reasonable, but
all were predictably biased against RSA's portfolio of SecurID devices.
 Vasco <www.vasco.com> is a big Belgian smart card and OTP token
vendor, perhaps best known for the Digipass OTP tokens which many
European financial institutions now issue to their online banking
customers for 2FA.

In Mr. Harminc's list of buyers' concerns, the SecurID's unique
capabilities -- the 60-second OTP, viable for only a minute or two --
were cast in negative terms, just because only RSA can provide or
support this patented functionality.  RSA is fair game, and Mr. Harminc
was fair enough, I suppose, for a competitive evangelist -- but
Harminc's comments bring to mind Ben Franklin's famous caution that
people in glass houses shouldn't throw stones.

Mr. Harminc's list of questions for prospective RSA customers also did
not include one that IT pros might consider critical: "Which OTP
hardware token is the most secure, the most robust, the most resistant,
against all known attacks?"

Not all tokens are equal.

The Vaso Digipass tokens that Mr. Harminc touts are sold with a
projected life-span of somewhere between three and seven years.  Last
summer, however, Vasco CEO T. Kendall Hunt told a gathering of security
analysts in New York that Vasco has recently discovered that many
European banks have decided, instead, to *annually* replace the Vasco
Digipass tokens they routinely issue to their business and retail
banking customers. See Mr. Hunt's comments in CRN at:
<http://tinyurl.com/cospv>.

Mr. Hunt offered no explanation for the radical changes in the risk
models by which these European financial service firms are now managing
their deployment and replacement policies for Vasco's OTP tokens.

Conincidentally, this month the European Commission expects to receive
the final report from a major study of Side-Channel Analysis (SCA) and
related attacks on physical implementations of crypto on microchips.
Two years ago, the EC commissioned nine teams of prominent IT
researchers -- based at corporate and academic IT research centers
across Europe -- to explore the threat that SCA attacks, including DPA
and associated threats, posed to cryptographic devices, in particular
"smart cards and related micro-chip systems." (See:
<http://tinyurl.com/7zfaa>.)

The EC's SCA research project was also tasked to investigate ways in
which the risk of SCA attacks might be blocked, avoided, or mitigated
by innovative SCA-resistant designs (SCARD) for chip circuits, or
changes in enterprise "best practice" policies.

Personally, I suspect that -- as the reportedly dismal results of the
EC's SCA study become more widely known -- the Euro banks' new annual
replacement policy for Vasco's tokens may only be the first of the
costly adjustments that financial services, and other critical
infrastructure industries, may be forced to accept, in order to manage
and mitigate operational risks.

As I've been repeating for damn near 20 years, old curmudgeon than I
am: Not all tokens are equal.

Surete,
           _Vin

------------------------------------------------------------
   Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]>
         22 Beacon St., Chelsea, MA 02150-2672 USA

Reply via email to