RE: Cryptanalysis of SecurID (ACE/Server)

New Message Reply About this list Date view Thread view Subject view Author view

Vin McLellan (vin@shore.net)
Wed, 7 Oct 1998 01:01:48 -0400


At 11:30 AM -0400 10/2/98, Michael Bauer wrote:

> While [TCP hijacking or telephone-call hijacking] is nothing to sneeze
>at, > I personally think that for the time being it's an acceptable risk
>given
> that my client will use this system strictly as a replacement for the
> single-factor authentication currently used by their dial-up access
> servers.

        This is a fairly common judgement call. It is not that wiretapping
and some equivalent of session hijacking on a phone PPP connection is not
possible, but that it calls for a more direct, planned, and more overtly
felonious attack -- probably involving a physical intrusion and an actual
wiretap. The difference is enough to block the random war-dialing hacker
and vandal.

>They're far
>more worried about random war-dialer attacks from the void
>than they are about someone systematically trying to impersonate one of
>their people, intercept email, etc. (Although I think they should _start_
>worrying about these things fairly soon.)

        Yup. Probably 70 percent of the installed ACE/SecurID systems are
still protecting dial-in communications servers, and except for encrypted
mail and HTTPS (which can be required by an ACE/Agent) most of the traffic
on those lines is probably still unencrypted. On the other hand, 18
commercial VPNs from different third-party vendors now ship with integrated
ACE/Agent code: "SecurID Ready," as they say.

>In the long term, they expect to be able to leverage this system in other
>applications as well, including VPN (i.e., encrypted TCP/IP sessions) and
>maybe even LAN authentication. Yes, it's expensive, but SecurID's high
>level of interoperability is worth it to this client.

        Multiple product lines from 70-odd third-party vendors of network
services or hardware/software products -- from comm servers to Oracle RDBS
-- ship with integrated ACE/Agent code. <http://www.securid.com/partners/>

        SDTI's new ACE/Agent for NT, free for current users, offers LAN
authentication (subauth Domain authentication) with a mini-PKI and X509
certs. It is already shipping, but it won't be formally announced for a
week or so. For Unix intranets, see SDTI's BoKs enterprise systems for
single sign-on, strong authentication, and centralized access control and
audit: <http://www.securid.com/products/>

>And despite Mr. Metzger's assertions, I see a lot of merit in two-factor
>authentication. Yes, the token can be stolen. Yes, my users can be
>idiots and put their PINs on sticky notes attached to the tokens (although
>since most people use their ATM PINs I doubt this happens too much).
>Nothing, however, changes the fact that in order to authenticate to
>service X (access server, VPN device, whatever) one will require two
>things, a physical device and a memorized (ideally) secret. And as Mr.
>Schneier observes, if that physical device is conveniently small/portable
>and not tied to any specific machine, all the better for the user.

        The potential of PKC security services (especially digital sigs) to
make security technology an enabling utility (rather than a burdensome
hassle) has lured infosec pros for a long time -- but I think many are
going to regret the loss of the simple OTP token (which is so obviously
doing just what it is supposed to do; nothing less, and nothing more.)

        Infosec professionals have not yet come to terms with the fact that
the PKI environment transfers a great deal of responsibility to users.
Perry said it: if you can't trust your users, you're dead. By contrast,
ACE/SecurID is a technology designed soley to enhance management audit and
accountability: the actions and options of the SecurID token-holder are
tightly circumscribed. It's a bold leap we make to PKI.

        Thirty years of industry lore have also defined the value of small
personalized hand-held authenticators. RSA keys and X509 Certs are going to
be seen as unnecessarily vulnerable until they are safely stored in
smartcards. Two-factor authentication will remain a valid and useful
standard.

>I agree with Mr. Metzger that it doesn't make much sense to use
>strong authentication if it's trivially easy to hijack the subsequent
>(unencrypted) session. But if you've already bought a 2fA system for
>something else (like dial-in connections, which I'm just not convinced are
>routinely hijacked), when the time comes to implement all-out encrypted
>networking, you'll already have an authentication mechanism in place.
>
>In the long run, I think PKI and similar technologies will
>make expensive tokens irrelevant. (Hey, maybe SDTI will have
>their own solution ready by the time my client's first round of tokens
>dies!) But right now these (PKI et al) seem hard to implement without
>fudamentally changing one's infrastructure (at the net-OS level) or at
>least doing a lot of customization of client apps -- in contrast, most 2fa
>systems can be "dropped in" to whatever kind of network you already have.

        SDTI calls their RSA and PKI-based next generation architecture
"SecurSight." <http://www.securid.com/solutions/> Version 1 will ship next
spring -- three or four years before your client's SecurIDs will expire;-)
SecurSight will potentially support authentication, authorization, and
grandular access controls over all internal network resources, apps and
services. For user authentication and PKI credentials, it will rely upon:

        - smartcard-based X509 certs, or
        - "soft smartcards" (PKC credentials which can be downloaded from a
remote server or held locally on a desktop -- but which can only be
accessed with a key which is send down from a SecurSight server which
demands SecurID two-factor authentication,) or
        - simple two-factor SecurID authentication (perhaps used in
conjunction with HTTPS, other SSL services, or complementary VPN products.

        While the SecurSight PKI will obviously have the potential to
support the full array of public-key cryptographic services, the first
version will use its RSA credentials to support the off-the-shelf X509-
enabled clients like web browsers and mailers; custom local apps; and a
variety of pre-wrapped network applications developed in conjunction with
some of SDTI's strategic partners. Ideally, these will be drop-in modules
which will offer SSL-encrypted internal tunnels to secure transactions and
interactions between desktop clients and mission-critical enterprise apps
from Oracle, Sybase, SAP, PeopleSoft, etc.

        SDTI's WebID kits today secure web server pages (and legacy
applications with web interfaces) so that they can only be accessed through
a SSL link. Within an enterprise PKI, SecurSight credentials will only
enhance the security of the mutual authentication and any subsequent
interaction.

        No one yet seems quite sure how the politics of US export controls
may bend, limit, or restrict the variety or integrity of PKI cryptographic
services that will be provided in the core SecurSight products. There will
obviously be a strong and immediate demand for (at least) digital
signatures and confidentiality. SDTI's RSA-designed toolkits will offer
ready solutions if and where they are allowed to be sold.

        Surete,
                _Vin

PS. I've broken a lot of SecurID cards over the past decade, while I've
been a dime-a-day consultant for SDTI. Luv the damn key fobs! I carry two;
sit on them almost daily -- and they just keep blinkin' at me.

-----
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which by
its nature will resist efforts to restrict it to bureaucrats and others who
deem only themselves worthy of such Privilege."
_ A Thinking Man's Creed for Crypto _vbm.

 * Vin McLellan + The Privacy Guild + <vin@shore.net> *
      53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548


New Message Reply About this list Date view Thread view Subject view Author view

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:20