Cryptography-Digest Digest #277, Volume #9 Wed, 24 Mar 99 12:13:03 EST
Contents:
Re: Encryption and the Linux password files (Chris Monico)
Re: Random Walk ("Tony T. Warnock")
CD Cipher (R. Knauer)
Re: Securid Card ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Re: Encryption and the Linux password files
Date: Wed, 24 Mar 99 06:22:45 GMT
In article <[EMAIL PROTECTED]>,
Sundial Services <[EMAIL PROTECTED]> wrote:
>I'm rather startled to find that Linux still uses a login password
>scheme that is based on a publicly-available password file that is
>easily replaced or substituted. Systems have been "taken over" in
that
>way.
Any box with a competent sys admin has a shadowed passfile, and not
simply the default /etc/password.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Random Walk
Date: Wed, 24 Mar 1999 08:35:35 -0700
Reply-To: [EMAIL PROTECTED]
"R. Knauer" wrote:
>
> I said that statistical tests for randomness assume infinite
> sequences. That is a completely different thing that what you claim I
> said.
>
> Infinite sequences require a continuous sample space, and finite
> sequences are sampled from a discrete sample space. Do you have any
> idea what that means?
>
The above two statements are false. Statistical tests do not assume
infninte sequences in the first case and one may sample a finite sequence
from a discrete space.
Tony
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: CD Cipher
Date: Fri, 12 Mar 1999 15:58:29 GMT
Reply-To: [EMAIL PROTECTED]
I refer you to Sec. 2.1.5 (p. 18) of the book "Stream Ciphers and
Number Theory".
In that section, the authors propose a system which combines the best
of stream ciphers and block ciphers, and prevents traditional attacks
on those cipher methods. The even go so far as to say that because
this Cooperatively Distributed Cipher (CD Cipher) is strong, that one
can use relatively week keystreams and relatively weak block
encryption methods. IOW, "good + bad = good".
The basic idea is that there are multiple block cipher keys Ki, where
i enumerates them. The main keystream K is used to select which Ki to
use on a given block of plaintext P. Thus the entire key is (K, {Ki}).
According to the authors, this is the best of two worlds, since it
prevents both block cipher attacks and stream cipher attacks. As they
point out, block cipher attacks work because they use only one key,
which is no longer the case here. Stream cipher attacks work because
of additive mixing, which is no longer the case here.
The simplest implementation is for i = 0, 1 - that is, there are two
disctinct keys for block encryption present. Then the bits of the main
keystream K act as selectors for which Ki to use for a given block of
plaintext.
If I read all this correctly, then one could presumably use a weak
main keystream generator and a weak block encryption method to form
the basis of a strong system. IOW, the only keys that need to be sent
along a secure channel are the seedkey for the main keystream
generator and the two keys for block encryption. If one used a 128 bit
seedkey for the main PRNG and two DES block encryption keys, then the
total key for the system would be only 240 bits.
To make this system even stronger one could use two completely
different block encrytion methods with different block sizes, such
that the block sizes are not commensurate. That way the attacker will
not know the block boundaries in the ciphertext.
Your considered comments, please.
Bob Knauer
"My choice early in life was either to be a piano-player in a whorehouse
or a politician. And to tell the truth there's hardly any difference."
-- Harry Truman
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Securid Card
Date: Wed, 24 Mar 1999 12:52:58 GMT
Dear Vin
I am interested in how SecurID interacts with other third party apps - you
mentioned that terminal servers may contain securid code - please can you
provide some more info on how SecurID works with Terminal server. For example,
do you put the ace agent on the ts and if so how do you authenticate to other
apps in a ts session?
Also, if you have any knowledge of using SecurID in a Lotus Notes environment
i.e to get access to mailboxes and shared databases your comments would be
much appreciated. It seems that there is no ace agent for Notes - a bit of a
problem for those of us with large Notes infrastructures. Thanks for the help
Steve Myers
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> The response to Loomis Farkle's query indicated both interest
> and some confusion about the internals of the ACE/SecurID system, so
> -- in an admittedly longish post (fair warning!) -- I thought to offer
> some design details about the SecurID token, and answer the questions
> that have been raised about how the SecurID interacts with Security
> Dynamics' authentication engine, what SDTI calls the ACE/Server.
>
> Loomis Farkle <[EMAIL PROTECTED]> asked:
>
> >> Does anyone know what the protocol is in these cards? Is it
> >> encrypting my PIN with a public key and the server is decrypting it
> >> with a private key and matching it to the password database? Is
> >> it symmetric with the PIN being the key and the only real defense
> >> being the rapidly changing plaintext/ciphertext in the card?
>
> Paul Rubin <[EMAIL PROTECTED]> responded:
>
> > Symmetric key with the key being inside the card (the server has to
> > know the card's serial number).
>
> Not quite right. Both the SecurID tokens and the ACE
> authentication server use a 14 year-old SDTI-proprietary hash -- by
> John Brainard, now with RSA Labs, an SDTI subsidiary -- to generate
> the "60-second" token-code that is displayed on the SecurID's LCD
> screen. The server does know the card's serial number, but (for an
> assigned SecurID) it need not. The records of about the token are also
> indexed on the basis of the assigned user's name in the ACE/Server
> database.
>
> In a SecurID, a token-specific secret key (seed) and "Current
> Time" are continuously and automatically hashed through Brainard's
> one-way function to generate a series of 6 to 8 digit token-codes. The
> LCD display on the SecurID changes every every 60 seconds. The
> token-codes are one-time passwords (OTPs), which are valid only very
> briefly, and then not at all.
>
> SDTI has patents that covers the mechanics of how its
> authentication server manages to synchronize its clock, on the fly,
> with each SecurID token which is register to it. Those patents have
> allowed SDTI to hold a virtual monopoly over this type of "time
> synched" hand-held authentication (HHA) token.
>
> The classic SecurID is a simple token -- either the size of a thick
> credit card, or in a key fob form-factor -- which continuously
> displays a changing 6-8 digit (or alphanumic) token-code. Most of the
> several million which have been sold do not have any input pad; a
> token-holder simply reads the token-code off the LCD with a glance and
> types it in at a keyboard, pre-pended by a PIN, like a longish
> traditional password.
>
> [The SecurID Mr. Farkle described was a PinPad version of the
> SecurID, an adaption of the traditional design for unencrypted network
> links. With the PinPad SecurID, the PIN is input into the token on a
> small keypad and literally added (no carry) to a pseudo-random numeric
> token-code to secure the PIN against eavesdroppers.]
>
> Buttressed by a memorized PIN, all versions of the SecurID
> offer two-factor user authentication ("sometime known," plus
> "something held"). The traditional SecurID became popular with users
> largely because it offered a clear ease-of-use advantage over its
> various competitors, which typically rely upon a challege/response
> exchange. Historically, this advantage let ACE/SecurID dominate the
> market for two-factor user authentication, particularly in corporate
> environments with 1,500 or more seats.
>
> I've been a consultant to SDTI for many years, so any opinions
> I offer should be taken with an appropriate grain of salt. I also
> wrote a widely-circulated SecurID FAQ in '95 -- now somewhat dated,
> unfortunately.
>
> When the SecurID first appeared a decade ago, I thought it was (from
> the user's point of view) a model of delicious simplicity compared to
> other token-based HHA systems. As IT professionals absorb the burdens
> of PKI, I dare say that others will quickly gain a new appreciation
> for the elegant simplicity that underlies this whole class of
> hand-held authenticators.
>
> [Compared to other costs involved in putting a user online,
> HHAs are cheap; what they offer -- the assurance of strong user
> authentication -- is often invaluable; and what they do is
> transparent. Since HHAs have no direct circuit connection to the
> user's network, workstation, or server, everyone can be utterly
> certain that they do no more than what they appear to do. That's an
> assurance difficult to obtain from any device that is wired directly
> into the host or network. Even a plugged-in smartcard.]
>
> How does it work? As others have noted, the ACE/Server
> continuously records the relative "drift" of the token's clock-chip
> (relative to the Server's clock, which is presumed <ahem> to be
> perfectly accurate.)
>
> When a user submits his name and a two-factor authentication
> call -- the 6-8 digit SecurID token-code, and a 4-8 digit PIN -- to
> the ACE/Server with a request for authentication of his pre-registered
> identity, the Server routinely checks its historical record for the
> relative "clock drift" associated with that particular token. Based on
> that record, the ACE/Server adds or subtracts a delta to synchronize,
> on the fly, the Server's calculation of "Current Time" and the version
> of "Current Time" used in that particular SecurID.
>
> The ACE/Server's database also hold an (encrypted) record of
> the seed for each token. The Server grabs the seed, and what it
> calculates to be the Current Time used in that particular token, and
> hashes them into a token-code. The result is then compared against the
> information submitted by the remote user seeking authentication.
>
> (This is a closed system, so the term "Current Time" is a bit
> of a misnomer. There is no need to have the ACE/Server's time set at
> GMT, or to have any set relationship with Time in the real world,
> unless there are other apps on the host which require it.)
>
> Actually, the ACE/Server automatically generates three
> consecutive (but pseudo-random) token-codes to match against the
> token-code which -- with a user name and PIN -- is submitted to the
> ACE/Server by a remote user. The three token-code spread or window is
> an adaption deemed necessary to address the likelyhood of "drift" from
> a precise time-line in either the token's clock-chip or the Server's
> clock.
>
> Only if the token-code submitted, with a valid PIN, by the
> user matches one of these three token-codes -- hashed with consecutive
> counts of Current Time, with one-minute intervals -- is the user's
> identity authenticated by the ACE/Server and his access privileges
> validated.
>
> In the typical ACE client/server installation, a remote user
> connects to an ACE/Client, and the ACE/Client uses the ACE protocol --
> which depends upon DES and F2, another SDTI-proprietary hash (designed
> by Ron Rivest)-- to further secure the authentication exchange between
> the ACE/Client and the ACE/Server.
>
> [Given that SDTI is the company that bankrolled RSA's DES
> Challenge Contests, which have so flamboyantly documented the relative
> weakness of DES, SDTI has -- IMNSHO -- been a little slow in upgrading
> the crypto in their DES-based client/server protocol. Remember,
> however, that the crypto in the ACE c/s protocol is only protecting an
> OTP with a brief half-life: a token-code valuable only for a minute or
> so. A year ago, at the RSA'98 Crypto Conference, SDTI published the
> design of the standardized SSL-based strong-crypto protocol which is
> gradually replacing the traditional ACE c/s protocol.]
>
> Many third-party remote access apps (terminal servers and
> firewalls, for example) now ship with integrated ACE/Client code.
> VPNs, SSL, SSH, or other encryption systems are often used today to
> secure the clear-text outward link -- from the user to the ACE/Client
> -- to protect it against active network attacks (like TCP splicing)
> and secure any subsequent transactions or data flow. Most of the
> leading VPNs today ship with integrated ACE/Client code too.
>
> ACE client/server applications are the norm, but there are
> other SecurID authentication systems in which the "server functions"
> are packaged in small stand-alone hardware boxes or, at the other end
> of the scale, in the speedy (1,000+ authentications/second) systems
> used by the huge ISPs (AOL, CIS, or MCI, for example) as a MVS or OS
> 390 mainframe app.
>
> Bradley Yearwood <[EMAIL PROTECTED]> recalled:
>
> |||> [...] From time to time, the server will decide to ask you to
> |||> wait for the next code to appear, and enter that. Whether this
> |||> is a measure to reinforce against some at least theoretical
> |||> weakness, or to help resynchronize to a highly skewed token, I am
> |||> not certain.
>
> This is a routine ACE/Server protocol to resynchronize the
> SecurID token's clock-crystal with the Server's clock. This protocol
> -- what an ACE Admin would call "Next Token Mode" -- is used to
> account for "drift" at either end: in a specific SecurID, or in the
> Server that supports it. It can indicate a need to resynch a token,
> but remember that the protocol works on the unlikely presumption that
> the server's clock is stable and precise.
>
> In fact, the token's clock-chip is quite stable -- far better
> than the typical digital watch -- and the bothersome Next Token demand
> is often required to address some hiccup or reset of the server's
> host. It is surely a rank injustice that the poor SecurID usually gets
> the blame, as in Mr. Yearwood's assumption that the irksome
> once-in-a-while demand for two consecutive token-codes was caused by
> "a highly skewed token."
>
> Mr. Farkle asked:
>
> /> [...] How does the server know the card's serial number?
>
> When he receives a shipment of new SecurID tokens, the Admin
> or owner of an ACE/Server also gets an encrypted disk with the secret
> seeds (indexed by serial number) for all the tokens he has purchased.
> The (unique, 64-bit, true-random) seeds have already been programmed
> into each token by SDTI as part of the manufacturing process.
>
> The ACE Administrator loads the list of seeds into the
> ACE/Server RDBS. As he assigns the tokens to individual users (whose
> identity has been vouched for "out of band") the Admin makes a
> notation in the ACE/Server database as to which token has been
> assigned to which user.
>
> The token's serial number -- embossed on the back of most
> SecurID cards or key-fobs; perhaps still sticker-labelled on others --
> is used _only_ to index the seeds for the Admin's on-site assignment
> of the token to the user. (A SecurID's serial number does not, of
> course, figure at all in the calculation of a SecurID token-code.
> There is an amazingly rich -- albiet ridiculous -- lore of rumor to
> the contrary;-)
>
> Two-factor authentication is the traditional definition of
> "strong user authentication." With the first use of a SecurID, the
> token is locked into what SDTI calls New PIN Mode: waiting for (a) the
> user to define his or her 6-8 digit PIN, or (b) the user to accept and
> acknowledge a PIN generated by the ACE/Server, or (c) for the user to
> choose (a) or (b).
>
> (The ACE Admin configures these options in accordance with his
> local security policy. For the first logon with a new SecurID --
> before a user can be dropped into New PIN Mode -- a token-holder is
> usually told to use some fixed identifier, often his name, as the
> initial PIN.)
>
> Mr. Farkle asked:
>
> >>Since this system relies rather heavily on the card and the server
> >>being in sync, what is the accuracy of the card's time function?
>
> Mr. Rubin replied:
>
> >Similar to a digital watch. The server notices as the card's clock
> >drifts, and adjusts for this.
>
> The error range for the crystal used in a SecurID's clock-chip
> is, as I recall, guarranteed to be less than ten parts per million --
> which means the token should not drift off its absolute time-line by
> more than a second every couple of days; maybe 2 minutes per year; ten
> minutes over a SecurID's max five-year lifespan.
>
> In manufacturing the SecurID, however, SDTI takes that
> worst-case scenario and refines it by precisely measuring the drift in
> a specific chip and coding a software correction for it into the
> token. That cuts the SecurID's base-line drift in the hardware to
> maybe a couple of seconds per month.
>
> It's the unpredictable enironmental factors -- notably
> climate; heat and cold -- that introduce wild cards that distort the
> SecurID's time-line over the life of a token. The mechanics by which
> the ACE/Server tracks those effects, and adapts to whatever
> distortions they (and the management of the server) introduce into the
> token/server synchronization is the patented heart of the ACE/SecurID
> system.
>
> Mr. Farkle:
>
> /> How would the server be able to notice the clock drift?
>
> It is not difficult to track a SecurID's clock-drift (relative
> to the ACE/Server's version of "Current Time") as the token is used.
>
> The ACE/Server maintains a record of how closely a particular
> SecurID hews to the projected (and constantly updated) time-line the
> ACE/Server calculates for it, each time it is used. The server's
> database also records, for each user/SecurID, which token-codes have
> been used, and when -- so it always knows how long it has been since a
> particular SecurID was last used.
>
> A lot of the predicable attacks on a Time-based system are
> effectively blocked just because the ACE/Server will not accept the
> repeat use of a token-code from the same SecurID.
>
> Another ACE/Server guideline: any three consecutive "bad
> logins" with a SecurID -- either a good-PIN/bad-token-code, or
> bad-PIN/good token-code combination -- will result in the ACE/Server
> disabling the account until it is reset by the Administrator.
>
> Mr. Farkle:
>
> /> [...] There's a potential of having several thousand users in this
> /> system -- would the server really be deducing clock drift info from
> /> a 6 digit number that also has to contain an authentication and
> /> keep a database on all the users?
>
> As Mr. Rubin dryly noted, this is "not a terribly large
> database by today's standards." The ACE/Server's built-in Progress
> RDBS has no problem managing this data for tens of thousands of users.
> Also, the 6-8 digit SecurID token-code does not exactly "contain" an
> authentication; it merely provides timely evidence that the remote
> user has immediate access to that particular SecurID at this moment.
>
> Tracking any drift in the token/server synchronization is not
> particularly difficult (and it is simplified by the design decision
> that has the token's clock brought into allignment with the
> ACE/Server's clock, which is presumed to be accurate and stable.)
>
> The SecurID token-code is a hash of Current Time and the
> SecurID's secret seed. If the ACE/Server can calculate (or, failing
> that, systematically guess) what the token is using for "Current
> Time," the difference between whatever version of "Current Time" was
> used to generate a particular token-code, and what the ACE/Server
> expected that token to use as "Current Time," becomes self-evident.
> (The ACE/Server has a routine to discover this, but it
> separate and distinct from the authentication cycle that approves or
> disapproves a particular authentication call.)
>
> Lyal Collins <[EMAIL PROTECTED]> noted:
>
> ||> Apparently there is a parameter on how many minutes (sub-minute
> ||> drift is not an issue) the server is allowed to "try" either side
> ||> of the current server time.
>
> The potential for unpredicable "drift" in one of the two
> time-lines (token and server) being synchronized is what led the SDTI
> designers to use a three token-code "window" as their target, when an
> incoming authentication call requires a comparison and match between
> the two.
>
> In its authentication cycle, the ACE/Server automatically
> calculates three token-codes when it receives a user's logon name: one
> for the one-minute time-slot before, and one for the one-minute
> time-slot after, whatever precise (to the minute) "Current Time" the
> ACE/Server expects this particular SecurID to use in generating a
> token-code.
>
> Only if the user submits the correct PIN and one of those
> three token-codes does the ACE/Server authenticate him.
>
> In addition to this authentication cycle, however, the ACE
> system has a reset cycle -- an attempt to minimize the number of valid
> users who could have their logons rejected because of some drift in
> their token's time-line, or some minor hiccup in the operation or
> <blush> human administration of the ACE/Server's platform.
>
> This is what happens: when a user submits a valid name and a
> valid PIN -- but with a SecurID token-code that is not one of the
> three pre-calculated by the ACE/Server -- the server automatically
> drops into a search pattern, a reset mode, to check on whether there
> has been some unexpected drift in the token's version of "Current
> Time," or in the time-line generated by the ACE/Server itself.
>
> Again: this is not an authentication cycle -- a PIN/SecurID
> combination is validated (and the user's identify authenticated)
> _only_ if the ACE/Server successfully matches an incoming
> authentication call against one of the three token-codes it just
> hashed, using its ACE database records of this token's secrets.
>
> In its automatic reset mode, the ACE/Server expands the search
> window slightly -- often one minute to either side of the three
> token-code target -- to look for valid tokens with time-chips which
> have, for whatever reason, fallen out of synchronization with the
> ACE/Server.
>
> The size of the window searched by the ACE/Server in reset
> mode is configurable by the local ACE Admin, but it typically varies
> according to how long it has been since that particular token
> (identified by the user's name) has been used.
>
> Minimally, reset mode calculates two additional time-codes --
> for the one-minute time slot before and after the three token-codes
> initially checked in the authentication cycle.
>
> That window can be incrimentally expanded -- by one time-code
> (a one-minute variance in Current Time) to either side for the base
> three -- for every two weeks that this particular SecurID has not been
> used, but only so far. Even if this SecurID has not be used for 6
> months or more, the search window can not be extended to cover more
> than a ten-minute drift from whatever the server initially expected
> this SecurID to use as "Current Time."
>
> Thus, for a SecurID that is used daily or even weekly, a good
> PIN, but bad token-code, combination -- even a typo in the user's
> routine input of the PIN/token-code at a keyboard -- will result in
> the ACE/Server quickly calculating two additional token-code to make
> certain that there was not some unexpected drift in the token's
> time-chip.
>
> For a token that has not been used in a six months to a year,
> an ACE/Server may generate a list of 21 potentially valid token-codes
> to compare against one submitted by a remote user who also had a valid
> user name and PIN. (Local site policy may be tighter than this, and
> many are, but it can not be any more expansive than this.)
>
> Whether it was off by one or ten minutes, a match between an
> incoming token-code and one of those calculated by an ACE/Server in
> this extended search pattern _never_ results in that remote user being
> authenticated. At best, it merely short-cuts the procedure of a second
> logon -- and quickly gives him a second chance to prove that he holds
> the SecurID assigned to him -- by inviting him to submit another valid
> token-code.
>
> To summarize the mechanics: if an ACE/Server drops into reset
> mode, calculates this expanded list of two to 18 additional
> token-codes, and discovers a match to the submitted token-code in this
> expanded list, the database records the apparent drift of the token's
> clock-chip.
>
> The ACE/Server then rolls back into its authentication cycle
> to demand a new and different SecurID token-code from the remote user.
> This second SecurID token-code is then matched against a new
> calculation of three token-codes, adjusted according to the new
> information about that token's apparent drift.
>
> <Whew!> I beg pardon for the wordy explanation, but the
> mechanics involved in this resynch process -- and the statistical
> impact of the reset upon the odds of someone trying to guess two
> consecutive 6-8 digit random numbers out of that huge solution space
> -- has confused bright people over the past decade.
>
> Mr. Collins, more tersely than I, tried to summarize:
>
> ||> Greater time windows allows potential for token misuse, replay
> ||> etc. Narrow widows mean drift (ie battery voltage, temperature
> ||> etc) problems cause lock-outs.
>
> In terms of the winner's circle of three token-codes which
> will result in a remote SecurID user (who has the proper PIN) getting
> authenticated, I guess this is overtly true. (Although, with a
> SecurID, replay attacks are not an issue, since a given token-code is
> not accepted twice from the same token.)
>
> It is not accurate, however, to imply that the reset cycle --
> looking for valid tokens which have drifted from their expected
> time-time -- effectively expands that inner three-token-code window
> and opens additional vulnerabilities.
>
> If an illegitimate "user" was able to get a valid user's name
> and also compromise that user's PIN -- but was unable to steal the
> appropriate SecurID token -- to gain illicit access he would have to
> be lucky enough to guess one of three random numbers in a solution
> space of 100 million possible 8-digit numbers.
>
> And with three consecutive bad guesses, the ACE/Server
> automatically blocks the account.
>
> If an attacker didn't guess one of the three -- but was lucky
> enough to guess one of the 21 token-codes calculated in the
> ACE/Server's extended search pattern -- the best he can expect is to
> be given another chance to submit a second valid SecurID token-code.
> So his odds go to hell and he is worse off.
>
> The likelyhood of an attacker correctly guessing _two_
> pseudo-random 8-digit token-codes in the correct sequence from among
> the whole solution space of 8-digit possibilities run something like
> one in 250 trillion.
>
> Leadacid <[EMAIL PROTECTED]> suggested a type
> of "attack" on the ACE/Server, but even he admitted that he didn't see
> how it could benefit even a malicious valid user.
>
> >/> [...] you could deliberately make it look like your card's clock
> >/> was dying. A moment before you log in, jot down the number from
> >/> the card. Wait say 2 minutes and log in. Just in case, write down
> >/> the next number and delay that the same amount of time, in case
> >/> the server asks for a second number. Next time you log in, write
> >/> down the numbers and wait 3 minutes before logging in, etc.
> >/> Pretty soon you'll have the server _expecting_ to see your numbers
> >/> skewed by 10 minutes.
>
> Awkward and difficult, and to what end? A valid SecurID user
> could undoubtedly fake a gradual skew in his SecurID's token-code, but
> even if he avoided a Next Token challenge (and/or a visit from an
> irritated network security administrator), I don't see a vulnerability
> here.
>
> SDTI's ACE/SecurID system is one of the Grand Old Ladies of
> computer security. Its foibles are known and its capabilities are well
> understood by the corporate network managers who depend upon it. That
> is why -- despite the fact that user authentication is now an
> incredibly dynamic market with an wide array of new PKI and cert-based
> technologies -- SecurIDs are likely to remain in widespread use.
>
> SDTI now offers a new authentication system, Keon, which reveiled
> SDTI's PKI, digital sig, and X.509 cert-based resource management
> scheme with single signon: <http://www.securid.com>. One of the more
> interesting aspect of this new family of RSA-based authentication
> products is that it can use either traditional smartcards or "soft
> smartcards" to hold user credentials.
>
> The soft smartcard scheme uses a PSE or e wallet to hold the user's
> encrypted credentials (certs and PKC keys) either locally on a
> workstation or on a Keon Server elsewhere on the network. With an SSL
> connection, the Keon Server can drop a symmetric decryption key to a
> mobile user (or a user who can not adequately secure his workstation)
> after the user submits a PIN and SecurID token-code to authenticate
> himself.
>
> I beg the indulgence of the Newsgroup for the length of this post. I
> hope it addressed the questions that were raised. If anyone has any
> additional questions, public or private, I'll try to answer them.
>
> Surete,
>
> _Vin
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
