From deengert at gmail.com  Sat May 13 14:38:11 2023
From: deengert at gmail.com (Douglas E Engert)
Date: Sat, 13 May 2023 16:38:11 -0500
Subject: [Pcsclite-muscle] PCSC use of ATR 3B 8K 80 01 ... for contactless
 readers
Message-ID: <f0f0550a-a963-c2b5-b67e-40e656595c85@gmail.com>

As suggested by? Ludovic Rousseau in this comment:
https://github.com/OpenSC/OpenSC/pull/2053#issuecomment-1546227385

I would like to know why:

http://pcscworkgroup.com/Download/Specifications/pcsc3_v2.01.09.pdf
"3.1.3.2.3 ATR" says:
"For contactless ICCs, the IFD subsystem must construct an ATR from the fixed elements that identify the cards.

Was this chosen because there is no way that a real ATR could have the same format?

Is there some reference in any recent versions of? ISO/IEC 7816-3 that says this is OK to use this constructed ATR?
 ?Thanks.

-- 

  Douglas E. Engert  <DEEngert at gmail.com>
  



From aferron at cardhoc.com  Sun May 14 06:50:04 2023
From: aferron at cardhoc.com (Antoine FERRON)
Date: Sun, 14 May 2023 13:50:04 +0000
Subject: [Pcsclite-muscle] PCSC use of ATR 3B 80 80 01 for contactless
 readers
In-Reply-To: <f0f0550a-a963-c2b5-b67e-40e656595c85@gmail.com>
References: <f0f0550a-a963-c2b5-b67e-40e656595c85@gmail.com>
Message-ID: <VE1P192MB0701FEC066FAB3C5F753FD16A67B9@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>

I only know this "fake ATR" in PC/SC, and nowhere else. No other standard bodies have approved (or even have referred to) this fake ATR by the PC/SC WG (AFAIK). I'm not sure whether the PCSC WG took precaution to chose ATRs that are somewhat unique and recognizable as being from a contactless card. It depends on the reader, and the number of details it provides. In your specific case, the reader/card only sends the bare minimum, so it's hard to tell. The only thing is that the "constructed" ATR is a valid format for ISO7816. Maybe PC/SC WG has a mailing list where you can specifically ask about the rationale behind the choice of these ATRs. Chances are that they only considered compatibility, and not the "recognition pattern".

To understand why it was designed like that, PCSC is a protocol to connect a smartcard reader to an operating system. And in Windows, the smartcard service, winscard, can't tell the difference between a contactless or a contact smartcard, it is designed only for ISO7816, and doesn't take in account the contactless interface. For example, it always provides ATR from a card. So the only way to make it work was to provide a fake ATR, to inform the system about a NFC card, exactly like it was a contact card. We can say the NFC stack is dressed up as a contact stack, hence the need to provide an ATR. Windows and PCSC make best effort to maintain "contact interface" compatibility and conceal contactless as a contact card. Then CCID and PCSClite are implementations of the smartcard service on Linux, built to mimic winscard interface, and use PCSC readers, so this mechanism has been carried on. By using PCSC, the system doesn't tell if it's a contact or contactless smartcard. Only the application can tell, by eventually scanning the ATR and look if it is one constructed from a contactless card (following PC/SC requirements). But there's no guarantee, there's no real information in an ATR, even "constructed", or declared by the PCSC reader. That way is not very useful.

I spent considerable time on this topic, how to know from winscard if this is a contact or contactless interface in use. Initially our software uses various methods to guess it. But some of them make the card connection unreliable (crashing some readers, adding delay at connection,...), so we simplify the detection. It is less accurate, but faster and more reliable (no more reader crash). Now it provides "is contactless" when it is sure (when the simple methods detect for sure), and "is contact" with also some degree of confidence (if sure or not).

For PIV and the topic we matter here, I suggest that you find a reliable discrimination command in the PIV applet to see if the PIV card is addressed using a contact or contactless interface. Like, send "do that" command and the applet replies "ok" with contact, and "no can do" when contactless. The PIV standard really separates the command and file system permissions depending on the interface, so you may find some. It is like a trial and error, but this will be reliable on a decent PIV card implementation, more reliable than using the PCSC interface data.

Antoine FERRON
CTO & Co-founder
CARDHOC Limited
aferron at cardhoc.com - https://cardhoc.com


-----Original Message-----
From: pcsclite-muscle <pcsclite-muscle-bounces at lists.infradead.org> On Behalf Of Douglas E Engert
Sent: Saturday, 13 May, 2023 23:38
To: pcsclite-muscle at lists.infradead.org
Subject: [Pcsclite-muscle] PCSC use of ATR 3B 8K 80 01 ... for contactless readers

As suggested by? Ludovic Rousseau in this comment:
https://github.com/OpenSC/OpenSC/pull/2053#issuecomment-1546227385

I would like to know why:

http://pcscworkgroup.com/Download/Specifications/pcsc3_v2.01.09.pdf
"3.1.3.2.3 ATR" says:
"For contactless ICCs, the IFD subsystem must construct an ATR from the fixed elements that identify the cards.

Was this chosen because there is no way that a real ATR could have the same format?

Is there some reference in any recent versions of? ISO/IEC 7816-3 that says this is OK to use this constructed ATR?
 ?Thanks.

-- 

  Douglas E. Engert  <DEEngert at gmail.com>
  


_______________________________________________
pcsclite-muscle mailing list
pcsclite-muscle at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/pcsclite-muscle

From sebastien at lorquet.fr  Mon May 15 00:30:54 2023
From: sebastien at lorquet.fr (Sebastien Lorquet)
Date: Mon, 15 May 2023 09:30:54 +0200
Subject: [Pcsclite-muscle] PCSC use of ATR 3B 80 80 01 for contactless
 readers
In-Reply-To: <VE1P192MB0701FEC066FAB3C5F753FD16A67B9@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
References: <f0f0550a-a963-c2b5-b67e-40e656595c85@gmail.com>
 <VE1P192MB0701FEC066FAB3C5F753FD16A67B9@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
Message-ID: <d3e2514a-9834-f77a-899f-ac5fa64726de@lorquet.fr>

Hello,

oh my gosh yes, same, I developed a contactless reader and it was a pain 
to make it work "driverless", eg with the undocumented microsoft CCID 
drivers.

The ATR is a pure contact protocol thing and it has no equivalent data 
field in any contactless mode, except maybe ISO14443-4 part A which has 
an ATS, with fields similar to an ATR but still not the same.

PC/SC dates back from a time when contactless was not a thing. I read it 
was available for Windows NT4 (their faq says released in 1997, 
https://pcscworkgroup.com/home/faq/ , which is basically the year 
contactless cards were "invented").

Sebastien

Le 14/05/2023 ? 15:50, Antoine FERRON a ?crit?:
> I only know this "fake ATR" in PC/SC, and nowhere else. No other standard bodies have approved (or even have referred to) this fake ATR by the PC/SC WG (AFAIK). I'm not sure whether the PCSC WG took precaution to chose ATRs that are somewhat unique and recognizable as being from a contactless card. It depends on the reader, and the number of details it provides. In your specific case, the reader/card only sends the bare minimum, so it's hard to tell. The only thing is that the "constructed" ATR is a valid format for ISO7816. Maybe PC/SC WG has a mailing list where you can specifically ask about the rationale behind the choice of these ATRs. Chances are that they only considered compatibility, and not the "recognition pattern".
>
> To understand why it was designed like that, PCSC is a protocol to connect a smartcard reader to an operating system. And in Windows, the smartcard service, winscard, can't tell the difference between a contactless or a contact smartcard, it is designed only for ISO7816, and doesn't take in account the contactless interface. For example, it always provides ATR from a card. So the only way to make it work was to provide a fake ATR, to inform the system about a NFC card, exactly like it was a contact card. We can say the NFC stack is dressed up as a contact stack, hence the need to provide an ATR. Windows and PCSC make best effort to maintain "contact interface" compatibility and conceal contactless as a contact card. Then CCID and PCSClite are implementations of the smartcard service on Linux, built to mimic winscard interface, and use PCSC readers, so this mechanism has been carried on. By using PCSC, the system doesn't tell if it's a contact or contactless smartcard. Only the application can tell, by eventually scanning the ATR and look if it is one constructed from a contactless card (following PC/SC requirements). But there's no guarantee, there's no real information in an ATR, even "constructed", or declared by the PCSC reader. That way is not very useful.
>
> I spent considerable time on this topic, how to know from winscard if this is a contact or contactless interface in use. Initially our software uses various methods to guess it. But some of them make the card connection unreliable (crashing some readers, adding delay at connection,...), so we simplify the detection. It is less accurate, but faster and more reliable (no more reader crash). Now it provides "is contactless" when it is sure (when the simple methods detect for sure), and "is contact" with also some degree of confidence (if sure or not).
>
> For PIV and the topic we matter here, I suggest that you find a reliable discrimination command in the PIV applet to see if the PIV card is addressed using a contact or contactless interface. Like, send "do that" command and the applet replies "ok" with contact, and "no can do" when contactless. The PIV standard really separates the command and file system permissions depending on the interface, so you may find some. It is like a trial and error, but this will be reliable on a decent PIV card implementation, more reliable than using the PCSC interface data.
>
> Antoine FERRON
> CTO & Co-founder
> CARDHOC Limited
> aferron at cardhoc.com - https://cardhoc.com
>
>
> -----Original Message-----
> From: pcsclite-muscle <pcsclite-muscle-bounces at lists.infradead.org> On Behalf Of Douglas E Engert
> Sent: Saturday, 13 May, 2023 23:38
> To: pcsclite-muscle at lists.infradead.org
> Subject: [Pcsclite-muscle] PCSC use of ATR 3B 8K 80 01 ... for contactless readers
>
> As suggested by? Ludovic Rousseau in this comment:
> https://github.com/OpenSC/OpenSC/pull/2053#issuecomment-1546227385
>
> I would like to know why:
>
> http://pcscworkgroup.com/Download/Specifications/pcsc3_v2.01.09.pdf
> "3.1.3.2.3 ATR" says:
> "For contactless ICCs, the IFD subsystem must construct an ATR from the fixed elements that identify the cards.
>
> Was this chosen because there is no way that a real ATR could have the same format?
>
> Is there some reference in any recent versions of? ISO/IEC 7816-3 that says this is OK to use this constructed ATR?
>   ?Thanks.
>

