<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_02_11_2129212</id>
	<title>European Credit and Debit Card Security Broken</title>
	<author>timothy</author>
	<datestamp>1265881920000</datestamp>
	<htmltext>Jack Spine writes <i>"With nearly a billion users dependent on smart banking credit and debit cards, banks have refused liability for losses where an idenification number has been provided. But now, the process behind the majority of European credit and debit card transactions is <a href="http://news.zdnet.co.uk/security/0,1000000189,40022674,00.htm">fundamentally broken</a>, according to researchers from Cambridge University. The researchers have demonstrated  a man-in-the-middle attack which fooled a card reader into accepting a number of point-of-sale transactions, even though the cards were not properly authenticated. The researchers <a href="http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf">used off-the-shelf components</a> (PDF), and a laptop running a Python script, to undermine the two-factor authentication process on European credit and debit cards, which is called Chip and PIN."</i></htmltext>
<tokenext>Jack Spine writes " With nearly a billion users dependent on smart banking credit and debit cards , banks have refused liability for losses where an idenification number has been provided .
But now , the process behind the majority of European credit and debit card transactions is fundamentally broken , according to researchers from Cambridge University .
The researchers have demonstrated a man-in-the-middle attack which fooled a card reader into accepting a number of point-of-sale transactions , even though the cards were not properly authenticated .
The researchers used off-the-shelf components ( PDF ) , and a laptop running a Python script , to undermine the two-factor authentication process on European credit and debit cards , which is called Chip and PIN .
"</tokentext>
<sentencetext>Jack Spine writes "With nearly a billion users dependent on smart banking credit and debit cards, banks have refused liability for losses where an idenification number has been provided.
But now, the process behind the majority of European credit and debit card transactions is fundamentally broken, according to researchers from Cambridge University.
The researchers have demonstrated  a man-in-the-middle attack which fooled a card reader into accepting a number of point-of-sale transactions, even though the cards were not properly authenticated.
The researchers used off-the-shelf components (PDF), and a laptop running a Python script, to undermine the two-factor authentication process on European credit and debit cards, which is called Chip and PIN.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107296</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>shentino</author>
	<datestamp>1265892240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>The problem is that the server storing your account information is trusting the terminal.</p><p>If the terminal can get away with trusting the signal it's getting from the card, then it's actually possible for a counterfeit terminal to rob you without even having the card.</p></htmltext>
<tokenext>The problem is that the server storing your account information is trusting the terminal.If the terminal can get away with trusting the signal it 's getting from the card , then it 's actually possible for a counterfeit terminal to rob you without even having the card .</tokentext>
<sentencetext>The problem is that the server storing your account information is trusting the terminal.If the terminal can get away with trusting the signal it's getting from the card, then it's actually possible for a counterfeit terminal to rob you without even having the card.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106582</id>
	<title>Another simple terminal solution</title>
	<author>Anonymous</author>
	<datestamp>1265889420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Is to include the PIN entered in the data encrypted and MAC'd by the card (this is sent to the bank.)</p><p>Then the bank could verify that the correct PIN was entered when authorising the transaction.</p></htmltext>
<tokenext>Is to include the PIN entered in the data encrypted and MAC 'd by the card ( this is sent to the bank .
) Then the bank could verify that the correct PIN was entered when authorising the transaction .</tokentext>
<sentencetext>Is to include the PIN entered in the data encrypted and MAC'd by the card (this is sent to the bank.
)Then the bank could verify that the correct PIN was entered when authorising the transaction.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110588</id>
	<title>PIN is useless</title>
	<author>Anonymous</author>
	<datestamp>1265967780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You can buy stuff online just by giving numbers written on the card...</p></htmltext>
<tokenext>You can buy stuff online just by giving numbers written on the card.. .</tokentext>
<sentencetext>You can buy stuff online just by giving numbers written on the card...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106880</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>Anonymous</author>
	<datestamp>1265890560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The information isn't being pulled off the chip.  That's the point.  You have something that simulates a chip saying the PIN was correct, regardless of what you enter.</p></htmltext>
<tokenext>The information is n't being pulled off the chip .
That 's the point .
You have something that simulates a chip saying the PIN was correct , regardless of what you enter .</tokentext>
<sentencetext>The information isn't being pulled off the chip.
That's the point.
You have something that simulates a chip saying the PIN was correct, regardless of what you enter.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107894</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>Anonymous</author>
	<datestamp>1265895300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The card does not do anything related to a PIN-authenticated transaction before the PIN is sent to the card and verified by the card. The wrong PIN is never sent to the card: The fake terminal side of the MITM handles the card like it's performing "signature authentication" instead of "PIN authentication". In the meantime the fake card side of the MITM goes through the "PIN authentication" protocol with the terminal. The problem is that the terminal cannot detect this mismatch because a) the PIN-OK message is not authenticated <b>and</b> b) neither the "transaction request" sent to the bank by the card nor the "transaction-accepted" message sent back by the bank indicates which authentication method was accepted in a format that the terminal can understand. Changing one or both of these aspects would eliminate the vulnerability. (Captcha: credited)</p></htmltext>
<tokenext>The card does not do anything related to a PIN-authenticated transaction before the PIN is sent to the card and verified by the card .
The wrong PIN is never sent to the card : The fake terminal side of the MITM handles the card like it 's performing " signature authentication " instead of " PIN authentication " .
In the meantime the fake card side of the MITM goes through the " PIN authentication " protocol with the terminal .
The problem is that the terminal can not detect this mismatch because a ) the PIN-OK message is not authenticated and b ) neither the " transaction request " sent to the bank by the card nor the " transaction-accepted " message sent back by the bank indicates which authentication method was accepted in a format that the terminal can understand .
Changing one or both of these aspects would eliminate the vulnerability .
( Captcha : credited )</tokentext>
<sentencetext>The card does not do anything related to a PIN-authenticated transaction before the PIN is sent to the card and verified by the card.
The wrong PIN is never sent to the card: The fake terminal side of the MITM handles the card like it's performing "signature authentication" instead of "PIN authentication".
In the meantime the fake card side of the MITM goes through the "PIN authentication" protocol with the terminal.
The problem is that the terminal cannot detect this mismatch because a) the PIN-OK message is not authenticated and b) neither the "transaction request" sent to the bank by the card nor the "transaction-accepted" message sent back by the bank indicates which authentication method was accepted in a format that the terminal can understand.
Changing one or both of these aspects would eliminate the vulnerability.
(Captcha: credited)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105936</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816</id>
	<title>Do they still need the card?</title>
	<author>Animaether</author>
	<datestamp>1265894880000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I'm just curious as the article summary and article don't mention (I guess the PDF might, but from the article's description, it isn't clear)...</p><p>Do they still need the card?</p><p>The article seems to describe the attack as a man-in-the-middle attack.. i.e. card -&gt; their device -&gt; the card reader/writer.  So the card instigates all the important bits (which back account number, etc.), and then their device sends back an 'OK' to the card reader/writer, happily ignoring the PIN part.</p><p>But does that mean they do still need to have a card?  Or could they easily make their own card with the details of whoever (let's say they grab the bank account # off of some business registry website), and then go ahead and perform transactions with it + their device?</p></htmltext>
<tokenext>I 'm just curious as the article summary and article do n't mention ( I guess the PDF might , but from the article 's description , it is n't clear ) ...Do they still need the card ? The article seems to describe the attack as a man-in-the-middle attack.. i.e. card - &gt; their device - &gt; the card reader/writer .
So the card instigates all the important bits ( which back account number , etc .
) , and then their device sends back an 'OK ' to the card reader/writer , happily ignoring the PIN part.But does that mean they do still need to have a card ?
Or could they easily make their own card with the details of whoever ( let 's say they grab the bank account # off of some business registry website ) , and then go ahead and perform transactions with it + their device ?</tokentext>
<sentencetext>I'm just curious as the article summary and article don't mention (I guess the PDF might, but from the article's description, it isn't clear)...Do they still need the card?The article seems to describe the attack as a man-in-the-middle attack.. i.e. card -&gt; their device -&gt; the card reader/writer.
So the card instigates all the important bits (which back account number, etc.
), and then their device sends back an 'OK' to the card reader/writer, happily ignoring the PIN part.But does that mean they do still need to have a card?
Or could they easily make their own card with the details of whoever (let's say they grab the bank account # off of some business registry website), and then go ahead and perform transactions with it + their device?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31112832</id>
	<title>Surely this is just a poor implementation</title>
	<author>psysjal</author>
	<datestamp>1265989380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A while ago (admittedly 4 years) I worked on the ATM side of an EMV chip and pin implementation. Yes the chip can lie to the terminal and yes the terminal can lie to the bank. But all results of a transaction from the card/chip result in the generation of a small cryptographic token generated using the cards view of how the transaction went. The information included in the generation of this is variable but should at least include things like whether the card thought PIN verification was sucessful or not, the transaction amount and whether the card thought the transaction was succesful or not.

<p>

This is normally printed on the receipt and either sent online to the bank or uploaded later in a batch transfer. If the system has been implemented sensibly it shouldn't be difficult to prove that this has happened. For an online transaction I don't really see how it can happen at all in a well implemented system.</p></htmltext>
<tokenext>A while ago ( admittedly 4 years ) I worked on the ATM side of an EMV chip and pin implementation .
Yes the chip can lie to the terminal and yes the terminal can lie to the bank .
But all results of a transaction from the card/chip result in the generation of a small cryptographic token generated using the cards view of how the transaction went .
The information included in the generation of this is variable but should at least include things like whether the card thought PIN verification was sucessful or not , the transaction amount and whether the card thought the transaction was succesful or not .
This is normally printed on the receipt and either sent online to the bank or uploaded later in a batch transfer .
If the system has been implemented sensibly it should n't be difficult to prove that this has happened .
For an online transaction I do n't really see how it can happen at all in a well implemented system .</tokentext>
<sentencetext>A while ago (admittedly 4 years) I worked on the ATM side of an EMV chip and pin implementation.
Yes the chip can lie to the terminal and yes the terminal can lie to the bank.
But all results of a transaction from the card/chip result in the generation of a small cryptographic token generated using the cards view of how the transaction went.
The information included in the generation of this is variable but should at least include things like whether the card thought PIN verification was sucessful or not, the transaction amount and whether the card thought the transaction was succesful or not.
This is normally printed on the receipt and either sent online to the bank or uploaded later in a batch transfer.
If the system has been implemented sensibly it shouldn't be difficult to prove that this has happened.
For an online transaction I don't really see how it can happen at all in a well implemented system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31115872</id>
	<title>Chip and Pin?..  Fish and Cushion!</title>
	<author>Anonymous</author>
	<datestamp>1266001440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'll take Fish and Cushion over them any day of the week...</p></htmltext>
<tokenext>I 'll take Fish and Cushion over them any day of the week.. .</tokentext>
<sentencetext>I'll take Fish and Cushion over them any day of the week...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107978</id>
	<title>Cashiers cant see the card</title>
	<author>The Outlander</author>
	<datestamp>1265895840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I was under the impression that one big reason for introducing Chip and Pin was to avoid the cashier handling the card. A big source of card fraud was bent cashiers photographing or copying the cards as they swiped them in the machines, using chip and pin means no-one else touches your card therefore negating another level of insecurity.</p></htmltext>
<tokenext>I was under the impression that one big reason for introducing Chip and Pin was to avoid the cashier handling the card .
A big source of card fraud was bent cashiers photographing or copying the cards as they swiped them in the machines , using chip and pin means no-one else touches your card therefore negating another level of insecurity .</tokentext>
<sentencetext>I was under the impression that one big reason for introducing Chip and Pin was to avoid the cashier handling the card.
A big source of card fraud was bent cashiers photographing or copying the cards as they swiped them in the machines, using chip and pin means no-one else touches your card therefore negating another level of insecurity.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110932</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>locofungus</author>
	<datestamp>1265972940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>So, you stick something between the card and the terminal (the laptop) that intercepts the "Wrong PIN was entered" message from the card and forwards a "Correct PIN was entered" message to the terminal instead.</i></p><p>No. That could be detected.</p><p>What this does is that the terminal sends the pin to the card. This is intercepted and a "Authenticated by signature" message sent to the card instead. The OK response to that "Authenticated by signature" is changed into an OK response "Authenticated by PIN" before being sent to the terminal.</p><p>So the terminal sees a complete and correct "Authenticated by PIN" exchange and the card sees a complete and correct "Authenticated by Signature" exchange.</p><p>And, AFAICT, there is absolutely no way, after the fact, to detect that this has been done. There is nothing recorded on the card that would indicate a signature authentication would be done. Even the "incorrect pin" counter is not incremented as no incorrect pin was ever sent to the card.</p><p>Tim.</p></htmltext>
<tokenext>So , you stick something between the card and the terminal ( the laptop ) that intercepts the " Wrong PIN was entered " message from the card and forwards a " Correct PIN was entered " message to the terminal instead.No .
That could be detected.What this does is that the terminal sends the pin to the card .
This is intercepted and a " Authenticated by signature " message sent to the card instead .
The OK response to that " Authenticated by signature " is changed into an OK response " Authenticated by PIN " before being sent to the terminal.So the terminal sees a complete and correct " Authenticated by PIN " exchange and the card sees a complete and correct " Authenticated by Signature " exchange.And , AFAICT , there is absolutely no way , after the fact , to detect that this has been done .
There is nothing recorded on the card that would indicate a signature authentication would be done .
Even the " incorrect pin " counter is not incremented as no incorrect pin was ever sent to the card.Tim .</tokentext>
<sentencetext>So, you stick something between the card and the terminal (the laptop) that intercepts the "Wrong PIN was entered" message from the card and forwards a "Correct PIN was entered" message to the terminal instead.No.
That could be detected.What this does is that the terminal sends the pin to the card.
This is intercepted and a "Authenticated by signature" message sent to the card instead.
The OK response to that "Authenticated by signature" is changed into an OK response "Authenticated by PIN" before being sent to the terminal.So the terminal sees a complete and correct "Authenticated by PIN" exchange and the card sees a complete and correct "Authenticated by Signature" exchange.And, AFAICT, there is absolutely no way, after the fact, to detect that this has been done.
There is nothing recorded on the card that would indicate a signature authentication would be done.
Even the "incorrect pin" counter is not incremented as no incorrect pin was ever sent to the card.Tim.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105936</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>Anonymous</author>
	<datestamp>1265886540000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>Replying to myself, if you read the PDF it details the process on page 3; the card actually does almost all of the transaction work before the PIN is entered, all the PIN enables is the "Is this transaction allowed? Yes, it's allowed. OK" part of the process.</p></htmltext>
<tokenext>Replying to myself , if you read the PDF it details the process on page 3 ; the card actually does almost all of the transaction work before the PIN is entered , all the PIN enables is the " Is this transaction allowed ?
Yes , it 's allowed .
OK " part of the process .</tokentext>
<sentencetext>Replying to myself, if you read the PDF it details the process on page 3; the card actually does almost all of the transaction work before the PIN is entered, all the PIN enables is the "Is this transaction allowed?
Yes, it's allowed.
OK" part of the process.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106966</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>Anonymous</author>
	<datestamp>1265890980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Seems like the problem with this system is that the problem is that the PIN is stored on the chip... and that's just as stupid as writing it on the card! The attacks are simple... either a card that always agrees the PIN given is correct, or a terminal that tries to authenticate all 10000 PINS and then learns the right one.</p></div><p>A fake card fails because the cards also contain a secret key that cannot be read. The key is used to sign transactions. Therefore a fake card that agrees the PIN is correct won't have a valid key and the transaction won't be correctly signed so will fail.</p><p>Secondly, the card tracks how many incorrect PINs have been tried and stops working after 3 tries. So scheme 2 fails.</p><p>Perhaps you might want to read the article.</p></div>
	</htmltext>
<tokenext>Seems like the problem with this system is that the problem is that the PIN is stored on the chip... and that 's just as stupid as writing it on the card !
The attacks are simple... either a card that always agrees the PIN given is correct , or a terminal that tries to authenticate all 10000 PINS and then learns the right one.A fake card fails because the cards also contain a secret key that can not be read .
The key is used to sign transactions .
Therefore a fake card that agrees the PIN is correct wo n't have a valid key and the transaction wo n't be correctly signed so will fail.Secondly , the card tracks how many incorrect PINs have been tried and stops working after 3 tries .
So scheme 2 fails.Perhaps you might want to read the article .</tokentext>
<sentencetext>Seems like the problem with this system is that the problem is that the PIN is stored on the chip... and that's just as stupid as writing it on the card!
The attacks are simple... either a card that always agrees the PIN given is correct, or a terminal that tries to authenticate all 10000 PINS and then learns the right one.A fake card fails because the cards also contain a secret key that cannot be read.
The key is used to sign transactions.
Therefore a fake card that agrees the PIN is correct won't have a valid key and the transaction won't be correctly signed so will fail.Secondly, the card tracks how many incorrect PINs have been tried and stops working after 3 tries.
So scheme 2 fails.Perhaps you might want to read the article.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>Anonymous</author>
	<datestamp>1265886060000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>RTFA. The problem isn't that the PIN is "stored on the card", it's that the card doesn't send any unique data to the terminal when the correct PIN is entered, it just sends a "Correct PIN was entered" message instead.</p><p>So, you stick something between the card and the terminal (the laptop) that intercepts the "Wrong PIN was entered" message from the card and forwards a "Correct PIN was entered" message to the terminal instead.</p><p>TBH I'm rather surprised that any information is allowed to be pulled off the chip without the PIN authenticating the user first; if you had to provide the correct PIN before the card would provide any information it would make it much harder to carry out the fraudulent transaction.</p></htmltext>
<tokenext>RTFA .
The problem is n't that the PIN is " stored on the card " , it 's that the card does n't send any unique data to the terminal when the correct PIN is entered , it just sends a " Correct PIN was entered " message instead.So , you stick something between the card and the terminal ( the laptop ) that intercepts the " Wrong PIN was entered " message from the card and forwards a " Correct PIN was entered " message to the terminal instead.TBH I 'm rather surprised that any information is allowed to be pulled off the chip without the PIN authenticating the user first ; if you had to provide the correct PIN before the card would provide any information it would make it much harder to carry out the fraudulent transaction .</tokentext>
<sentencetext>RTFA.
The problem isn't that the PIN is "stored on the card", it's that the card doesn't send any unique data to the terminal when the correct PIN is entered, it just sends a "Correct PIN was entered" message instead.So, you stick something between the card and the terminal (the laptop) that intercepts the "Wrong PIN was entered" message from the card and forwards a "Correct PIN was entered" message to the terminal instead.TBH I'm rather surprised that any information is allowed to be pulled off the chip without the PIN authenticating the user first; if you had to provide the correct PIN before the card would provide any information it would make it much harder to carry out the fraudulent transaction.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110964</id>
	<title>in practise</title>
	<author>Anonymous</author>
	<datestamp>1265973240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>so just had a quick look and this is all done with a fake card wired to a computer... i.e. not very practical in reality.</p><p>it's very common for the merchant to take back the terminal once you've entered the pin, print of the recipts then hand your card back to with your recipt, at this point they may notice the wires dangling from your sleve.</p><p>the only reliable places where this wouldn't happen are large retail stores and newsagents that have installed the static terminals.</p><p>so as long as you stick to:</p><p>1) i havd you my card<br>2) you keep it in my sight and also check for "omg wires!"<br>3) i enter my pin<br>4) you complete the transaction and return my card</p><p>everything should be sweet.</p><p>just saying...</p></htmltext>
<tokenext>so just had a quick look and this is all done with a fake card wired to a computer... i.e. not very practical in reality.it 's very common for the merchant to take back the terminal once you 've entered the pin , print of the recipts then hand your card back to with your recipt , at this point they may notice the wires dangling from your sleve.the only reliable places where this would n't happen are large retail stores and newsagents that have installed the static terminals.so as long as you stick to : 1 ) i havd you my card2 ) you keep it in my sight and also check for " omg wires !
" 3 ) i enter my pin4 ) you complete the transaction and return my cardeverything should be sweet.just saying.. .</tokentext>
<sentencetext>so just had a quick look and this is all done with a fake card wired to a computer... i.e. not very practical in reality.it's very common for the merchant to take back the terminal once you've entered the pin, print of the recipts then hand your card back to with your recipt, at this point they may notice the wires dangling from your sleve.the only reliable places where this wouldn't happen are large retail stores and newsagents that have installed the static terminals.so as long as you stick to:1) i havd you my card2) you keep it in my sight and also check for "omg wires!
"3) i enter my pin4) you complete the transaction and return my cardeverything should be sweet.just saying...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31109312</id>
	<title>Colopure Cleanse</title>
	<author>tancyer</author>
	<datestamp>1265907120000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext>well for one thing I don't think anyone would give you a bill consolidation loan if your on social security because if you were to default on the loan your social security earnings .
<a href="http://www.articlesbase.com/health-articles/colopure-cleanse-reviews-does-colopure-cleanse-really-work--1847973.html" title="articlesbase.com" rel="nofollow">Colopure Cleanse</a> [articlesbase.com]</htmltext>
<tokenext>well for one thing I do n't think anyone would give you a bill consolidation loan if your on social security because if you were to default on the loan your social security earnings .
Colopure Cleanse [ articlesbase.com ]</tokentext>
<sentencetext>well for one thing I don't think anyone would give you a bill consolidation loan if your on social security because if you were to default on the loan your social security earnings .
Colopure Cleanse [articlesbase.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106702</id>
	<title>Re:We Already Know This</title>
	<author>verbalcontract</author>
	<datestamp>1265889900000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>This doesn't seem like the average attack we see in the United States, where a false card reader and camera copy a victim's credit card stripe and PIN respectively. I'm by no means an expert in Chip and PIN, but Wikipedia indicates that the smart card chip is much more difficult to copy than the US's magnetic stripes:</p><p>

<a href="http://en.wikipedia.org/wiki/Chip\_and\_pin" title="wikipedia.org">http://en.wikipedia.org/wiki/Chip\_and\_pin</a> [wikipedia.org]</p><p>From the text:</p><p> <em>"Once the card has been verified as authentic, the customer enters a 4-digit PIN..."</em> </p><p>It doesn't say whether all the credit card information is passed during this handshake, but if it's not, it wouldn't be possible to copy the card just by reading it.</p></htmltext>
<tokenext>This does n't seem like the average attack we see in the United States , where a false card reader and camera copy a victim 's credit card stripe and PIN respectively .
I 'm by no means an expert in Chip and PIN , but Wikipedia indicates that the smart card chip is much more difficult to copy than the US 's magnetic stripes : http : //en.wikipedia.org/wiki/Chip \ _and \ _pin [ wikipedia.org ] From the text : " Once the card has been verified as authentic , the customer enters a 4-digit PIN... " It does n't say whether all the credit card information is passed during this handshake , but if it 's not , it would n't be possible to copy the card just by reading it .</tokentext>
<sentencetext>This doesn't seem like the average attack we see in the United States, where a false card reader and camera copy a victim's credit card stripe and PIN respectively.
I'm by no means an expert in Chip and PIN, but Wikipedia indicates that the smart card chip is much more difficult to copy than the US's magnetic stripes:

http://en.wikipedia.org/wiki/Chip\_and\_pin [wikipedia.org]From the text: "Once the card has been verified as authentic, the customer enters a 4-digit PIN..." It doesn't say whether all the credit card information is passed during this handshake, but if it's not, it wouldn't be possible to copy the card just by reading it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108304</id>
	<title>Re:Do they still need the card?</title>
	<author>Anonymous</author>
	<datestamp>1265898000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yes, they still need the card.<br> <br>

The keys that are on the smartcard (there are a number of keys) remain on the card, and can't be extracted, whether you have the PIN or not (meaning even the cardholder can't extract the keys. If the keys, during generation, as marked as not exportable, even the bank can't extract them, even with the master key). In order to perform an operation, you query the card with a bunch of information, and usually the PIN (specific operations like getting the ATR don't require an open session though.). Considering they still need the keys on the card to sign the transaction the card still needs to be physically present (at least, even though I work in the field, is my understanding of the attack).<br> <br>

Oh, and yes: we're scrambling for answers at this point. Obviously we're downplaying the whole thing, but I'm pretty sure our sales guys are going to get a huge number of calls in the next few days.</htmltext>
<tokenext>Yes , they still need the card .
The keys that are on the smartcard ( there are a number of keys ) remain on the card , and ca n't be extracted , whether you have the PIN or not ( meaning even the cardholder ca n't extract the keys .
If the keys , during generation , as marked as not exportable , even the bank ca n't extract them , even with the master key ) .
In order to perform an operation , you query the card with a bunch of information , and usually the PIN ( specific operations like getting the ATR do n't require an open session though. ) .
Considering they still need the keys on the card to sign the transaction the card still needs to be physically present ( at least , even though I work in the field , is my understanding of the attack ) .
Oh , and yes : we 're scrambling for answers at this point .
Obviously we 're downplaying the whole thing , but I 'm pretty sure our sales guys are going to get a huge number of calls in the next few days .</tokentext>
<sentencetext>Yes, they still need the card.
The keys that are on the smartcard (there are a number of keys) remain on the card, and can't be extracted, whether you have the PIN or not (meaning even the cardholder can't extract the keys.
If the keys, during generation, as marked as not exportable, even the bank can't extract them, even with the master key).
In order to perform an operation, you query the card with a bunch of information, and usually the PIN (specific operations like getting the ATR don't require an open session though.).
Considering they still need the keys on the card to sign the transaction the card still needs to be physically present (at least, even though I work in the field, is my understanding of the attack).
Oh, and yes: we're scrambling for answers at this point.
Obviously we're downplaying the whole thing, but I'm pretty sure our sales guys are going to get a huge number of calls in the next few days.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108728</id>
	<title>Credits cards have always had this problem</title>
	<author>tg123</author>
	<datestamp>1265901780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Credits cards have always had this problem.</p><p>The reason this works with credit cards is little or no checking is done at the place of purchase.  It is expected that the customer will check there monthly statement and notify the bank / credit company of any issues.</p></htmltext>
<tokenext>Credits cards have always had this problem.The reason this works with credit cards is little or no checking is done at the place of purchase .
It is expected that the customer will check there monthly statement and notify the bank / credit company of any issues .</tokentext>
<sentencetext>Credits cards have always had this problem.The reason this works with credit cards is little or no checking is done at the place of purchase.
It is expected that the customer will check there monthly statement and notify the bank / credit company of any issues.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172</id>
	<title>We Already Know This</title>
	<author>Anonymous</author>
	<datestamp>1265887560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>This has been known for years. The machines and man-in-the-middle attacks are obvious, simply because you cannot verify the authenticity of any machine that you stick your card into and type your PIN. You have no clue that any one of them is doing what you think it should be doing. ATM machines are bad enough, but at least there is some sort of trust over the fact they are at a fixed point and there is some form of physical security around them. With chip and pin machines all you have is utterly blind faith that you have no choice but to accept, and then you get blamed for being insecure by the banks when the inevitable happens.<br> <br>

What have we heard about this in the mainstream press and media? Nothing. People, and those with a vested interest, obviously just want to deny that it can happen.</htmltext>
<tokenext>This has been known for years .
The machines and man-in-the-middle attacks are obvious , simply because you can not verify the authenticity of any machine that you stick your card into and type your PIN .
You have no clue that any one of them is doing what you think it should be doing .
ATM machines are bad enough , but at least there is some sort of trust over the fact they are at a fixed point and there is some form of physical security around them .
With chip and pin machines all you have is utterly blind faith that you have no choice but to accept , and then you get blamed for being insecure by the banks when the inevitable happens .
What have we heard about this in the mainstream press and media ?
Nothing. People , and those with a vested interest , obviously just want to deny that it can happen .</tokentext>
<sentencetext>This has been known for years.
The machines and man-in-the-middle attacks are obvious, simply because you cannot verify the authenticity of any machine that you stick your card into and type your PIN.
You have no clue that any one of them is doing what you think it should be doing.
ATM machines are bad enough, but at least there is some sort of trust over the fact they are at a fixed point and there is some form of physical security around them.
With chip and pin machines all you have is utterly blind faith that you have no choice but to accept, and then you get blamed for being insecure by the banks when the inevitable happens.
What have we heard about this in the mainstream press and media?
Nothing. People, and those with a vested interest, obviously just want to deny that it can happen.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31109026</id>
	<title>Finances the Valentines way.</title>
	<author>Ostracus</author>
	<datestamp>1265904360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"The researchers used off-the-shelf components (PDF), and a laptop running a Python script, to undermine the two-factor authentication process on European credit and debit cards, which is called Chip and PIN."</p><p>Oh some Americans already have a similar system. It's called Ball and Chain. Courtesy of this system there's little fraud because all transactions are wife approved.</p></htmltext>
<tokenext>" The researchers used off-the-shelf components ( PDF ) , and a laptop running a Python script , to undermine the two-factor authentication process on European credit and debit cards , which is called Chip and PIN .
" Oh some Americans already have a similar system .
It 's called Ball and Chain .
Courtesy of this system there 's little fraud because all transactions are wife approved .</tokentext>
<sentencetext>"The researchers used off-the-shelf components (PDF), and a laptop running a Python script, to undermine the two-factor authentication process on European credit and debit cards, which is called Chip and PIN.
"Oh some Americans already have a similar system.
It's called Ball and Chain.
Courtesy of this system there's little fraud because all transactions are wife approved.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106622</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>mlts</author>
	<datestamp>1265889540000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>How about storing the PIN similar to how TrueCrypt validates a hash?  One value is a random salt, which is decrypted by the PIN the user types in, and that is compared to the second value.  Add in a number of rounds to help deter brute forcing.</p><p>However, what really is needed is for the smart card to either delay access with an exponentially increasing time, or after 3-5 bad guesses, the card blocks access to the PIN, until released by the provider, similar to how GSM SIM cards work.</p><p>Best of all worlds is if the European banks just went with a true smart card system in the first place, where offline transactions were signed/decrypted on chip by the card, and the card readers presented the transaction to be signed or declined.</p></htmltext>
<tokenext>How about storing the PIN similar to how TrueCrypt validates a hash ?
One value is a random salt , which is decrypted by the PIN the user types in , and that is compared to the second value .
Add in a number of rounds to help deter brute forcing.However , what really is needed is for the smart card to either delay access with an exponentially increasing time , or after 3-5 bad guesses , the card blocks access to the PIN , until released by the provider , similar to how GSM SIM cards work.Best of all worlds is if the European banks just went with a true smart card system in the first place , where offline transactions were signed/decrypted on chip by the card , and the card readers presented the transaction to be signed or declined .</tokentext>
<sentencetext>How about storing the PIN similar to how TrueCrypt validates a hash?
One value is a random salt, which is decrypted by the PIN the user types in, and that is compared to the second value.
Add in a number of rounds to help deter brute forcing.However, what really is needed is for the smart card to either delay access with an exponentially increasing time, or after 3-5 bad guesses, the card blocks access to the PIN, until released by the provider, similar to how GSM SIM cards work.Best of all worlds is if the European banks just went with a true smart card system in the first place, where offline transactions were signed/decrypted on chip by the card, and the card readers presented the transaction to be signed or declined.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31115020</id>
	<title>Re:Do they still need the card?</title>
	<author>Anonymous</author>
	<datestamp>1265998080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>you need the card to generate the crytogram, they cant simulate this.</p><p>P.S. this is not an Hack, this is weakeness is documented in EMV, it's suposed to exist, it's a question of risk vs cost, it's up to the card issuer adopt what they think they need. If you want to avoid the attack Issuers must use CDA.</p></htmltext>
<tokenext>you need the card to generate the crytogram , they cant simulate this.P.S .
this is not an Hack , this is weakeness is documented in EMV , it 's suposed to exist , it 's a question of risk vs cost , it 's up to the card issuer adopt what they think they need .
If you want to avoid the attack Issuers must use CDA .</tokentext>
<sentencetext>you need the card to generate the crytogram, they cant simulate this.P.S.
this is not an Hack, this is weakeness is documented in EMV, it's suposed to exist, it's a question of risk vs cost, it's up to the card issuer adopt what they think they need.
If you want to avoid the attack Issuers must use CDA.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31112422</id>
	<title>Re:Do they still need the card?</title>
	<author>Anonymous</author>
	<datestamp>1265987580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yes you do. You still need the RSA private key and 3DES key to authenticate the card to the reader and the transaction to the bank. The only thing you do is fake a "yes the entered PIN is correct" as the transaction stays between the card and the reader and is not validated (by say, signing the yes with the RSA key or performing a MAC on it).</p><p>This is just dumb and was either overlooked, or willingly accepted to support some legacy operation mode or the like.</p><p>So the attack allows the bad guy to steal a card and use it to perform PIN verified payments (at stores).</p></htmltext>
<tokenext>Yes you do .
You still need the RSA private key and 3DES key to authenticate the card to the reader and the transaction to the bank .
The only thing you do is fake a " yes the entered PIN is correct " as the transaction stays between the card and the reader and is not validated ( by say , signing the yes with the RSA key or performing a MAC on it ) .This is just dumb and was either overlooked , or willingly accepted to support some legacy operation mode or the like.So the attack allows the bad guy to steal a card and use it to perform PIN verified payments ( at stores ) .</tokentext>
<sentencetext>Yes you do.
You still need the RSA private key and 3DES key to authenticate the card to the reader and the transaction to the bank.
The only thing you do is fake a "yes the entered PIN is correct" as the transaction stays between the card and the reader and is not validated (by say, signing the yes with the RSA key or performing a MAC on it).This is just dumb and was either overlooked, or willingly accepted to support some legacy operation mode or the like.So the attack allows the bad guy to steal a card and use it to perform PIN verified payments (at stores).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108402</id>
	<title>Neat attack...</title>
	<author>leromarinvit</author>
	<datestamp>1265898840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Nice attack (and it seems pretty simple, actually). I wonder what dimwit decided it was a good idea not to authenticate the card's "PIN OK" success message in any way...</htmltext>
<tokenext>Nice attack ( and it seems pretty simple , actually ) .
I wonder what dimwit decided it was a good idea not to authenticate the card 's " PIN OK " success message in any way.. .</tokentext>
<sentencetext>Nice attack (and it seems pretty simple, actually).
I wonder what dimwit decided it was a good idea not to authenticate the card's "PIN OK" success message in any way...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626</id>
	<title>Chip and Chip security... wait a second!</title>
	<author>Anonymous</author>
	<datestamp>1265885520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Seems like the problem with this system is that the problem is that the PIN is stored on the chip... and that's just as stupid as writing it on the card! The attacks are simple... either a card that always agrees the PIN given is correct, or a terminal that tries to authenticate all 10000 PINS and then learns the right one.</p><p>Payment processors have for years been wanting to have an offline secure system, but it just doesn't work. With cheap enough data systems available everywhere, it's not hard for every Wal-Mart most rural gas stations to see a satellite. Get a $20/mo. dial-up account if you have to... there's no reason for anything that does money to be off the grid.</p><p>If the PIN is stored online like traditional ATM cards, then there would be a quick way to be sure there's honest checking of the pin and alarms if somebody fails too many times. The American "contact" systems are actually reasons to not require a signature or a PIN... but those are also designed for small-dollar transactions and keeping the fast food line moving. Sure, they're open to cloning risk, but they're willing to take that downside because there's enough upside to using the system.</p></htmltext>
<tokenext>Seems like the problem with this system is that the problem is that the PIN is stored on the chip... and that 's just as stupid as writing it on the card !
The attacks are simple... either a card that always agrees the PIN given is correct , or a terminal that tries to authenticate all 10000 PINS and then learns the right one.Payment processors have for years been wanting to have an offline secure system , but it just does n't work .
With cheap enough data systems available everywhere , it 's not hard for every Wal-Mart most rural gas stations to see a satellite .
Get a $ 20/mo .
dial-up account if you have to... there 's no reason for anything that does money to be off the grid.If the PIN is stored online like traditional ATM cards , then there would be a quick way to be sure there 's honest checking of the pin and alarms if somebody fails too many times .
The American " contact " systems are actually reasons to not require a signature or a PIN... but those are also designed for small-dollar transactions and keeping the fast food line moving .
Sure , they 're open to cloning risk , but they 're willing to take that downside because there 's enough upside to using the system .</tokentext>
<sentencetext>Seems like the problem with this system is that the problem is that the PIN is stored on the chip... and that's just as stupid as writing it on the card!
The attacks are simple... either a card that always agrees the PIN given is correct, or a terminal that tries to authenticate all 10000 PINS and then learns the right one.Payment processors have for years been wanting to have an offline secure system, but it just doesn't work.
With cheap enough data systems available everywhere, it's not hard for every Wal-Mart most rural gas stations to see a satellite.
Get a $20/mo.
dial-up account if you have to... there's no reason for anything that does money to be off the grid.If the PIN is stored online like traditional ATM cards, then there would be a quick way to be sure there's honest checking of the pin and alarms if somebody fails too many times.
The American "contact" systems are actually reasons to not require a signature or a PIN... but those are also designed for small-dollar transactions and keeping the fast food line moving.
Sure, they're open to cloning risk, but they're willing to take that downside because there's enough upside to using the system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31115010</id>
	<title>Re:We Already Know This</title>
	<author>Anonymous</author>
	<datestamp>1265998020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There's no need for any wires or a backpack.  There's nothing to stop someone from writing a card application that performs this MIM attack.  The artwork on the card maybe wouldn't look like the original card, but with chip &amp; pin, the merchant doesn't look at the card at all, so no problem there.  AFAIK, the banks are working on installing certificates on the cards, and that would make this MIM attack a lot harder.</p></htmltext>
<tokenext>There 's no need for any wires or a backpack .
There 's nothing to stop someone from writing a card application that performs this MIM attack .
The artwork on the card maybe would n't look like the original card , but with chip &amp; pin , the merchant does n't look at the card at all , so no problem there .
AFAIK , the banks are working on installing certificates on the cards , and that would make this MIM attack a lot harder .</tokentext>
<sentencetext>There's no need for any wires or a backpack.
There's nothing to stop someone from writing a card application that performs this MIM attack.
The artwork on the card maybe wouldn't look like the original card, but with chip &amp; pin, the merchant doesn't look at the card at all, so no problem there.
AFAIK, the banks are working on installing certificates on the cards, and that would make this MIM attack a lot harder.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107722</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107070</id>
	<title>so, we'll have to hand over our card for the cashi</title>
	<author>HonTakuan</author>
	<datestamp>1265891340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"The FPGA board was connected to a Maxim 1740 interface chip, which was linked via thin wires to a fake card, used for insertion in the terminal."

so, we'll have to hand over our card for the cashier to swipe.</htmltext>
<tokenext>" The FPGA board was connected to a Maxim 1740 interface chip , which was linked via thin wires to a fake card , used for insertion in the terminal .
" so , we 'll have to hand over our card for the cashier to swipe .</tokentext>
<sentencetext>"The FPGA board was connected to a Maxim 1740 interface chip, which was linked via thin wires to a fake card, used for insertion in the terminal.
"

so, we'll have to hand over our card for the cashier to swipe.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31117290</id>
	<title>Re:Do they still need the card?</title>
	<author>Anonymous</author>
	<datestamp>1266007740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The card is required. However, these have been proven clonable before.</p></htmltext>
<tokenext>The card is required .
However , these have been proven clonable before .</tokentext>
<sentencetext>The card is required.
However, these have been proven clonable before.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107228</id>
	<title>Yup, in 2000 when banking data was given to USA.</title>
	<author>Anonymous</author>
	<datestamp>1265892000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Security was broken when EU agreed to give all European banking data to USA<nobr> <wbr></nobr>;-)</p><p>Thankfully this was discovered in 2006 by Press, and EU governement decided to stop this.</p></htmltext>
<tokenext>Security was broken when EU agreed to give all European banking data to USA ; - ) Thankfully this was discovered in 2006 by Press , and EU governement decided to stop this .</tokentext>
<sentencetext>Security was broken when EU agreed to give all European banking data to USA ;-)Thankfully this was discovered in 2006 by Press, and EU governement decided to stop this.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106878</id>
	<title>chip and pin fail</title>
	<author>Carus</author>
	<datestamp>1265890560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><a href="http://www.youtube.com/watch?v=U1QAnb-wnTs" title="youtube.com" rel="nofollow">http://www.youtube.com/watch?v=U1QAnb-wnTs</a> [youtube.com]


ohhhhhhhhhhhhhhh CHIP AND PIN FAIL</htmltext>
<tokenext>http : //www.youtube.com/watch ? v = U1QAnb-wnTs [ youtube.com ] ohhhhhhhhhhhhhhh CHIP AND PIN FAIL</tokentext>
<sentencetext>http://www.youtube.com/watch?v=U1QAnb-wnTs [youtube.com]


ohhhhhhhhhhhhhhh CHIP AND PIN FAIL</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110854</id>
	<title>Boring... nothing new</title>
	<author>agesilaos</author>
	<datestamp>1265971560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's nothing new that SDA EMV cards are vulnerable on this kind of attack. I tell you even more, it's quite easy to copy SDA card.
DDA cards have no such security issues.
If they think they receive PhD thanks to this paper they're wrong.</htmltext>
<tokenext>It 's nothing new that SDA EMV cards are vulnerable on this kind of attack .
I tell you even more , it 's quite easy to copy SDA card .
DDA cards have no such security issues .
If they think they receive PhD thanks to this paper they 're wrong .</tokentext>
<sentencetext>It's nothing new that SDA EMV cards are vulnerable on this kind of attack.
I tell you even more, it's quite easy to copy SDA card.
DDA cards have no such security issues.
If they think they receive PhD thanks to this paper they're wrong.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108670</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>tg123</author>
	<datestamp>1265901120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>RTFA. The problem isn't that the PIN is "stored on the card", it's that the card doesn't send any unique data to the terminal when the correct PIN is entered, <b> <i>it just sends a "Correct PIN was entered"</i> </b> message instead.</p><p>So, you stick something between the card and the terminal (the laptop) that intercepts the "Wrong PIN was entered" message from the card and forwards a "Correct PIN was entered" message to the terminal instead..............</p></div><p>Please mod this up this is the point the article is  trying to make.</p><p>All that needs to happen is the message Pin Verified  or a similar message is sent to the EFTPOS  terminal  and the transaction goes through.</p></div>
	</htmltext>
<tokenext>RTFA .
The problem is n't that the PIN is " stored on the card " , it 's that the card does n't send any unique data to the terminal when the correct PIN is entered , it just sends a " Correct PIN was entered " message instead.So , you stick something between the card and the terminal ( the laptop ) that intercepts the " Wrong PIN was entered " message from the card and forwards a " Correct PIN was entered " message to the terminal instead..............Please mod this up this is the point the article is trying to make.All that needs to happen is the message Pin Verified or a similar message is sent to the EFTPOS terminal and the transaction goes through .</tokentext>
<sentencetext>RTFA.
The problem isn't that the PIN is "stored on the card", it's that the card doesn't send any unique data to the terminal when the correct PIN is entered,  it just sends a "Correct PIN was entered"  message instead.So, you stick something between the card and the terminal (the laptop) that intercepts the "Wrong PIN was entered" message from the card and forwards a "Correct PIN was entered" message to the terminal instead..............Please mod this up this is the point the article is  trying to make.All that needs to happen is the message Pin Verified  or a similar message is sent to the EFTPOS  terminal  and the transaction goes through.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107316</id>
	<title>Re:We Already Know This</title>
	<author>T Murphy</author>
	<datestamp>1265892360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I see the importance of this not to be what kind of attack they used (other than being relatively simple), but the fact that they are proving these cards aren't as secure as they're claimed to be. It's the difference between knowing Capone did it and finally getting evidence that will stick.</htmltext>
<tokenext>I see the importance of this not to be what kind of attack they used ( other than being relatively simple ) , but the fact that they are proving these cards are n't as secure as they 're claimed to be .
It 's the difference between knowing Capone did it and finally getting evidence that will stick .</tokentext>
<sentencetext>I see the importance of this not to be what kind of attack they used (other than being relatively simple), but the fact that they are proving these cards aren't as secure as they're claimed to be.
It's the difference between knowing Capone did it and finally getting evidence that will stick.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108264</id>
	<title>Slightly wrong</title>
	<author>Anonymous</author>
	<datestamp>1265897700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>The article states that the banks dont accept liability for a transaction performed with PIN. This is true however the liability isn't pushed to the consumer, it is accepted by the card issuer instead (i.e. mastercard, visa etc.).</p><p>I also disagree with their assertion that chip and pin is fundamentally broken. EMV requires the card to generate a cryptogram at the end of the transaction. The card can simply refuse to generate this data if it hasn't received the correct PIN. I am a little suprised that the cards they tried don't do this already.</p><p>Some people here have suggested that the PIN be authenticated online. The EMV standard actually supports online authentication of PIN, its just that some banks choose to issue cards that use a PIN that is verified by the card instead because they don't have the systems in place to support online verification. Many banks</p><p>For all the people saying that the designers of the system dont know what they are doing i suggest they read the specifications (freely available on the emvco website). They are actually quite good and do support pretty much all of the improvements people here have suggested (and more). The problem is they need to be practical as well, something that most comments here don't consider. There is no point designing a foolproof system that no-one can use.</p><p>This hole can be removed and it most certainly will be if criminals start to exploit it.</p></htmltext>
<tokenext>The article states that the banks dont accept liability for a transaction performed with PIN .
This is true however the liability is n't pushed to the consumer , it is accepted by the card issuer instead ( i.e .
mastercard , visa etc .
) .I also disagree with their assertion that chip and pin is fundamentally broken .
EMV requires the card to generate a cryptogram at the end of the transaction .
The card can simply refuse to generate this data if it has n't received the correct PIN .
I am a little suprised that the cards they tried do n't do this already.Some people here have suggested that the PIN be authenticated online .
The EMV standard actually supports online authentication of PIN , its just that some banks choose to issue cards that use a PIN that is verified by the card instead because they do n't have the systems in place to support online verification .
Many banksFor all the people saying that the designers of the system dont know what they are doing i suggest they read the specifications ( freely available on the emvco website ) .
They are actually quite good and do support pretty much all of the improvements people here have suggested ( and more ) .
The problem is they need to be practical as well , something that most comments here do n't consider .
There is no point designing a foolproof system that no-one can use.This hole can be removed and it most certainly will be if criminals start to exploit it .</tokentext>
<sentencetext>The article states that the banks dont accept liability for a transaction performed with PIN.
This is true however the liability isn't pushed to the consumer, it is accepted by the card issuer instead (i.e.
mastercard, visa etc.
).I also disagree with their assertion that chip and pin is fundamentally broken.
EMV requires the card to generate a cryptogram at the end of the transaction.
The card can simply refuse to generate this data if it hasn't received the correct PIN.
I am a little suprised that the cards they tried don't do this already.Some people here have suggested that the PIN be authenticated online.
The EMV standard actually supports online authentication of PIN, its just that some banks choose to issue cards that use a PIN that is verified by the card instead because they don't have the systems in place to support online verification.
Many banksFor all the people saying that the designers of the system dont know what they are doing i suggest they read the specifications (freely available on the emvco website).
They are actually quite good and do support pretty much all of the improvements people here have suggested (and more).
The problem is they need to be practical as well, something that most comments here don't consider.
There is no point designing a foolproof system that no-one can use.This hole can be removed and it most certainly will be if criminals start to exploit it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107722</id>
	<title>Re:We Already Know This</title>
	<author>Peter H.S.</author>
	<datestamp>1265894400000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p><i>This has been known for years. The machines and man-in-the-middle attacks are obvious, simply because you cannot verify the authenticity of any machine that you stick your card into and type your PIN. You have no clue that any one of them is doing what you think it should be doing. ATM machines are bad enough, but at least there is some sort of trust over the fact they are at a fixed point and there is some form of physical security around them. With chip and pin machines all you have is utterly blind faith that you have no choice but to accept, and then you get blamed for being insecure by the banks when the inevitable happens.</i></p><p>Please note that while this is a MIM attack, neither the ATM nor its communication links are compromised. The MIM part is in the \_card\_, that gives out an "This is a valid transaction PIN code" no matter what. So attach a fake card to some wires running up your sleeve into a laptop and FPGA in a back pack, and and you can draw money from the account to the maximum limit with a fake card and without entering a correct PIN code.</p><p>The sad thing is that the banks are in total denial about this, claiming that since no such attacks have been discovered, the problem doesn't exist.</p><p>--<br>Regards</p></htmltext>
<tokenext>This has been known for years .
The machines and man-in-the-middle attacks are obvious , simply because you can not verify the authenticity of any machine that you stick your card into and type your PIN .
You have no clue that any one of them is doing what you think it should be doing .
ATM machines are bad enough , but at least there is some sort of trust over the fact they are at a fixed point and there is some form of physical security around them .
With chip and pin machines all you have is utterly blind faith that you have no choice but to accept , and then you get blamed for being insecure by the banks when the inevitable happens.Please note that while this is a MIM attack , neither the ATM nor its communication links are compromised .
The MIM part is in the \ _card \ _ , that gives out an " This is a valid transaction PIN code " no matter what .
So attach a fake card to some wires running up your sleeve into a laptop and FPGA in a back pack , and and you can draw money from the account to the maximum limit with a fake card and without entering a correct PIN code.The sad thing is that the banks are in total denial about this , claiming that since no such attacks have been discovered , the problem does n't exist.--Regards</tokentext>
<sentencetext>This has been known for years.
The machines and man-in-the-middle attacks are obvious, simply because you cannot verify the authenticity of any machine that you stick your card into and type your PIN.
You have no clue that any one of them is doing what you think it should be doing.
ATM machines are bad enough, but at least there is some sort of trust over the fact they are at a fixed point and there is some form of physical security around them.
With chip and pin machines all you have is utterly blind faith that you have no choice but to accept, and then you get blamed for being insecure by the banks when the inevitable happens.Please note that while this is a MIM attack, neither the ATM nor its communication links are compromised.
The MIM part is in the \_card\_, that gives out an "This is a valid transaction PIN code" no matter what.
So attach a fake card to some wires running up your sleeve into a laptop and FPGA in a back pack, and and you can draw money from the account to the maximum limit with a fake card and without entering a correct PIN code.The sad thing is that the banks are in total denial about this, claiming that since no such attacks have been discovered, the problem doesn't exist.--Regards</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110712</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>maevius</author>
	<datestamp>1265969520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In order for the transaction to be authorized by the server, the PIN is encrypted and sent by the terminal using a symmetric key that the bank gives the terminal vendor. So no this is not possible</htmltext>
<tokenext>In order for the transaction to be authorized by the server , the PIN is encrypted and sent by the terminal using a symmetric key that the bank gives the terminal vendor .
So no this is not possible</tokentext>
<sentencetext>In order for the transaction to be authorized by the server, the PIN is encrypted and sent by the terminal using a symmetric key that the bank gives the terminal vendor.
So no this is not possible</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107296</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31114874</id>
	<title>chip and pin not broken, UK Banks that Issue Cards</title>
	<author>Anonymous</author>
	<datestamp>1265997540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Calling EMV broken is laughable. First EMV supplys a variaty of options that are scalable in complexity and security. For example SDA, EMV covers the possibility of a static authentication, is it safe? not realy. Replay attacks are super easy.<br>About the attack this guys use. DDA, that means dynamic authentication<nobr> <wbr></nobr>,where unlike SDA the cryptogram is not static, meaning that replay attacks are not possible. HOWEVER it does not prevent WEDGE attacks or man in the middle, whatever you want to call it. This DDA weakness, as the SDA weakness are documented, reading it right now in one famous card issuer company (TOP3), that even don't allow cards issued with DDA and SDA , this document is 4 years old.<br>There is a 3 option CDA, this avoids both MITM and Replay attacks. It very similiar to DDA, but adds one level of security, it puts all the sensitive data INSIDE the crytogram, including the PIN OK verification, this guaranties that the PIN OK comes from the card, as the card is the only one that can generate the cryptogram (Private Key). Making this kind of attack impossible without cracking the private keys .</p><p>Concluding, Its the issuers responsability to implement the best options AVAILABLE (EMV offer various options of security level vs complexity ) for the level of security to their needs.<br>The weakness here is TOTALY the issuers fault.</p><p>PS. this is not a genius attack, it's a well none fact to EMV, it's not a dirty secret. Making news of this is just.. wierd. Take from a guy who actualy works with the stuff.</p></htmltext>
<tokenext>Calling EMV broken is laughable .
First EMV supplys a variaty of options that are scalable in complexity and security .
For example SDA , EMV covers the possibility of a static authentication , is it safe ?
not realy .
Replay attacks are super easy.About the attack this guys use .
DDA , that means dynamic authentication ,where unlike SDA the cryptogram is not static , meaning that replay attacks are not possible .
HOWEVER it does not prevent WEDGE attacks or man in the middle , whatever you want to call it .
This DDA weakness , as the SDA weakness are documented , reading it right now in one famous card issuer company ( TOP3 ) , that even do n't allow cards issued with DDA and SDA , this document is 4 years old.There is a 3 option CDA , this avoids both MITM and Replay attacks .
It very similiar to DDA , but adds one level of security , it puts all the sensitive data INSIDE the crytogram , including the PIN OK verification , this guaranties that the PIN OK comes from the card , as the card is the only one that can generate the cryptogram ( Private Key ) .
Making this kind of attack impossible without cracking the private keys .Concluding , Its the issuers responsability to implement the best options AVAILABLE ( EMV offer various options of security level vs complexity ) for the level of security to their needs.The weakness here is TOTALY the issuers fault.PS .
this is not a genius attack , it 's a well none fact to EMV , it 's not a dirty secret .
Making news of this is just.. wierd. Take from a guy who actualy works with the stuff .</tokentext>
<sentencetext>Calling EMV broken is laughable.
First EMV supplys a variaty of options that are scalable in complexity and security.
For example SDA, EMV covers the possibility of a static authentication, is it safe?
not realy.
Replay attacks are super easy.About the attack this guys use.
DDA, that means dynamic authentication ,where unlike SDA the cryptogram is not static, meaning that replay attacks are not possible.
HOWEVER it does not prevent WEDGE attacks or man in the middle, whatever you want to call it.
This DDA weakness, as the SDA weakness are documented, reading it right now in one famous card issuer company (TOP3), that even don't allow cards issued with DDA and SDA , this document is 4 years old.There is a 3 option CDA, this avoids both MITM and Replay attacks.
It very similiar to DDA, but adds one level of security, it puts all the sensitive data INSIDE the crytogram, including the PIN OK verification, this guaranties that the PIN OK comes from the card, as the card is the only one that can generate the cryptogram (Private Key).
Making this kind of attack impossible without cracking the private keys .Concluding, Its the issuers responsability to implement the best options AVAILABLE (EMV offer various options of security level vs complexity ) for the level of security to their needs.The weakness here is TOTALY the issuers fault.PS.
this is not a genius attack, it's a well none fact to EMV, it's not a dirty secret.
Making news of this is just.. wierd. Take from a guy who actualy works with the stuff.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108086</id>
	<title>Re:Do they still need the card?</title>
	<author>JackHoffman</author>
	<datestamp>1265896560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yes, they still need the card. The card performs a "chip and signature" protocol with the bank. In the "chip and signature" protocol as well as in the "chip and PIN" protocol, the chip on the card uses a secret symmetric key to create a transaction-specific message authentication code. The bank will not accept the transaction without that code. The attack is to have the card perform "chip and signature" while the terminal performs "chip and PIN". The protocol flaw is that the terminal cannot tell that the card is not performing "chip and PIN".</p><p>The messages between the card and the bank do usually include this information, but the format is not part of the standard. Consequently the terminal can not read it. It blindly relays the "chip and signature" messages, thinking that they're "chip and PIN" messages. The other indication that something's wrong would be the lack of a PIN-OK message from the card, but this message is not authenticated in any way, so the MITM can just fake that part of the "chip and PIN" protocol.</p></htmltext>
<tokenext>Yes , they still need the card .
The card performs a " chip and signature " protocol with the bank .
In the " chip and signature " protocol as well as in the " chip and PIN " protocol , the chip on the card uses a secret symmetric key to create a transaction-specific message authentication code .
The bank will not accept the transaction without that code .
The attack is to have the card perform " chip and signature " while the terminal performs " chip and PIN " .
The protocol flaw is that the terminal can not tell that the card is not performing " chip and PIN " .The messages between the card and the bank do usually include this information , but the format is not part of the standard .
Consequently the terminal can not read it .
It blindly relays the " chip and signature " messages , thinking that they 're " chip and PIN " messages .
The other indication that something 's wrong would be the lack of a PIN-OK message from the card , but this message is not authenticated in any way , so the MITM can just fake that part of the " chip and PIN " protocol .</tokentext>
<sentencetext>Yes, they still need the card.
The card performs a "chip and signature" protocol with the bank.
In the "chip and signature" protocol as well as in the "chip and PIN" protocol, the chip on the card uses a secret symmetric key to create a transaction-specific message authentication code.
The bank will not accept the transaction without that code.
The attack is to have the card perform "chip and signature" while the terminal performs "chip and PIN".
The protocol flaw is that the terminal cannot tell that the card is not performing "chip and PIN".The messages between the card and the bank do usually include this information, but the format is not part of the standard.
Consequently the terminal can not read it.
It blindly relays the "chip and signature" messages, thinking that they're "chip and PIN" messages.
The other indication that something's wrong would be the lack of a PIN-OK message from the card, but this message is not authenticated in any way, so the MITM can just fake that part of the "chip and PIN" protocol.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31126298</id>
	<title>Phish and Chips</title>
	<author>sydbarrett74</author>
	<datestamp>1266070320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>So would this attack be called phish and chips?</htmltext>
<tokenext>So would this attack be called phish and chips ?</tokentext>
<sentencetext>So would this attack be called phish and chips?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108392</id>
	<title>Noviant Haydont</title>
	<author>Anonymous</author>
	<datestamp>1265898720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>EMV is an International standard implemented on ALL continents. Not just Europe. It was designed by two major US companies (Visa and MasterCard) and a small European one (Europay).<br>So no, its not a European standard. EMVCo: http://www.emvco.com/</p><p>And by the way, US is the only country with no plan to implement this standard that was imposed to the rest of the world. Why?...</p></htmltext>
<tokenext>EMV is an International standard implemented on ALL continents .
Not just Europe .
It was designed by two major US companies ( Visa and MasterCard ) and a small European one ( Europay ) .So no , its not a European standard .
EMVCo : http : //www.emvco.com/And by the way , US is the only country with no plan to implement this standard that was imposed to the rest of the world .
Why ? .. .</tokentext>
<sentencetext>EMV is an International standard implemented on ALL continents.
Not just Europe.
It was designed by two major US companies (Visa and MasterCard) and a small European one (Europay).So no, its not a European standard.
EMVCo: http://www.emvco.com/And by the way, US is the only country with no plan to implement this standard that was imposed to the rest of the world.
Why?...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107358</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>Anonymous</author>
	<datestamp>1265892480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I wish I had mod points for you. It's buried at the end of the first page of the article but you're exactly right - they clearly state that the pin you enter is compared to the pin on the card... These researchers didn't even break that comparison mechanism, they just impersonate the chip to tell the payment processor "yup all is well, pin is verified!"</htmltext>
<tokenext>I wish I had mod points for you .
It 's buried at the end of the first page of the article but you 're exactly right - they clearly state that the pin you enter is compared to the pin on the card... These researchers did n't even break that comparison mechanism , they just impersonate the chip to tell the payment processor " yup all is well , pin is verified !
"</tokentext>
<sentencetext>I wish I had mod points for you.
It's buried at the end of the first page of the article but you're exactly right - they clearly state that the pin you enter is compared to the pin on the card... These researchers didn't even break that comparison mechanism, they just impersonate the chip to tell the payment processor "yup all is well, pin is verified!
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105916</id>
	<title>Re:Chip and Chip security... wait a second!</title>
	<author>Conorflan</author>
	<datestamp>1265886480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"The American "contact" systems are actually reasons to not require a signature or a PIN"

I may have misunderstood this statement, but by stating it you appear to be implying that the European system is contactless.
Or is "contact" meant to mean something other than physical contact?</htmltext>
<tokenext>" The American " contact " systems are actually reasons to not require a signature or a PIN " I may have misunderstood this statement , but by stating it you appear to be implying that the European system is contactless .
Or is " contact " meant to mean something other than physical contact ?</tokentext>
<sentencetext>"The American "contact" systems are actually reasons to not require a signature or a PIN"

I may have misunderstood this statement, but by stating it you appear to be implying that the European system is contactless.
Or is "contact" meant to mean something other than physical contact?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107250</id>
	<title>Simple Solution</title>
	<author>bill\_mcgonigle</author>
	<datestamp>1265892060000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>and a laptop running a Python script</i></p><p>So, classify Python as a criminal tool, problem solved.</p><p>(the rule that you have to mention Python at every possibility cuts both ways).</p></htmltext>
<tokenext>and a laptop running a Python scriptSo , classify Python as a criminal tool , problem solved .
( the rule that you have to mention Python at every possibility cuts both ways ) .</tokentext>
<sentencetext>and a laptop running a Python scriptSo, classify Python as a criminal tool, problem solved.
(the rule that you have to mention Python at every possibility cuts both ways).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31111068</id>
	<title>APACS rumbled - all scarper</title>
	<author>dugeen</author>
	<datestamp>1265974800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>The idea of forcing people to enter PINs into any machine controlled by a retailer was ridiculous from day one - the supposed extra security of Chip &amp; Fraud was merely a way for the banks to transfer liability for fraud to the customer. (Happily the FSA has now forbidden them to do this unless they have actual genuine proof that the customer gave away their PIN - well done guys, springing into action after only 4 years of complaints).</htmltext>
<tokenext>The idea of forcing people to enter PINs into any machine controlled by a retailer was ridiculous from day one - the supposed extra security of Chip &amp; Fraud was merely a way for the banks to transfer liability for fraud to the customer .
( Happily the FSA has now forbidden them to do this unless they have actual genuine proof that the customer gave away their PIN - well done guys , springing into action after only 4 years of complaints ) .</tokentext>
<sentencetext>The idea of forcing people to enter PINs into any machine controlled by a retailer was ridiculous from day one - the supposed extra security of Chip &amp; Fraud was merely a way for the banks to transfer liability for fraud to the customer.
(Happily the FSA has now forbidden them to do this unless they have actual genuine proof that the customer gave away their PIN - well done guys, springing into action after only 4 years of complaints).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108918</id>
	<title>Re:Cashiers cant see the card</title>
	<author>jonwil</author>
	<datestamp>1265903280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Here in Australia, as a rule most cashiers dont generally handle the card (all the swipe machines are usually in places where the customer can see them, swipe and enter his pin)</p></htmltext>
<tokenext>Here in Australia , as a rule most cashiers dont generally handle the card ( all the swipe machines are usually in places where the customer can see them , swipe and enter his pin )</tokentext>
<sentencetext>Here in Australia, as a rule most cashiers dont generally handle the card (all the swipe machines are usually in places where the customer can see them, swipe and enter his pin)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107978</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105916
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107978
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107316
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105936
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110932
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31115010
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107722
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108304
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107358
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110712
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107296
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31112422
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31115020
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106966
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108670
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106622
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31117290
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_11_2129212_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106702
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_11_2129212.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108392
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_11_2129212.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105626
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107358
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105916
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107296
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110712
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105792
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31110932
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106880
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108670
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31105936
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107894
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106966
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106622
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_11_2129212.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107070
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_11_2129212.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107978
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108918
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_11_2129212.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107816
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31115020
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108086
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31108304
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31117290
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31112422
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_11_2129212.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31111068
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_11_2129212.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106172
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107722
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31115010
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31106702
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_11_2129212.31107316
</commentlist>
</conversation>
