Re: Do You Need a Digital ID?
minor addenda ... ref: http://www.garlic.com/~lynn/aadsm19.htm#1 Do You Need a Digital ID? http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID? there are 2nd order implementations of public/private key authentication business process where keeping the private key private might involve * keeping the private key in an encrypted file and a pin/password is required to decrypt a file. this could be considered a possibly weak form of two-factor authentication: 1) possession of the encrypted file and 2) possession of the key to decrypt the file (it may in fact be considered so weak that many might considerd it only one-factor authentication, the knowledge of the key to decrypt the file). * keeping the private key in a token ... where the characteristics of the private key and the token holding the private key are taken as equivalent. the simple token/private-key equivalence is then one-factor something you have authentication ... aka a) digital signature is an expression of access and use of the private key and b) access and use of the private key is an expression of the possession of the token. * a private key token that requires PIN and/or biometrics to operate in specific manner ... a relying party with business process certification of the private key only existing in a specific token and that the specific token is also certified as to requiring specific PIN and/or biometrics then possibly the relying party can assume some form of two factor authentication (or even three factor authentication); the digital signature is an expression of the access and use of the private key, the access and use of the private is an expression of a combination of a) possession of a specific hardware token, b) corresponding PIN for that specific hardware token to operate in a specific manner and/or c) biometric for that specific hardware token to operate in a specific manner. note in the old fashion identity digital certificates from the early 90s ... there was frequently little or no discussion as to the integrity requirements regarding the ability to access and use a specific private key (which is what the whole private/public key business process is fundamentally built on). there was frequently lots of documentation on what a certification authority might do in the integrity around the generation of an identity digital certificate but very little or nothing about what the key owner was required to do in order to enable the whole fundamental public/private key business process to operate correctly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Do You Need a Digital ID?
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
Re: Do You Need a Digital ID?
| 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
Re: Do You Need a Digital ID?
Now that the taxing bodies (US states) have learned not to print the SSN on the mailing label, Illinois has gone further and requires a state-assigned PIN to file or access your tax information over the internet. They helpfully provide you the PIN ... on the mailing label. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Do You Need a Digital ID?
Jerrold Leichter wrote: 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. but business rules for public(/private) key infrastructure can describe that only the associated authenticating entity is the only one in possession of the private key (something you have) as a way of relating the objective of having a specific entity's exclusive ability to access and utilize a private key to three factor authentication. almost all of the existing something you have authentication objects are capable of being counterfeited to a greater or lesser degree. possibly the widest deployed something you have authentication objects are magstripe plastic cards ... and it turns out they have been proven to be remarkably easy to counterfeit/copied. the distinction between the ease or difficulty of counterfeiting/copying a magstripe plastic card vis-a-vis a private key ... depends on the level of security used to prevent it from being copied. obviously a private key can be copied with relative ease (possibly much easier than a magstripe plastic card). in general, you will find that almost all something you have authentication objects are subject to being copied ... the issue is the degree to which security processes are in place to prevent them from being copied. just because a private key ... represented by some sequence of bits can be easily copied ... when no protections are in force ... doesn't mean that there can't be security procedures put into place that would make it extremely difficult to achieve copying of a private key. most models serve a useful purpose until somebody comes up with a better or more applicable model. many of the 3-factor authentication implementations actually use some representation that allows the actual occurence to be implied by something else. for instance something you know authentication can be done as a shared-secret where both the originator and the relying party are both in possession of the shared-secret. an example are keys in symmetric key cryptography. however, it is possible to have something you know authentication where the secret is not shared. For instance if there is a hardware token that is certified to only operate when the correct PIN has been entered the PIN represents something you know authentication w/o having to share the secret with any other party (the relying party assumes that the correct PIN has been entered by a) being confident of the operation of the particular hardware token and b) the hardware token having done something known expected). similarly, biometrics systems are frequently implemented as a form of shared-secret. an entity's biometric template is registered with some relying party and subsequent transactions are authenticated by checking a new biometric template with the biometric template on file. the x9.84 biometric standard devotes a great deal to the security for centrally stored biometric templates treating them as a greater security risk than traditional something you know shared-secrets. the threat is that somebody can obtain files of registered biometric templates and be able to subsequently retransmit them electronicly attempting to impersonate the associated person. The issue in the traditional 'something you know shared-secret is that a PIN compromise can be reported and a new, replacement PIN/password created. However, it is somewhat more difficult to replace a thumb or iris when there has been a reported compromise of something you are shared secret. in any case, for all of the deployed existing authentication systems involving any one of the three factor authentication paradigms, all of the methods are vulnerable to copying to one degree or another. as a result, I would
Re: Do You Need a Digital ID?
Jerrold Leichter wrote: That's fine for *describing* the system, and useful for analyzing its usability or acceptability. But it's not the whole story. 3-factor authentication paradigm obviously doesn't take into account whether the authentication material is treated as a secret or a shared-secret i.e. both biometrics and something you know can be implemented as either secret or shared-secret shared-secret tends to have copies of the authentication material in the possession of the relying party ... while secret tends to be an infrastructure where the relying-party can infer the existance of the secret by other characteristics. it is one of the reasons that the x9.84 biometric standard goes to great deal of description when biometrics are implemented as shared-secrets ... with the biometric templates stored at a central site. 3-factor authentication paradigm obviously also doesn't cover whether the authentication is direct fact-to-face or that the relying party is infering authentication taking place by the existance of other kinds of evidence. for instance, a relying party validating a digital signature with a public key will infer that the other party is in possession of the corresponding private key. the relying party may not have direct knowledge of the other party being in possession of the corresponding private key ... the relying party just infers it from the validation of a digital signature with the public key. which then takes us back to your original response: 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. ref: http://www.garlic.com/~lynn/aadsm19.htm#2 Do you Need a Digital ID? or http://www.mail-archive.com/cryptography%40metzdowd.com/msg03734.html 3-factor authentication paradigm obviously also doesn't cover all the sort of business rules that allow a relying party to infer something to be true ... even when they don't have direct evidence that it is true aka for a public/private key infrastructure where the relying party normally is inferring that the private key owner has in fact attempted to consistantly and reliably maintained the confidentiality and privacy of the private key and therefor its usefullness as part of any 3-factor authentication paradigm. 3-factor authentication paradigm might also help people designing and/or analysing authentication infrastructures. something you know operations may be some what more vulnerable to electronic sniffing, phishing, and/or information harvesting attacks. something you have hopefully are more resistant to electronic sniffing, phishing, and/or information harvesting attacks ... although the transmission of static data in non-face-to-face operations that allow the relying party to infer the possession of the something you have has been shown to be extremely vulnerable to skimming attacks (that enable the manufactor of counterfeit magstripe plastic cards). Obviously sniffing and skimming exploits involve very similar threat model. One application would be to choose a multi-factor authentication implementation where the different factors represent countermeasure to different threats. A multi-factor authentication implementation, where the different factors are vulnerable to the same threats, doesn't provide a great deal of additional security. However, there are obviously a lot of variouscharactistics like * face-to-face or non-face-to-face * direct evidence or inferring based on other evidence * static or non-static data * central store or remote inferrance * treat models * represents what kind of countermeasures * resistance to counterfeiting/impersonation * human factors a difficult human factors has been the issue of something you know shared-secrets. shared-secret pin/passwords have had two kinds of guidelines 1) make it hard to guess (which tends to make it difficult to memorize) 2) different shared-secret for every security domain (where most institutions viewed that they were the only security domain, but in reality many people now are faced with scores of different security domains with scores of extremely difficult to remember shared-secrets). lots of past posts on threats, vulnerabilities, exploits http://www.garlic.com/~lynn/subpubkey.html#fraud and lots of 3-factor authentication posts: http://www.garlic.com/~lynn/subpubkey.html#3factor and various past posts on general subject of designing high-assurance systems http://www.garlic.com/~lynn/subpubkey.html#assurance we have somewhat viewed assurance and high-availability as similar ... where a system needs to be resistant to all kinds of failures ... regardless of whether they were failures due to attacks/exploits or just plain simple
Re: Do You Need a Digital ID?
Anne Lynn Wheeler wrote: 3-factor authentication paradigm obviously also doesn't cover whether the authentication is direct fact-to-face or that the relying party is infering authentication taking place by the existance of other kinds of evidence. for instance, a relying party validating a digital signature with a public key will infer that the other party is in possession of the corresponding private key. the relying party may not have direct i.e. http://www.garlic.com/~lynn/aadsm19.htm#5 Do You Need a Digital ID? one of the possible side-effects of applying 3-factor authentication paradigm ... and observing that 1) the verification of a digital signature is just a method of inferring the possession of a specific private key 2) the possession of a private key obviously (theoritically possible, but i know of not instances of people memorizing private keys) isn't something you know authentication and a private key isn't something you are authentication ... leaving it to be something you have authentication (aka in your possession) 3) private keys in their simplest form are just electronic bits that are relatively easy to copy then in order for a private key to be useful in a something you have authentication, it follows fairly staight-forwardly that significant security procedures and countermeasures are required to prevent such copying (in order to provide some level of assurance that the assumed entity is consistantly and uniquely in possession of the specific private key). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Do You Need a Digital ID?
| if a re-issued a new token/card (to replace a lost/stolen token/card) is | identical to the lost/stolen token/card ... then it is likely that there is no | something you have authentication involved (even tho a token/card is | involved in the process) ... and therefor the infrastructure is just single | factor authentication. | | at the basics, a digital signature is an indirect indication of something you | have authentication aka the existance of a digital signature implies | that the originator accessed and utilized a private key in the generation of | the digital signature. a digital signature by itself says nothing about the | integrity of that something you have authentication ... since the digital | signature doesn't carry any indication of the integrity measures used to | secure and access the associated private key. 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
Re: Do You Need a Digital ID?
R.A. Hettinga wrote: http://www.pcworld.com/resource/printable/article/0,aid,120008,00.asp i've been asked to flush out my merged security taxonomy and glossary http://www.garlic.com/~lynn/index.html#glosnote to highlight the distinction between identity theft and account theft. typically identity theft is that enuf information is obtained to fraudulently be able to open new accounts in the victim's name (among other things) while account theft is that the thief has enuf information to perform fraudulent transactions against an existing account of the victim. account theft tends to be attacks on poor authentication procedures by account institutions and/or use of social engineering or phishing to obtain the victim's account authentication information (which shares a lot in common with straight identity theft). a common exploit is the use of skimming/sniffing of static authentication verification data that enables creating counterfeit tokens/cards that enables fraudulent transactions. given 3-factor authentication: * something you have * something you know * something you are there can be a great deal of confusion whether a token/card represents something you have or not. If a token/card contains valid authentication information and if that token/card is lost/stolen and a new account has to be created then it is likely the token/card represents something you have authentication. however, some infrastructure just utilize a token/card to provide the equilvalent of userid (say an account number which isn't required to be secret) and the actual authentication is in the form of a password/PIN ... i.e. something you know authentication. just because a token/card is involved along with a PIN/password doesn't automatically imply that two-factor authentication is involved. if a re-issued a new token/card (to replace a lost/stolen token/card) is identical to the lost/stolen token/card ... then it is likely that there is no something you have authentication involved (even tho a token/card is involved in the process) ... and therefor the infrastructure is just single factor authentication. at the basics, a digital signature is an indirect indication of something you have authentication aka the existance of a digital signature implies that the originator accessed and utilized a private key in the generation of the digital signature. a digital signature by itself says nothing about the integrity of that something you have authentication ... since the digital signature doesn't carry any indication of the integrity measures used to secure and access the associated private key. there is some temptation to claim that the a lot of the problems with establishment of digital signature technology is that the basic trust building blocks haven't been established. numerous institutions have spent a lot of time focusing on the trust infrastructures associated with certification authority operation and digital certificates which have nothing directly to do with any form of 3 factor authentication. the basic building block is that a financial (or other) institutions have ongoing relationships represented by established accounts and that the entities associated with those accounts have established authentication material. In the case of digital signatures, that would be public keys. To the degree that a relying party institution (financial or other) can trust what is represented by a digital signature is the integrity level of the environment that protects the access and use of the associated private key w/o additional knowledge, the relying party only knows that some entity accessed and utilized a specific private key ... as in a simple, single factor, something you have authentication. A digital signature by itself has no indication of the security and integrity level associated with the private key protection, access and use ... and/or if there is anything more than simple, single factor, something you have authentication. Furthermore, in the great majority of the transactions involving established relationships, there is no need for digital certificates to establish identication information straight-forward authentication tends to be sufficient. misc. past 3-factor authentication posts http://www.garlic.com/~lynn/subpubkey.html#3factor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
