Do You Need a Digital ID?
Anne & Lynn Wheeler
lynn at garlic.com
Mon Mar 21 10:27:53 EST 2005
now, i've said that all of these comments are within the 3 factor
authentication paradigm ... if you back up a couple paragraphs in the
original postings ... you will find the comments:
> given 3-factor authentication:
>
> * something you have
> * something you know
> * something you are
aka the comments/postings are within the framework/paradigm of 3-factor
authentication. so is the issue with the 3-factor authentication
framework ... or is the issue that the comments are inconsistent given a
3-factor authentication framework?
I assert (as stated in the original posting) that the comments/posting
is within the context of 3-factor authentication framework and the
definition of the public/private key business process. you are free to
define something other than 3-factor authentication framework .... or a
totally different business process for the treatment of asymmetric
cryptography keys.
a digital signature is something that is supposedly hard to counterfeit
.... and just represents the application of a private key to some data
(the digital signature is an indication/expression that a private key
has been accessed and used). for most entities, a private key is not
something that is memorized, but rather it is contained by something
that the human has. the integrity of the process is based on the
integrity of the infrastructure that controls the access and use of that
private key ... therefor a digital signature infrastructure typically
represents a "something you have" technology.
the whole asymmetric cryptography technology (of which a digital
signature is just a part) has been taken and a business process wrapped
afound it which is frequently referred to as public/private key
cryptography (an abbreviation frequently to simple public key
technology). the foundation of the public/private key (or public key
technology for short) business process is based on keeping the "private
key" actually "private". If everybody is allowed to have as free access
to the "private keys" as there is access to the "public key" ... the
whole infrastructure (including digital signatures) falls apart.
So if you are looking at a threat assessement ... the public/private key
business process allows for both digital signatures and public keys to
be readily known ... the whole foundation that holds the whole "public
key" business process together is based on keeping the private key
actually unknown and unaccessable to others than the authorized entities.
so i've haven't seen any private key deployments which are based on a
human actually memorizing the private key ... so it can't be a (at least
directly) a "something you know" operation. of the private key
deployments i've seen, there has been the requirement that an entity
possesses a "private key" and is able to access and make use of that
"private key" ... since it isn't "something you know" (and since a
"private key" is also not typically "something you are" biometrics) then
that leaves a "private key" representing "something you have".
so if you look at typical "something you have" infrastructures, their
integrity is based on the protection of the operations that access and
utilize the "something you have".
as i pointed out in one of the earlier postings, much of the literature
in the mid-90s grossly confused the the terms digital signature and
digital certificates and private key ... to the point that it sometimes
represented that a digital ceritifcate was responsible for generating a
digital signature (or by implication the public key included in a
digital certificate). Since the public/private key business process
allows for both digital signatures and public keys to be readily known,
it is fairly obvious that they can't be the integrity/security
foundation for the business process.
so when a digital signature is validated with a public key ... what is
it doing ... it is validating that the private key (of a public/private
key pair from asymmetric cryptography) generated that digital signature.
"private key" isn't a characteristic of asymmetric cryptography ... it
is a characteristic of public/private key business process requiring
that the "private key" be kept private. a digital signature is just an
expression of the business process use of that private key.
so from 3-factor authentication paradign there are three things:
* something you know authentication
* something you have authentication
* something you are authentciation
now, i know of no public/private key business process deployments that
require humans to memorize the private key ... that eliminates (at least
direct use of) "something you know" authentication.
the most common deployments of public/private key business process
deployment aren't based on biometrics ... which then eliminates
"something you are" authentication.
that just leaves "private keys" as a type of "something you have"
technology ... (since it isn't memorized or biometrics). therefor the
foundation of public/private key business process deployments
(frequently abbreviated to simply public key ... with the existance of a
corresponding pviate key assumed) is based on the possession of a
private key and the business processes of keeping that private key
actually private (and the business processes of uniquely being able to
use the private key and not having it widely available to large numbers
of unauthorized people).
now, usually once past the description of public key business processes
for public consumption (where it might actually be stated that the
digital signature was generated by the digital certificate) .... you
quickly get into the foundations which are based on
1) asymmetric key cryptography
2) business process of allowing one of the asymmetric key pair to be
made public
3) business process of allowing one of the asymmetric key pair to be
kept private
4) business process of consistently maintaining the privacy of the
designated private key.
repeating 3-factor authentication paradign
* something you know authentication
* something you have authentication
* soemthing you are authentication
digital signature is an expression of the private key business process
that consistently and reliably maintains the privacy of the private key.
private key isn't a technology (like asymmetric key cryptography is a
technology). private key is a business process application to asymmetric
key cryptography. the access and use of a private key is supposedly for
the purpose of reliably authenticating the entity associated with that
private key. so by process of elimination:
* how many public key deployments require the associated entity memorize
the "private key"
* how many public key deployments require that the private key be an
expression of some biometric for that entity
by process of elimination, if the "public key" deployments aren't
typically "something you know" or "something you are" ... then that just
leaves "public key" deployments to be "something you have" authentication.
now it is obvious that a specific physical object can be in unique
possession of a specific entity (modulo physical object counterfeiting).
however, the business process for public/private key defines that a
private key is in the unique possesion of a specific entity. not by law
of physics ... but by law of the business process. if you violate the
law of the business process and allow multiple entities to possess the
private key (say you include
both the private key and the public key in a widely published digital
certificate) then the whole public/private key business process would
come apart.
lots of past postings on 3-factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor
I do agree that (possibly because of the syntactic similarity) lots of
people confuse digital signature and real human signatures. A human
signature carries with it the connotation of understanding, aggreement,
approval, authorization, etc. A digital signature is simply the
expression of the access and use of a private key ... and the
definition/law of the public/private key business process is that the
private key be consistently protected and kept private so that relying
parties ... when verifying a particular digital signature ... can
associate it with the authentication of a specific entity.
There are several deployed infrastructures of the application of the
public/private key business process, where the digital signature
generation is simply for authentication purposes ... there is a human
that is responsible for activating the access and operation of the
private key for the generation of the digital signature ... w/o a
requirement that the human ever observes the contents of what the
digital signature is being applied to.
As previously mentioned numerous times before ... there is a dual-use
attack on public/private key infrastructures where there are procedures
in place that require a human to observe, read, and understand any bits
that are being digital signed. However, if the same private key that is
used in real "signature" applications, is also ever used in
authentication applications where the human doesn't observe and read the
contents, then the attacker just supplies a valid document masguerading
as authentication bits (which the human won't be reading and/or
understanding).
note that non-repudiation is sometimes referenced with regard to some
aspects of digital signatures being similar to human signatures (aka
read, observe, understand, approve, authorize, agree). the eu finread
definition tried to include some aspects of read, observe, understand,
approx, authorize, agree ... misc. past finread postings:
http://www.garlic.com/~lynn/subpubkey.html#finread
Jerrold Leichter wrote:
> This is a rather bizarre way of defining things. "Something you have" is a
> physical object. On the one hand, any physical object can be copied to an
> arbitrary degree of precision; on the other hand, no two physical objects are
> *identical*. So a distinction based on whether a replacement is "identical"
> to the original gets you nowhere.
>
> A digital signature is just a big number. In principal, it can be memorized,
> thus becoming "something you know". As a *number*, I don't see how it can, in
> and of itself, *ever* be something you *have*.
>
>From a purely information point of view, there is not, and cannot be, any
> difference among the different authentication modalities. A house key can be
> represented as a fairly short number (the key blank number and the pinning).
> Even a very fancy and elaborate key - or any physical object - can, in
> principle, be represented as a CAD file. While "something I am" is difficult
> to represent completely this way (at least today!), it doesn't matter: A
> "something I am" *authentication element* has to ultimately be testable for
> veracity on the basis of information the tester has access to.
>
> The meaningful distinction here has to do with possible modes of attack,
> constrained by the *physical* characteristics of the system. An
> authentication element is "something you have" if an attacker must gain
> physical possession of it to be able to authenticate as you. The "closeness"
> and length of time the attacker must possess the element form the fundamental
> "measures of quality" of such an element. A house key is a prototypical
> "something you have". Duplicating it requires the ability to physically hold
> it. (One can, of course, imagine taking very detailed photographs from a
> distance, or using some other kind of remote sensing technology. While
> possible in principle, this would be a very expensive and difficult attack in
> practice, and we generally ignore the possibility.) Keys with restricted
> blanks are relatively difficult to duplicate even if you have physical
> possession. We generally assume that you can take a key back, thus revoking
> access. This is also a general property of any "something you have"
> authentication element - and is truely present only to some degree. Still,
> one can meaningfully ask of such an element "How many copies are in existence?
> Who has access to them?"
>
> Conversely, "something you know" can, in principle, only be learned by you
> revealing it. Once revealed, a "something you know" element cannot be
> revoked. It can be copied easily, and determining who might know it is
> usually impractical once there is any suspicion of compromise.
>
> A key card by itself is like a blank house key. It becomes "something you
> have" when it's encoded with a password, a digital signature private key, or
> some other secret that's, say, part of an interactive zero-knowledge proof
> system. The quality of the key card depends on how easy it is to extract
> the information and produce another key card that can be used in its place.
>
> Of course, quality is a *system* property. A house key "reveals its secret"
> when placed in a lock - any lock. While I could easily enough build a lock that
> would read off the pinning of any key inserted into it and send it to me on
> the Internet, this doesn't at present appear to be a threat that needs to be
> defended against. We generally assume that locks are simple physical devices
> that don't leak any information. On the other hand, a key card by its very
> nature sends information into a digital system, and protecting information
> once it is in digital form is challenging. If I could know to a sufficient
> degree of certainty that my keycard would only be used in "secure" readers
> which would send the information no further, there would be relatively little
> difference between a key card with a simple password encoded on a magnetic
> strip, and a house hey. Both would provide a "something you have" element.
>
> A "digital signature" isn't an authentication element at all! We incorrectly
> analogize it to a traditional signature, because inherent in the notion of the
> latter is a whole system embodying assumptions like (a) a signature instance
> is physically created by the party being authenticated; (b) we can effectively
> distinguish an instance thus created from a duplicate. I can photocopy a
> signature perfectly. If it were impossible to distinguish a photocopy from an
> original - based on pen pressure on the paper, ink vs. toner, etc. -
> signatures would be completely worthless as authentication elements. To
> decide whether a "digital signature" is "something you have", "something you
> know", or perhaps even "something you are" - a signature based somehow on
> biometrics; or not a reaonable authentication element at all; requires knowing
> how the abstract bits that define that signature are actually used in the
> total physical system.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list