[1253] in cryptography@c2.net mail archive
Re: Fortezza dying on the vine?
daemon@ATHENA.MIT.EDU (Vin McLellan)
Sat Jul 26 13:19:00 1997
In-Reply-To: <v03007808affee9a0d078@[172.17.1.150]>
Date: Sat, 26 Jul 1997 02:56:01 -0500
To: Rick Smith <smith@securecomputing.com>
From: Vin McLellan <vin@shore.net>
Cc: cryptography@c2.net
>At 5:00 PM -0400 7/25/97, Bill Sommerfeld wrote:
>
>>One thing I wonder is whether the higher than anticipated
>>administrative costs of Fortezza will also apply to smartcard-type
>>systems. I'm presuming the expensive part is not the symmetric crypto
>>engine part but rather the PKI/digital signature side of Fortezza.
>>
>>Is it just USG mucking up, or is this going to be a general problem
>>with all hardware-widget based systems?
Rick Smith <smith@securecomputing.com> responded:
>There are lots of hardware based authentication systems out there right now
>-- Safeword, SecurID, Digital Pathways, etc. Although the actual behavior
>is different than crypto cards (they just generate pass codes), they are
>also subject to administrative tinkering like rekeying. Companies that use
>them don't seem to find them too expensive to administer.
I don't think the problem will be in the hardware widgets (i.e.,
smartcards) -- although I do think all us old OTP mavens will remember
fondly the dedicated simplicity of our hand-held authentication tokens
(which don't have any direct circuit connection with the user's machine, or
the network beyond.)
I don't know the distribution of maintenance costs for Fortezza,
but I wouldn't be surprised if the PCMCIA card-slots (the readers) are a
problem. COTS PCMCIA slots -- as almost everyone with a laptop can see at a
glance -- are not made for the repeated in/out use foreseen for Fortezza
"cryptocards."
I'm a little more pessimistic than Rick. I do expect key and cert
management to quickly become a bear. Chained certs will define a whole new
class of administrative headache.
I also expect that notation on 509-type certificates will very
quickly be called upon to carry the weight of privilege management for the
OS or the network, which may add an entertaining layer or two to cert
management.
Fortezza also never bothered to support machine to machine
authentication -- but the real world will demand that... and fairly soon
thereafter, authentication for processes, programs, and agents as well.
Key generation and distribution are also interesting administrative
challenges. Fortezza, with LEAF key-escrow, obviously had special burdens,
which may or may not be forced on commercial PKI -- but, just in terms of
coordination, Fortezza (with built-in universal GAK) also had/has an
advantage in that key generation (all four PKI keys: key-exchange and
digital sig, both public and private) is centralized.
Maintaining the integrity of digital signatures outside dot-GOV may
require transferring a lot more responsibility to the user. Fine in theory
-- in practice, maybe a sysadmin's worst nightmare.
Sorry to say, but I don't think the Fortezza field staff "mucked up."
I think managing hierarchical PKI will be a <sigh> worthy
challenge for the private sector, just as it has been (and will be) for the
public sector.
Suerte,
_Vin
>Other differences that might make a difference:
>
>1) Secret key vs public key. Perhaps this is a wash, since tinkering with
>private keys likewise requires secrecy.
>
>2) Elaborate PKI vs enterprise or site based management. This might be a
>big one -- it costs less if you don't have to synch up with some higher
>level organization in order to validate your keys. The costs of a higher
>level PKI doesn't have to be amortized among its users -- the company
>doesn't have to pay for a partial share in someone's Safekeyper purchase or
>the armed guards at the bunker's front door.
>
>Another big piece of the Fortezza story is that they sold a demo system,
>not one that was ready for use. They tried to push cards out to customers
>before they had solid, reliable equipment for certification. They still
>don't. Another turnoff has been NSA's policy of subjecting the cards to an
>incompatible upgrade about once a year. The cards, CA stations, and all
>applications are usually affected. This is not productive.
>
>Rick.
>smith@securecomputing.com Secure Computing Corporation
>"Internet Cryptography" in bookstores soon http://www.visi.com/crypto/
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
-- <@><@> --
