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