Do You Need a Digital ID?

Jerrold Leichter jerrold.leichter at smarts.com
Mon Mar 21 18:52:49 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 don't think the 3-factor authentication framework is nearly as well-defined
as people make it out to be.

Here is what I've always taken to be the core distinctions among the three
prongs:

	Something you know
		Can be copied.
		If copied illicitly, you can't tell (except by noticing
			illicit uses).

	Something you have
		Cannot be copied.
		Can be transferred (i.e., you can give it to someone
			else, but then you no longer have it)
		Hence, if transferred illicitly, you can quickly detect it.

	Something you are
		Cannot be transferred.
		Cannot be changed.
		Inherently tied to your identity, not your role.

This classification, useful as it is, certainly doesn't cover the space of
possible authentication techniques.  For example, an RFID chip embedded under
the skin and designed to destroy itself if removed doesn't exactly match any
of these sets of properties:  It's not "something you have" because it can't
be transferred, but it's not "something you are" because it can be changed.
Attempting to force-fit everything into an incomplete model doesn't strike me
as a useful exercise.

| 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.
Yes, this *entire system* - a private key embedded in a device that protects
the secret key embedded in it - is properly described as "something you have".
But people use the phrase "digital signature" to describe other systems as
well.  The laws on acceptable "digital signatures" are broad enough to include
way more than this - in fact, way more than is really reasonable.  If my
secret key is stored en clair in a file on a general-purpose computer that
provides no protection against copying, it still acts in some ways like
"something I have", but it lacks the "cannot be copied" attribute that seems
central to the notion.  On the other hand, if the secret key is stored in a
file encrypted using a pass phrase that I memorize, the entire system takes on
the security properties of "something I know", even though it has a physical
embodiment.

| 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