Re: EMV cards as identity cards
possibly unrelated, random news, privacy related URL distributed today about eu commission and the eu data protection act http://iccheshireonline.icnetwork.co.uk/0100news/0200businessfarmingnews/tm_objectid=14663715method=fullsiteid=50061headline=raid-threats-to-city-firms-name_page.html there is also an issue with regard to what it means to sign digital signatures as in authentication can hardware tokens, portals, etc. signing as part of some type of three factor authentication: * something you know * something you have * something you are if a portal produces a digital signature, then a relying party might imfer that there was some form of something you know authentication since the portal might be designed to only perform a digital signature when provided with some form of password. if a hardware token produces a digital signature, then a relying party might possibly infer both something you know and something you have authentication ... assuming that a person holds the hardware token and the hardware token requires a pin or password to operate authentication definitions would, in no way, preclude portals performing digital signatures since it all comes down to is what a relying party may infer when they encounter a digital signature. problems could crop up though if people were to confuse such digital signatures with legal signatures (as opposed to being able to just infer some form of authentication). in the crypto mailing list there was an extended discussion about infrastructure vulnerability when the same key pairs might be used for both authentication events as well as in conjunction with legal signature operations: http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#13 dual-use digital signature vulnerability http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability) semi-related to x9.99 privacy standard being passed (and should show up at the ansi e-store shortly) and the new privacy work item being approved for iso tc68 ... i also recently got an email notice that iso sc6 has approved a new work item for the finread terminal there was a related discussion in the sci.crypt newsgroup regarding some of the requirements for legal signature (with some relationship to feature/function in finread terminal, but happened to wander around and cover a somewhat broader range of characteristics): http://www.garlic.com/~lynn/2004h.html#48 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#50 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#53 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#54 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#55 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#56 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#57 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004h.html#59 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates http://www.garlic.com/~lynn/2004i.html#7 New
Re: EMV cards as identity cards
Exactly what are you addressing here??? 1. That EMV is a bad idea since it (optionally) uses PKI? Could very well be so but EMV is also an off-line thing as the EMV founders incorrectly thought that not many countries could afford broadband! Regardless how right of wrong this assumption may be, those who actually are prepared to convert to accepting chip-cards, probably have broadband as well. That is, a core EMV idea is indeed ill-founded! 2. That ID certificates are redundant? As ID certificates is an FI add-on service to be used by thousands of independent e-gov relying parties using a common national identity scheme, there is no viable alternative to PKI except using a gateway approach which is fairly much the same trust wise. The difference is that some people do not believe that gateways can sign but schemes running in Norway shows that this is piece of cake. At least technically! Anders - Original Message - From: [EMAIL PROTECTED] To: Anders Rundgren [EMAIL PROTECTED] Cc: internet-payments [EMAIL PROTECTED]; Safecode [EMAIL PROTECTED] Sent: Monday, September 20, 2004 22:11 Subject: Re: EMV cards as identity cards on of the issues in the account/identity fraud scenarios is that just knowing the PAN allows fraudulent transactions to be performed. you start to see things like harvesting of merchant transaction files that provide PANs for fraudulent transactions. recent studies have indicated that possible at least 77 percent of such harvesting involves insiders. part of the scenario is the security versus risk discussed in this posting about merchant transaction file harvesting ans security proportional to risk: http://www.garlic.com/~lynn/2001h.html#61 on of the requirements given the x9a10 working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments. the resulting x9.59 standard http://www.garlic.com/~lynn/index.html#x959 uses digital signature to authenticate retail transactions (regardless of kind, including iso 8583 payment transactions) but doesn't mandate the horrendous payload bloat of attaching a redundant and superfulous relying-party-only certificate. x9.59 also specifies that account numbers that are used in x9.59 transactions can not be used in non-authenticated transactions. the result is that it is no longer possible to perform fraudulent payment transactions just by learning an account number. the scenario then is that if it is no longer possible to perform fraudulent transactions by harvesting (x9.59) account numbers from merchant transaction files then it is no longer necessary to maintain such high security infrastructures to prevent crooks from acquiring knowledge of account numbers. we've referred to this being privacy or identity agnostic as opposed to truely anonymous. there is still an account number floating around ... but typically has no other identifying information ... unless somebody gets a court order to acquire the information from your financial institution. misc references to privacy, identity, x9.59, etc http://www.garlic.com/~lynn/subpubkey.html#privacy misc. past postings mentioning privacy/identity agnostic: http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists? http://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance -- Liberty Alliance Project http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda) http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/aadsm18.htm#22 [anonsec] Re: potential new IETF WG on anonymous IPSec at 9/18/2004 11:32 pm anders wrote: Paulo I may have lost the safecode stuff. I have no detailed description of EMV but that is probably easy to get on the net. But I essentially described a multi-application smart card which could hold a credit-card function, a purse and in this case also an identity function using PKI. Since the card does not have a display or keyboard etc. there is no way to select what resource the card reading app is to use. It is therefore assumed that this is hardcoded into applications or that applications offer this selection. However, you cannot do a selection without having parts of the available resources accessible. In the case of the ID-application it is actually your full identity! To allow any merchant to monitor a card holder's identity is in to some extent already possible due to the PAN code, but to *extend* this feature seems to clearly be a step in the wrong direction. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Re: EMV cards as identity cards
i have pointed out in multiple threads and numerous times (a number of times when you have raised this or similar question in the past) that there has been some history of x.509 identity certificates from the early 90s and that the in the mid-90s, many financial institutions around the world retrenched to relying-party-only certificates because of the enormous privacy and liability issues associated with the x.509 identity certificates. I was at a presentation by one of the large german banks at the 1998 21st nissc conference in DC ... on the enormous privacy and liability issues associated with x.509 identity certificates and the requirement for relying-party-only certificates (effectively only containing an account number and public key). There were payment transaction designs and deployments from the mid-90s that also used relying-party-only certificates and had made some reference to the enormous privacy and liability issues associated with x.509 identity certificates. lots of past postings on relying-party-only certificates: http://www.garlic.com/~lynn/subpubkey.html#rpo the issue that i've also pointed out multiple times in the past is that for online transactions involving replying-party-only certificates, that the relying-party-only certificates can typically be shown to be redundant and superfluous ... since the relying-party is the issuing party ... and therefor already has a registered copy of the public key (typically stored in an account record which will be referenced as part of any online transaction). the ancillary issue from some of the payment transactions from the mid-90s using relying-party-only certificates for online iso 8583 payment transactions was that there was enormous payload bloat with various relying-party-only certificates being approximately two orders of magnitude larger in size than typical base iso 8583 transactions. there has also been some sporadic discussions that sometimes there is confusion between identification and authentication and that there are times that identification has been specified when authentication would have been sufficient. at 9/21/2004 12:27 am, anders wrote: Exactly what are you addressing here??? 1. That EMV is a bad idea since it (optionally) uses PKI? Could very well be so but EMV is also an off-line thing as the EMV founders incorrectly thought that not many countries could afford broadband! Regardless how right of wrong this assumption may be, those who actually are prepared to convert to accepting chip-cards, probably have broadband as well. That is, a core EMV idea is indeed ill-founded! 2. That ID certificates are redundant? As ID certificates is an FI add-on service to be used by thousands of independent e-gov relying parties using a common national identity scheme, there is no viable alternative to PKI except using a gateway approach which is fairly much the same trust wise. The difference is that some people do not believe that gateways can sign but schemes running in Norway shows that this is piece of cake. At least technically! Anders -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Re: EMV cards as identity cards
this is similar to the problem with identity x.509 certificates that EU financial institutions identified in the early 90s and resulted in EU (as well as other) financial institutions migrating to relying-party-only certificates in the mid-90s (i.e. effectively containing only an account number and a public key). also in the mid-90s ... the EU has some dictate that retail point-of-sale electronic transactions should be as anonymous as cash. there was then some push to have names taken off of payment cards for point-of-sale transactions leaving only the PAN (not just chip-cards ... but all retail, point-of-sale cards). of course, the relying-party-only certificates with just PAN and public key resulted in mainly online transactions; however it was trivial to show that relying-party-only certificates are redundant and superfluous in online transactions since the relying-party will also be the issuing party and therefor have the public key onfile at the relying/issuing party. a traditional ISO 8583 payment transactions (upgraded to include an appended digital signature) coming into a issuing/relying party ... will have a PAN ... looking up the account number ... and being able to retrieve the public key from the account record. this makes the public key carried in an appended relying-party-only certificate redundant and superfluous since the only other information in the relying-party-only certificate is the PAN ... which is carried in the 8583 transaction itself, this makes the whole relying-party-only certificate also redundant and superfluous. the other issue with redundant and superfluous relying-party-only certificates that various of the payment pilots of the mid-90s that had relying-party-only certificates was that the typical redundant and superfluous relying-party-only certificate could be approximately two oders of magnitude (100 hundred times) larger than the base 8583 payment transaction itself. the result was an enormous payload bloat (of 100 times) to append a redundant and superfluous relying-party-only certificate to a typical 8583 payment transaction similar thread in this mailing list earlier this spring: http://www.garlic.com/~lynn/aadsm17.htm#12 A combined EMV and ID card http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card at 9/17/2004 10:50 pm, anders wrote: In Sweden banks are combining the EMV payment application(s) with a separate identity application using PKI. The reasons are obvious, one card does it all. The drawback is that the card holder's identity including social security numbers etc. is available for any merchant terminal to read if they want, as the public keys (certificates) are not protected by PIN codes etc. If they were protected the card would be incompatible with existing software and become harder to use so that is not an option. I would like to hear if anybody have heard of similar efforts in other parts of the world. Anders Rundgren -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Re: EMV cards as identity cards
on of the issues in the account/identity fraud scenarios is that just knowing the PAN allows fraudulent transactions to be performed. you start to see things like harvesting of merchant transaction files that provide PANs for fraudulent transactions. recent studies have indicated that possible at least 77 percent of such harvesting involves insiders. part of the scenario is the security versus risk discussed in this posting about merchant transaction file harvesting ans security proportional to risk: http://www.garlic.com/~lynn/2001h.html#61 on of the requirements given the x9a10 working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments. the resulting x9.59 standard http://www.garlic.com/~lynn/index.html#x959 uses digital signature to authenticate retail transactions (regardless of kind, including iso 8583 payment transactions) but doesn't mandate the horrendous payload bloat of attaching a redundant and superfulous relying-party-only certificate. x9.59 also specifies that account numbers that are used in x9.59 transactions can not be used in non-authenticated transactions. the result is that it is no longer possible to perform fraudulent payment transactions just by learning an account number. the scenario then is that if it is no longer possible to perform fraudulent transactions by harvesting (x9.59) account numbers from merchant transaction files then it is no longer necessary to maintain such high security infrastructures to prevent crooks from acquiring knowledge of account numbers. we've referred to this being privacy or identity agnostic as opposed to truely anonymous. there is still an account number floating around ... but typically has no other identifying information ... unless somebody gets a court order to acquire the information from your financial institution. misc references to privacy, identity, x9.59, etc http://www.garlic.com/~lynn/subpubkey.html#privacy misc. past postings mentioning privacy/identity agnostic: http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists? http://www.garlic.com/~lynn/aepay7.htm#liberty Network Identity Alliance -- Liberty Alliance Project http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda) http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/aadsm18.htm#22 [anonsec] Re: potential new IETF WG on anonymous IPSec at 9/18/2004 11:32 pm anders wrote: Paulo I may have lost the safecode stuff. I have no detailed description of EMV but that is probably easy to get on the net. But I essentially described a multi-application smart card which could hold a credit-card function, a purse and in this case also an identity function using PKI. Since the card does not have a display or keyboard etc. there is no way to select what resource the card reading app is to use. It is therefore assumed that this is hardcoded into applications or that applications offer this selection. However, you cannot do a selection without having parts of the available resources accessible. In the case of the ID-application it is actually your full identity! To allow any merchant to monitor a card holder's identity is in to some extent already possible due to the PAN code, but to *extend* this feature seems to clearly be a step in the wrong direction. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
