> 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 [EMAIL PROTECTED]
