Re: public key authentication

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 07/20/05 

Date: Wed, 20 Jul 2005 12:15:49 -0600

"Richard E. Silverman" <res@qoxp.net> writes:
> So are the long bit strings that are your private keys. Anything is
> "guessable," in the sense in which you're using it. The issue is
> whether it is feasible or likely for someone to guess it, and the
> answer with a long, random password is "no."
>
> The more important point here is the other issues with password
> authentication, such as:
>
> - it reveals your password to a possibly compromised server
>
> - it makes it more likely for people to select bad passwords, since they
> aren't using an automated tool like ssh-keygen
>
> - it does not resist MITM attacks
>
> - it is cumbersome to automate

these are somewhat at the micro-level ... aka a security officer
looking at passwords as a form of shared-secrets (or, if you will,
an institutional-centric viewpoint):
http://www.garlic.com/~lynn/subpubkey.html#secrets

... there is also the issue of shared-secrets being required to be
unique for every unique security domains. in the past when a person
was involved in one or two different security domains .. they had only
one or two shared secrets to memorize. now, it is not uncommon for
people to have scores of unique shared-secrets that they have to
memorize. taking the person-centric view ... this also has resulted in
reaching human factor limitations when humans now have to make some
sort of record of their scores of shared-secrets (because most humans
don't have the capacity to otherwise deal with the situation). The
necessity for resorting to some sort of recording infrastructure for
tracking the scores of shared-secrets opens up additional threats and
vulnerabilities.

the other compromise ... is some numbe of infrastructures, finding
that humans have a difficult time keeping track of unique,
infrastructure shared secrets ... are resorting to common information
that is known by the individual, like date-of-birth, mother's maiden
name, social security number, etc. this violates fundamental security
guidelines (but recognizes that there are common human limitations)
... and as led to a lot of the current identity theft situations.

the institutional centric model doesn't allow from human limitations
having to deal with scores of different security domains, each
requiring their unique shared secret for authentication. the person
centric model recognizes that individuals when dealing with scores of
unique security domains, each requiring unique shared secrets, isn't a
practical paradigm for people.

the basic asymmetric key technology allows for one key (of a key-pair)
for encoding information with the other key decoding the information
(as opposed to symmmetric key technology where the same key is used
for both decoding and encoding).

there is a business process called public key ... where one key (of a
key pair) is identified as public and freely distributed. The other
key (of the key pair) is identified is private, kept confidential and
never divulged.

there is a business process called digital signature ... where the
hash of a message (or document) is calculated and then encoded with
the private key producing a "digital signature". the recipient then
recalculates the hash of the message, decodes the digital signature
(with the correct public key, producing the original hash), and
compares the two hash values. If the two hash values are the same,
then the recipient can assume

1) the message/text hasn't been modified since being digitally signed

2) "something you have" authentication ... aka the originator has
access to and use of the corresponding private key.

>From 3-factor authentication:
http://www.garlic.com/~lynn/subpubkey.html#html

* something you have
* something you know
* something you are

... shared-secrets can be considered a form of "something you know"
authentication and digital signatures a form of "something you have"
authentication.

The integrity of digital signature authentication can be improved by
using certified hardware tokens where the key pair is generated on the
token and the private key is protected from every leaving the token.
Where a private key is certified as only existing in a specific kind
of hardware token ... then digital signature verification can somewhat
equate the access and use of the private key as equivalent to the
access and use of the hardware token (of known integrity
characteristics).

There has been some amount of stuff in the press about the benefits of
two-factor authentication (possibly requiring both "something you
have" and "something you know"). The issue really comes down to
whether the two factors are resistant to common vulnerability and
threats. An example is PIN-debit payment cards which are considered
two-factor authentication ... i.e. the "something you have" magstripe
card and the "something you know" PIN (shared-secret).

The issue is that some of the ATM-overlay exploits can record both the
magstripe and the PIN ... resulting in a common vulnerability that
allows production of counterfeit card and fraudulent transactions.
The supposed scenario for two-factor authentication is that the
different factors have different vulnerabilities (don't have common
threats and vulnerabilities). Supposedly, the original PIN concept was
that if the card was lost or stolen (a "something you have"
vulnerability), then the crook wouldn't also have access to the
required PIN. Note, however, because of human memory limitations, it
is estimated that 30precent of PIN-debit cards have the PIN written on
them ... also creating a common threat/vulnerability.

public key hardware tokens can also require a PIN to operate. However,
there can be significant operational and human factors differences
between public key hardware tokens with PINs and a PIN-debit magstripe
cards:

1) the PIN is transferred to the hardware token for correct operation,
in the sense that you own the hardware token ... and the PIN is
never required by the rest of the infrastructure, it becomes a
"secret" rather than a "shared-secret"

2) in a person-centric envrionment, it would be possible to register
the same publickey/hardware token with multiple different
infrastructures (in part because, the public key can only be used to
verify, it can't be used to impersonate). this could drastically
minimize the number of unique hardware tokens an individual would have
to deal with (and correspondingly the number of PINs needed for each
unique token), possibly to one or two.

An institutional centric envrionment would issue a unique hardware
token to every individual and require that the individual choose a
unique (secret) PIN to activiate each token ... leading to a large
number of PINs to be remembered and increases the probability that
people would write the PIN on the token. A very small number of tokens
would mean that there would be a very small number of PINs to remember
(less taxing on human memory limitations) as well as increase the
frequency that the limited number of token/PINs were repeatedly used
(re-inforcing the human memory for specific PIN).

Substituting such a hardware token in a PIN-debit environment
... would still leave the PIN vulnerabile to ATM-overlays that skim
that static data; but the hardware token wouldn't be subject to
counterfeiting ... since the private key is never actually exposed.
In this case, the two-factors are vulnerable to different threats
.... so a single common attack wouldn't leave the individual exposed
to fraudulent transactions. The PIN makes the hardware token resistant
to common lost/stolen vulnerabilities and the hardware token makes the
PIN resistant to common skimming/recording vulnerabilities.

Encrypted software file private key implementations have some number
of additional vulnerabilities vis-a-vis a hardware token private key
implementation ... aka the compromise of your personal computer.
Normally the software file private key implementation requires a
PIN/password to decrypt the software file ... making the private key
available. A compromised personal computer can expose both the PIN
entry (key logging) and the encrypted private key file (allow a remote
attack to optain the encrypted file and use the pin/password to
decrypt it).

Note that the original pk-init draft for kerberos specified the simple
registration of public key in lieu of passwords and digital signature
authentication ... in much the same way that common SSH operates ...
http://www.garlic.com/~lynn/subpubkey.html#certless

and w/o requiring the expesne and complexity of deploying a PKI
certificate-based operation
http://www.garlic.com/~lynn/subpubkey.html#kerberos

similar kind of implementations have been done for radius ... where
public key is registered in lieu of password ... and straight-forward
digital signature verficiation performed ... again w/o the complexity
and expense of deploying a PKI certificate-based operation
http://www.garlic.com/~lynn/subpubkey.html#radius 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages

  • Re: X509 digital certificate for offline solution
    ... since the hardware tokens perform operations using the embedded private ... has accesws and use of the corresponding private key. ... i would assert that the integrity level of the originating environment ...
    (microsoft.public.dotnet.security)
  • RE: [fw-wiz] Username password VS hardware token plus PIN
    ... What is the value of hardware token with burned in PIN as compared to ... I am reasonably confident of the validity of the ... I fail to see the benefit of using hardware tokens that rely on a one time ... If you are not the intended recipient please notify the sender ...
    (Firewall-Wizards)
  • [fw-wiz] Username password VS hardware token plus PIN
    ... What is the value of hardware token with burned in PIN as compared to ... I fail to see the benefit of using hardware tokens that rely on a one time ... I have searched long and hard for a token that can use a username password ... If you are not the intended recipient please notify the sender ...
    (Firewall-Wizards)
  • Re: When rsa vs dsa
    ... one of the issues used to have to do with hardware tokens. ... which resulted in dsa ... a requirement for a random number NONCE in rsa-signed messages. ... with RSA (eliminating the private key vulnerability dependent on ...
    (comp.security.ssh)
  • RE: [Full-Disclosure] Clear text password exposure in Datakeys tokens and smartcards
    ... The host decides if the PIN matches. ... authentication information and pass both ... RSA also sells "software tokens" which are the same thing, ... (At least with the hardware tokens ...
    (Full-Disclosure)