From emaxx at google.com  Thu Aug 11 05:07:45 2022
From: emaxx at google.com (Maksim Ivanov)
Date: Thu, 11 Aug 2022 14:07:45 +0200
Subject: [Pcsclite-muscle] Change the error code when PC/SC access is
 refused by polkit?
In-Reply-To: <CAGstE8CH-bVuDVf=81XuXw8DWCWUL9p-+YGtrm44qWKvTvOWHA@mail.gmail.com>
References: <CAGstE8CH-bVuDVf=81XuXw8DWCWUL9p-+YGtrm44qWKvTvOWHA@mail.gmail.com>
Message-ID: <CAH=wB8z9XKyimAgvVMoR4nAqYVYjffeVdxOzGvSosWqwYhQw6g@mail.gmail.com>

Hi,

Just my 2 cents: the "SCARD_W_SECURITY_VIOLATION" error code sounds
like a reasonable reply for the "NOT authorized for action" error.

But I don't know either how easy it'd be to implement it.


Regards,
Maksim


On Fri, Jul 29, 2022 at 4:33 PM Ludovic Rousseau
<ludovic.rousseau at gmail.com> wrote:
>
> Hello,
>
> I am using PC/SC on CentOS/RedHat and I am often surprised when I get the error:
> $ pcsc_scan
> SCardEstablishContext: RPC transport error.
>
> The error code is SCARD_F_COMM_ERROR
> https://pcsclite.apdu.fr/api/group__ErrorCodes.html#ga93d3cf468d69423eab1d478a7a870408
>
> From the pcscd logs I see:
> 00000003 [139737213696960] pcscdaemon.c:133:SVCServiceRunLoop() A new
> context thread creation is requested: 10
> 00019807 [139737012623104] auth.c:139:IsClientAuthorized() Process
> 41685 (user: 1000) is NOT authorized for action: access_pcsc
> 00000107 [139737012623104] winscard_svc.c:335:ContextThread() Rejected
> unauthorized PC/SC client
>
> So I get SCARD_F_COMM_ERROR because auth.c (in fact polkit) decided I
> should not have access to PC/SC.
> For example this happens when I connect to the computer using ssh, and
> not from the console.
>
> The error is even more confusing if you enable logs in the client:
> $ PCSCLITE_DEBUG=0 pcsc_scan
> winscard_clnt.c:605:SCardEstablishContextTH() Your pcscd is too old
> and does not support CMD_VERSION
> SCardEstablishContext: RPC transport error.
>
> The problem is NOT that pcscd is too old :-)
>
>
> I was thinking: maybe a more explicit error code would be better?
> Maybe SCARD_E_SYSTEM_CANCELLED or SCARD_W_SECURITY_VIOLATION
>
> I do not want to invent a new WinSCard return value.
> We should use one form the list
> https://docs.microsoft.com/en-us/windows/win32/secauthn/authentication-return-values
>
> I don't know if it is easy to implement. When polkit refuses the
> connection the pcscd server just closes the socket without sending
> *anything* to the client.
>
> Any comment?
>
> Regards,
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From aferron at cardhoc.com  Thu Aug 11 07:31:58 2022
From: aferron at cardhoc.com (Antoine FERRON)
Date: Thu, 11 Aug 2022 14:31:58 +0000
Subject: [Pcsclite-muscle] Know the interface connection type with a card
In-Reply-To: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
References: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
Message-ID: <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>

Dear smartcard friends,

I'm writing here since the PyScard developer recommended to do so to get a broader audience for my question. It is not strictly about the pcsc-lite system, but more about PyScard.

Using pyscard, I recently spent some time trying to build a detection method in smartcards handling library to know whether the card connection is through contactless or with contacts. And so far, I didn't find any reliable method to get this information. This is needed as some cards behave differently depending of the access interface, mostly because internally the applet knows which interface is currently used, and can act accordingly. Also, some standards like EMV instruct to behave differently depending of the access interface. All that makes the need for knowing the access interface when talking to a smartcard.
My idea is to have in the Python card object a is_contactless attribute which is true when the connection is done through the wireless interface. How can it be done ? On Windows ? On Mac ? On Linux? Our main and first target is Windows, and I feel this is an actual issue in Windows. As the Win Scard interface doesn't seem to offer any way to read this. Hence my question, I maybe missed one thing to get this info.
I have to say the method should not rely on a specific applet, but should be universal to provide the type of access connection in use to talk with the card (RF contactless or wires contact).

Thanks,
AF


From dandrader at google.com  Fri Aug 12 03:00:05 2022
From: dandrader at google.com (Daniel d'Andrada)
Date: Fri, 12 Aug 2022 12:00:05 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
Message-ID: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>

Hi all,

I'm proposing a Web API for smart cards, at PC/SC level. It will give
a page access to the PC/SC implementation (and card reader drivers)
available in the host OS. Meaning PCSClite on Linux, macOS and
ChromeOS.

It's hosted here:
https://github.com/dandrader/web-smart-card/blob/main/README.md
If interested, you can file bugs in that repo to discuss problems you see in it.

I would appreciate the opinion of the PC/SC experts and users here.

Best regards,
Daniel


From andreas.schwier at cardcontact.de  Fri Aug 12 03:13:35 2022
From: andreas.schwier at cardcontact.de (Andreas Schwier)
Date: Fri, 12 Aug 2022 12:13:35 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
Message-ID: <4e907620-4a8d-25e2-aac2-5231df2e1087@cardcontact.de>

Hi Daniel,

having such an API would be a great thing. Right now we need additional 
applications on the host to integrate with smart cards in a web 
application [1].

My feeling so far was, that browser manufacturer didn't want to 
integrate with client side hardware.

Has that changed and who is driving this ?

Andreas

[1] https://www.openscdp.org/scriptingserver/remoteterminal.html

On 12.08.22 12:00, Daniel d'Andrada wrote:
> Hi all,
> 
> I'm proposing a Web API for smart cards, at PC/SC level. It will give
> a page access to the PC/SC implementation (and card reader drivers)
> available in the host OS. Meaning PCSClite on Linux, macOS and
> ChromeOS.
> 
> It's hosted here:
> https://github.com/dandrader/web-smart-card/blob/main/README.md
> If interested, you can file bugs in that repo to discuss problems you see in it.
> 
> I would appreciate the opinion of the PC/SC experts and users here.
> 
> Best regards,
> Daniel
> 
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle

-- 
     ---------    CardContact Systems GmbH
    |.##> <##.|   Sch?lerweg 38
    |#       #|   D-32429 Minden, Germany
    |#       #|   Phone +49 571 56149
    |'##> <##'|   http://www.cardcontact.de
     ---------    Registergericht Bad Oeynhausen HRB 14880
                  Gesch?ftsf?hrer Andreas Schwier


From aferron at cardhoc.com  Fri Aug 12 05:43:09 2022
From: aferron at cardhoc.com (Antoine FERRON)
Date: Fri, 12 Aug 2022 12:43:09 +0000
Subject: [Pcsclite-muscle] Know the interface connection type with a card
In-Reply-To: <CAGRN=sDCfbKFnEPHnyD-6C3myuxWRsgkwAC_OkCXPG7v+HQvPA@mail.gmail.com>
References: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <CAGRN=sDCfbKFnEPHnyD-6C3myuxWRsgkwAC_OkCXPG7v+HQvPA@mail.gmail.com>
Message-ID: <VE1P192MB0701F004761A5E3B84087427A6679@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>

Awesome, thanks!
I didn?t think about this. And I know this command that I use for NFC tags applications. I can confirm that nearly all contactless readers are supporting this command, so this should be a quite reliable method.

So far, I notice that some contactless readers are identified with ?CL?, but it was not all the time, probably half of the readers are doing this. I tried this method, as you suggest, but I let this down, because only some readers do that. But I will combine this with the UID reading, that should provide a decent manner to infer if the card is access through the contactless interface or not.

FYI, other paths I tried without any success.  One was to read the T=15 flag from pyScard connection.getProtocol(), but it never provides this value, especially in Windows, where the Scard interface only lists T0 and T1. The other was trying to see if the ATR (ATS image) was short enough to be computed from ATS, hence being a contactless connection. But no clear limit was found for this criterion to provide any useful info.

To Sylvain Feret who also proposed the same idea,
> I haven't taken the time to figure out which of 14443-3 or -4, or maybe the WinSCard interface is handling this command.
> I would like to read about results obtained under linux/MacOS.
This command is intercepted by the reader, and not actually transmitted to the tag/chip/card. This command is a query for the reader. So this is not part of any ISO7816/14443 standards. But rather a PCSC industry defacto standard. But in case the reader doesn't support it (if contact for ex), the command is sent/forwarded to the card.
The compatibility in Linux and Mac should be good enough, as this is an APDU message and the reader will potentially handle it. I can't see any issue for this global behaviour would be different relative to the OS.

My first practical tests, I found out that some T=0 cards in contact readers are receiving this command forwarded by the reader (as the reader doesn't handle this command). And this command stalls the card, it breaks the card connection and I need to reconnect to the card in order to continue sending any new command. Pretty annoying.

AF


From: Marc Jacquinot <marc at cardwerk.com> 
Sent: 11 August 2022 17:50
To: Antoine FERRON <aferron at cardhoc.com>
Cc: pcsclite-muscle at lists.infradead.org
Subject: Re: [Pcsclite-muscle] Know the interface connection type with a card

Hi Antoine,
most PCSC compatible?readers allow UID access via FFCA0000 command APDU. If you are getting an ATR and UID, you know that you are dealing with a contactless card interface. Depending on the card reader manufacturer, the reader name may also reflect the interface (CL, cl, contactless ...). However, that's not standardized.
Regards,
Marc

On Thu, Aug 11, 2022 at 10:31 AM Antoine FERRON <mailto:aferron at cardhoc.com> wrote:
Dear smartcard friends,

I'm writing here since the PyScard developer recommended to do so to get a broader audience for my question. It is not strictly about the pcsc-lite system, but more about PyScard.

Using pyscard, I recently spent some time trying to build a detection method in smartcards handling library to know whether the card connection is through contactless or with contacts. And so far, I didn't find any reliable method to get this information. This is needed as some cards behave differently depending of the access interface, mostly because internally the applet knows which interface is currently used, and can act accordingly. Also, some standards like EMV instruct to behave differently depending of the access interface. All that makes the need for knowing the access interface when talking to a smartcard.
My idea is to have in the Python card object a is_contactless attribute which is true when the connection is done through the wireless interface. How can it be done ? On Windows ? On Mac ? On Linux? Our main and first target is Windows, and I feel this is an actual issue in Windows. As the Win Scard interface doesn't seem to offer any way to read this. Hence my question, I maybe missed one thing to get this info.
I have to say the method should not rely on a specific applet, but should be universal to provide the type of access connection in use to talk with the card (RF contactless or wires contact).

Thanks,
AF

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



-- 
---------------------------------------------------------------
Marc Jacquinot - Smart Card Expert
<http://www.cardwerk.com/>
< Smart consulting - development - customization >
----------------------------------------------------------------
CardWerk Technologies
2615 George Busbee Pkwy
Suite 11-312
Kennesaw, GA 30144 - USA?
Office:?tel:770-514-8039?
??Please consider the environment before printing this e-mail.

From aferron at cardhoc.com  Fri Aug 12 06:01:00 2022
From: aferron at cardhoc.com (Antoine FERRON)
Date: Fri, 12 Aug 2022 13:01:00 +0000
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <4e907620-4a8d-25e2-aac2-5231df2e1087@cardcontact.de>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
 <4e907620-4a8d-25e2-aac2-5231df2e1087@cardcontact.de>
Message-ID: <VE1P192MB0701C3FC812755A845B364EBA6679@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>

I know there was a failed attempt to do very similar things.
Here's an official GP proposal :
http://globalplatform.github.io/WebApis-for-SE/doc/

Also Gemalto pushed years ago in this direction to add SC in the web world. https://www.w3.org/2015/06/secure_elements.pptx But the challenges were not solved, mostly because of a lack of interest from the W3C and web browsers editors.

W3C is now developing a FileAPI for the horror of security guy like me. But I still don't feel the mood to be interested to add smartcards.

Interesting ways to make a direct use of a smartcard from the web in practice (but rather hacky) are :
Use FIDO2 API to exchange message to a FIDO2 authr.
The native engine such as Windows CNG GIDS. So the cryptography web API see a service provider and can use an underlying smart card.

AF

-----Original Message-----
From: pcsclite-muscle <pcsclite-muscle-bounces at lists.infradead.org> On Behalf Of Andreas Schwier
Sent: 12 August 2022 12:14
To: pcsclite-muscle at lists.infradead.org
Subject: Re: [Pcsclite-muscle] Proposal for a Web API for smart cards

Hi Daniel,

having such an API would be a great thing. Right now we need additional applications on the host to integrate with smart cards in a web application [1].

My feeling so far was, that browser manufacturer didn't want to integrate with client side hardware.

Has that changed and who is driving this ?

Andreas

[1] https://www.openscdp.org/scriptingserver/remoteterminal.html

On 12.08.22 12:00, Daniel d'Andrada wrote:
> Hi all,
> 
> I'm proposing a Web API for smart cards, at PC/SC level. It will give 
> a page access to the PC/SC implementation (and card reader drivers) 
> available in the host OS. Meaning PCSClite on Linux, macOS and 
> ChromeOS.
> 
> It's hosted here:
> https://github.com/dandrader/web-smart-card/blob/main/README.md
> If interested, you can file bugs in that repo to discuss problems you see in it.
> 
> I would appreciate the opinion of the PC/SC experts and users here.
> 
> Best regards,
> Daniel
> 
> _______________________________________________
> pcsclite-muscle mailing list
> mailto:pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle

-- 
     ---------    CardContact Systems GmbH
    |.##> <##.|   Sch?lerweg 38
    |#       #|   D-32429 Minden, Germany
    |#       #|   Phone +49 571 56149
    |'##> <##'|   http://www.cardcontact.de
     ---------    Registergericht Bad Oeynhausen HRB 14880
                  Gesch?ftsf?hrer Andreas Schwier

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

From dandrader at google.com  Fri Aug 12 06:07:49 2022
From: dandrader at google.com (Daniel d'Andrada)
Date: Fri, 12 Aug 2022 15:07:49 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <4e907620-4a8d-25e2-aac2-5231df2e1087@cardcontact.de>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
 <4e907620-4a8d-25e2-aac2-5231df2e1087@cardcontact.de>
Message-ID: <CA+enBd_cPJdAHRiHFM2ZOsXEJNHWc7B0GLf5kVV1YyYJUB-oMw@mail.gmail.com>

Hi Andreas,

There's a wealth of Web APIs for accessing client-side hardware already:
WebUSB, Web Bluetooth, Web NFC, Web Serial, WebHID, Gamepad.

So in that sense, a Web API for smart cards is not really breaking new ground.

On Fri, Aug 12, 2022 at 12:15 PM Andreas Schwier
<andreas.schwier at cardcontact.de> wrote:
>
> Hi Daniel,
>
> having such an API would be a great thing. Right now we need additional
> applications on the host to integrate with smart cards in a web
> application [1].
>
> My feeling so far was, that browser manufacturer didn't want to
> integrate with client side hardware.
>
> Has that changed and who is driving this ?
>
> Andreas
>
> [1] https://www.openscdp.org/scriptingserver/remoteterminal.html
>
> On 12.08.22 12:00, Daniel d'Andrada wrote:
> > Hi all,
> >
> > I'm proposing a Web API for smart cards, at PC/SC level. It will give
> > a page access to the PC/SC implementation (and card reader drivers)
> > available in the host OS. Meaning PCSClite on Linux, macOS and
> > ChromeOS.
> >
> > It's hosted here:
> > https://github.com/dandrader/web-smart-card/blob/main/README.md
> > If interested, you can file bugs in that repo to discuss problems you see in it.
> >
> > I would appreciate the opinion of the PC/SC experts and users here.
> >
> > Best regards,
> > Daniel
> >
> > _______________________________________________
> > pcsclite-muscle mailing list
> > pcsclite-muscle at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>
> --
>      ---------    CardContact Systems GmbH
>     |.##> <##.|   Sch?lerweg 38
>     |#       #|   D-32429 Minden, Germany
>     |#       #|   Phone +49 571 56149
>     |'##> <##'|   http://www.cardcontact.de
>      ---------    Registergericht Bad Oeynhausen HRB 14880
>                   Gesch?ftsf?hrer Andreas Schwier
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From ludovic.rousseau at gmail.com  Fri Aug 12 06:25:33 2022
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Fri, 12 Aug 2022 15:25:33 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
Message-ID: <CAGstE8BR7bnpVt0298v22+FAtt4dSAZy_SrPNpx7q-5GPw+F8A@mail.gmail.com>

Le ven. 12 ao?t 2022 ? 12:01, Daniel d'Andrada <dandrader at google.com> a ?crit :
> Hi all,

Hello Daniel,

> I'm proposing a Web API for smart cards, at PC/SC level. It will give
> a page access to the PC/SC implementation (and card reader drivers)
> available in the host OS. Meaning PCSClite on Linux, macOS and
> ChromeOS.
>
> It's hosted here:
> https://github.com/dandrader/web-smart-card/blob/main/README.md
> If interested, you can file bugs in that repo to discuss problems you see in it.
>
> I would appreciate the opinion of the PC/SC experts and users here.

I note this API is much easier to use than the previous one for Chrome OS
https://github.com/GoogleChromeLabs/chromeos_smart_card_connector

It is possible to identify a PC/SC reader by asking the USB VendorID
and ProductID.
See "Identifying a reader model (part 2)"
https://ludovicrousseau.blogspot.com/2012/04/identifying-reader-model-part-2.html
It works with my CCID driver so, I think, not with Windows CCID driver.

You do not target Windows. There is a technical reason?

Also I do not see any source code. Maybe it is just a API proposal
with no code available yet?

I already know SConnect for a similar software. But SConnect is not
Free Software
https://www.sconnect.com/faqs/#compatibility

Regards,

-- 
 Dr. Ludovic Rousseau


From dandrader at google.com  Fri Aug 12 08:42:40 2022
From: dandrader at google.com (Daniel d'Andrada)
Date: Fri, 12 Aug 2022 17:42:40 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <CAGstE8BR7bnpVt0298v22+FAtt4dSAZy_SrPNpx7q-5GPw+F8A@mail.gmail.com>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
 <CAGstE8BR7bnpVt0298v22+FAtt4dSAZy_SrPNpx7q-5GPw+F8A@mail.gmail.com>
Message-ID: <CA+enBd-7-qQxcjDXhoUOvaGth+=c=VPdY_yjzTQSd4bAJQK84w@mail.gmail.com>

Hi Ludovic,

Reading my e-mail again I see that it was misleading. It *is* also
targeting Windows (winscard). I just explicitly mentioned the
platforms that use PCSClite given the context of this mailing list.

Right now it's in an API proposal phase, but the intent is to have it
in Chrome[1]. Its prototyping phase hasn't started, thus no code to
look at yet.

Regarding card reader identification, I wasn't aware of the
possibility of getting USB vendor and product ids via
FEATURE_GET_TLV_PROPERTIES. Thanks for pointing that out. Will update
the proposal appropriately. Although that seems to not change the fact
that one still cannot reliably identify a reader with PC/SC given
that, as you said, this depends on the driver supporting/implementing
this and apparently that might not be the case on Windows (will
check).

Like CardContact's Scripting Server, I wasn't aware of SConnect.
Thanks for that link.

[1] https://chromestatus.com/feature/6411735804674048

On Fri, Aug 12, 2022 at 3:26 PM Ludovic Rousseau
<ludovic.rousseau at gmail.com> wrote:
>
> Le ven. 12 ao?t 2022 ? 12:01, Daniel d'Andrada <dandrader at google.com> a ?crit :
> > Hi all,
>
> Hello Daniel,
>
> > I'm proposing a Web API for smart cards, at PC/SC level. It will give
> > a page access to the PC/SC implementation (and card reader drivers)
> > available in the host OS. Meaning PCSClite on Linux, macOS and
> > ChromeOS.
> >
> > It's hosted here:
> > https://github.com/dandrader/web-smart-card/blob/main/README.md
> > If interested, you can file bugs in that repo to discuss problems you see in it.
> >
> > I would appreciate the opinion of the PC/SC experts and users here.
>
> I note this API is much easier to use than the previous one for Chrome OS
> https://github.com/GoogleChromeLabs/chromeos_smart_card_connector
>
> It is possible to identify a PC/SC reader by asking the USB VendorID
> and ProductID.
> See "Identifying a reader model (part 2)"
> https://ludovicrousseau.blogspot.com/2012/04/identifying-reader-model-part-2.html
> It works with my CCID driver so, I think, not with Windows CCID driver.
>
> You do not target Windows. There is a technical reason?
>
> Also I do not see any source code. Maybe it is just a API proposal
> with no code available yet?
>
> I already know SConnect for a similar software. But SConnect is not
> Free Software
> https://www.sconnect.com/faqs/#compatibility
>
> Regards,
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From dandrader at google.com  Fri Aug 12 09:15:19 2022
From: dandrader at google.com (Daniel d'Andrada)
Date: Fri, 12 Aug 2022 18:15:19 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <VE1P192MB0701C3FC812755A845B364EBA6679@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
 <4e907620-4a8d-25e2-aac2-5231df2e1087@cardcontact.de> <VE1P192MB0701C3FC812755A845B364EBA6679@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
Message-ID: <CA+enBd9fsBhNp0Fae4psif8rgVjrffSrhHqU3mKQqTpFKJc_Ag@mail.gmail.com>

Hi Antoine,

I wasn't aware of this Secure Element Web API proposal. Quite
interesting. Thanks for the context.

On Fri, Aug 12, 2022 at 3:01 PM Antoine FERRON <aferron at cardhoc.com> wrote:
>
> I know there was a failed attempt to do very similar things.
> Here's an official GP proposal :
> http://globalplatform.github.io/WebApis-for-SE/doc/
>
> Also Gemalto pushed years ago in this direction to add SC in the web world. https://www.w3.org/2015/06/secure_elements.pptx But the challenges were not solved, mostly because of a lack of interest from the W3C and web browsers editors.
>
> W3C is now developing a FileAPI for the horror of security guy like me. But I still don't feel the mood to be interested to add smartcards.
>
> Interesting ways to make a direct use of a smartcard from the web in practice (but rather hacky) are :
> Use FIDO2 API to exchange message to a FIDO2 authr.
> The native engine such as Windows CNG GIDS. So the cryptography web API see a service provider and can use an underlying smart card.
>
> AF
>
> -----Original Message-----
> From: pcsclite-muscle <pcsclite-muscle-bounces at lists.infradead.org> On Behalf Of Andreas Schwier
> Sent: 12 August 2022 12:14
> To: pcsclite-muscle at lists.infradead.org
> Subject: Re: [Pcsclite-muscle] Proposal for a Web API for smart cards
>
> Hi Daniel,
>
> having such an API would be a great thing. Right now we need additional applications on the host to integrate with smart cards in a web application [1].
>
> My feeling so far was, that browser manufacturer didn't want to integrate with client side hardware.
>
> Has that changed and who is driving this ?
>
> Andreas
>
> [1] https://www.openscdp.org/scriptingserver/remoteterminal.html
>
> On 12.08.22 12:00, Daniel d'Andrada wrote:
> > Hi all,
> >
> > I'm proposing a Web API for smart cards, at PC/SC level. It will give
> > a page access to the PC/SC implementation (and card reader drivers)
> > available in the host OS. Meaning PCSClite on Linux, macOS and
> > ChromeOS.
> >
> > It's hosted here:
> > https://github.com/dandrader/web-smart-card/blob/main/README.md
> > If interested, you can file bugs in that repo to discuss problems you see in it.
> >
> > I would appreciate the opinion of the PC/SC experts and users here.
> >
> > Best regards,
> > Daniel
> >
> > _______________________________________________
> > pcsclite-muscle mailing list
> > mailto:pcsclite-muscle at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>
> --
>      ---------    CardContact Systems GmbH
>     |.##> <##.|   Sch?lerweg 38
>     |#       #|   D-32429 Minden, Germany
>     |#       #|   Phone +49 571 56149
>     |'##> <##'|   http://www.cardcontact.de
>      ---------    Registergericht Bad Oeynhausen HRB 14880
>                   Gesch?ftsf?hrer Andreas Schwier
>
> _______________________________________________
> pcsclite-muscle mailing list
> mailto:pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From ludovic.rousseau at gmail.com  Sat Aug 13 06:24:53 2022
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Sat, 13 Aug 2022 15:24:53 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <CA+enBd-7-qQxcjDXhoUOvaGth+=c=VPdY_yjzTQSd4bAJQK84w@mail.gmail.com>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
 <CAGstE8BR7bnpVt0298v22+FAtt4dSAZy_SrPNpx7q-5GPw+F8A@mail.gmail.com> <CA+enBd-7-qQxcjDXhoUOvaGth+=c=VPdY_yjzTQSd4bAJQK84w@mail.gmail.com>
Message-ID: <CAGstE8CrZqnG2ZLNgfL=ObbXtXjCiqNRE4ZUHS1ierJ+oWstcw@mail.gmail.com>

Hello Daniel,

Le ven. 12 ao?t 2022 ? 17:44, Daniel d'Andrada <dandrader at google.com> a ?crit :
> [1] https://chromestatus.com/feature/6411735804674048

>From the web page above:
"Motivation

Smart cards are popular in the enterprise and governmental sectors. A
governmental website could identify a citizen by communicating with a
government-issued smart ID card inserted in a card reader without the
need of external, native, applications. Similarly, an enterprise that
issues smart cards to their employees could authenticate them in its
corporate website using the employee's card inserted in a smart card
reader needing only the browser itself."

This is what PKCS#11 is used for. You can do a client web
authentication using your employee badge.

Do you plan to (re)implement a PKCS#11 library equivalent (something
like OpenSC) in JavaScript in the web page?

What are the problems with the "external, native, applications"?

Regards,

-- 
 Dr. Ludovic Rousseau


From mstjohns at comcast.net  Mon Aug 15 14:11:35 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 15 Aug 2022 17:11:35 -0400
Subject: [Pcsclite-muscle] Know the interface connection type with a card
In-Reply-To: <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
References: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
Message-ID: <fe23ce31-df35-6e3d-055d-8c52d5943bc3@comcast.net>

On 8/11/2022 10:31 AM, Antoine FERRON wrote:
> Dear smartcard friends,
>
> I'm writing here since the PyScard developer recommended to do so to get a broader audience for my question. It is not strictly about the pcsc-lite system, but more about PyScard.
>
> Using pyscard, I recently spent some time trying to build a detection method in smartcards handling library to know whether the card connection is through contactless or with contacts. And so far, I didn't find any reliable method to get this information. This is needed as some cards behave differently depending of the access interface, mostly because internally the applet knows which interface is currently used, and can act accordingly. Also, some standards like EMV instruct to behave differently depending of the access interface. All that makes the need for knowing the access interface when talking to a smartcard.
> My idea is to have in the Python card object a is_contactless attribute which is true when the connection is done through the wireless interface. How can it be done ? On Windows ? On Mac ? On Linux? Our main and first target is Windows, and I feel this is an actual issue in Windows. As the Win Scard interface doesn't seem to offer any way to read this. Hence my question, I maybe missed one thing to get this info.
> I have to say the method should not rely on a specific applet, but should be universal to provide the type of access connection in use to talk with the card (RF contactless or wires contact).
>
> Thanks,
> AF
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle

SCardGetAttrib with SCARD_ATTR_CURRENT_PROTOCOL_TYPE should get you what 
you want...

Mike




From mstjohns at comcast.net  Mon Aug 15 19:02:12 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 15 Aug 2022 22:02:12 -0400
Subject: [Pcsclite-muscle] Know the interface connection type with a card
In-Reply-To: <fe23ce31-df35-6e3d-055d-8c52d5943bc3@comcast.net>
References: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <fe23ce31-df35-6e3d-055d-8c52d5943bc3@comcast.net>
Message-ID: <b8415038-2a3c-4064-6069-5e2262f674b2@comcast.net>

On 8/15/2022 5:11 PM, Michael StJohns wrote:
> On 8/11/2022 10:31 AM, Antoine FERRON wrote:
>> Dear smartcard friends,
>>
>> I'm writing here since the PyScard developer recommended to do so to 
>> get a broader audience for my question. It is not strictly about the 
>> pcsc-lite system, but more about PyScard.
>>
>> Using pyscard, I recently spent some time trying to build a detection 
>> method in smartcards handling library to know whether the card 
>> connection is through contactless or with contacts. And so far, I 
>> didn't find any reliable method to get this information. This is 
>> needed as some cards behave differently depending of the access 
>> interface, mostly because internally the applet knows which interface 
>> is currently used, and can act accordingly. Also, some standards like 
>> EMV instruct to behave differently depending of the access interface. 
>> All that makes the need for knowing the access interface when talking 
>> to a smartcard.
>> My idea is to have in the Python card object a is_contactless 
>> attribute which is true when the connection is done through the 
>> wireless interface. How can it be done ? On Windows ? On Mac ? On 
>> Linux? Our main and first target is Windows, and I feel this is an 
>> actual issue in Windows. As the Win Scard interface doesn't seem to 
>> offer any way to read this. Hence my question, I maybe missed one 
>> thing to get this info.
>> I have to say the method should not rely on a specific applet, but 
>> should be universal to provide the type of access connection in use 
>> to talk with the card (RF contactless or wires contact).
>>
>> Thanks,
>> AF
>>
>> _______________________________________________
>> pcsclite-muscle mailing list
>> pcsclite-muscle at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>
> SCardGetAttrib with SCARD_ATTR_CURRENT_PROTOCOL_TYPE should get you 
> what you want...
>
> Mike
>
>
Sorry - forgot to mention that T=CL is probably encoded as T=15

Mike




From aferron at cardhoc.com  Tue Aug 16 03:52:00 2022
From: aferron at cardhoc.com (Antoine FERRON)
Date: Tue, 16 Aug 2022 10:52:00 +0000
Subject: [Pcsclite-muscle] Know the interface connection type with a card
In-Reply-To: <b8415038-2a3c-4064-6069-5e2262f674b2@comcast.net>
References: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <fe23ce31-df35-6e3d-055d-8c52d5943bc3@comcast.net>
 <b8415038-2a3c-4064-6069-5e2262f674b2@comcast.net>
Message-ID: <VE1P192MB0701C7940B3B0DC36F9D8A78A66B9@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>

> SCardGetAttrib with SCARD_ATTR_CURRENT_PROTOCOL_TYPE should get you 
> what you want...
> Forgot to mention that T=CL is probably encoded as T=15

Well, I tried similar things, and this provides always 1, 2 or 3 (T0, T1, T0/T1), at least on Windows. It never provides 8 nor 15 value. Maybe in Linux ?
For now, I'm using pyscard connection.getProtocol(), and this is the same? This reads SCARD_ATTR_CURRENT_PROTOCOL_TYPE ? You think SCARD_ATTR_CURRENT_PROTOCOL_TYPE will provide a different value from connection.getProtocol() ? That will provide 8 or 15 on Windows? To me, the Winscard interface never tells you about contactless protocol used.


-----Original Message-----
From: pcsclite-muscle <pcsclite-muscle-bounces at lists.infradead.org> On Behalf Of Michael StJohns
Sent: 16 August 2022 04:02
To: pcsclite-muscle at lists.infradead.org
Subject: Re: [Pcsclite-muscle] Know the interface connection type with a card

On 8/15/2022 5:11 PM, Michael StJohns wrote:
> On 8/11/2022 10:31 AM, Antoine FERRON wrote:
>> Dear smartcard friends,
>>
>> I'm writing here since the PyScard developer recommended to do so to 
>> get a broader audience for my question. It is not strictly about the 
>> pcsc-lite system, but more about PyScard.
>>
>> Using pyscard, I recently spent some time trying to build a detection 
>> method in smartcards handling library to know whether the card 
>> connection is through contactless or with contacts. And so far, I 
>> didn't find any reliable method to get this information. This is 
>> needed as some cards behave differently depending of the access 
>> interface, mostly because internally the applet knows which interface 
>> is currently used, and can act accordingly. Also, some standards like 
>> EMV instruct to behave differently depending of the access interface.
>> All that makes the need for knowing the access interface when talking 
>> to a smartcard.
>> My idea is to have in the Python card object a is_contactless 
>> attribute which is true when the connection is done through the 
>> wireless interface. How can it be done ? On Windows ? On Mac ? On 
>> Linux? Our main and first target is Windows, and I feel this is an 
>> actual issue in Windows. As the Win Scard interface doesn't seem to 
>> offer any way to read this. Hence my question, I maybe missed one 
>> thing to get this info.
>> I have to say the method should not rely on a specific applet, but 
>> should be universal to provide the type of access connection in use 
>> to talk with the card (RF contactless or wires contact).
>>
>> Thanks,
>> AF
>>
>> _______________________________________________
>> pcsclite-muscle mailing list
>> pcsclite-muscle at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>
> SCardGetAttrib with SCARD_ATTR_CURRENT_PROTOCOL_TYPE should get you 
> what you want...
>
> Mike
>
>
Sorry - forgot to mention that T=CL is probably encoded as T=15

Mike



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


From dandrader at google.com  Wed Aug 17 09:35:06 2022
From: dandrader at google.com (Daniel d'Andrada)
Date: Wed, 17 Aug 2022 18:35:06 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <CAGstE8CrZqnG2ZLNgfL=ObbXtXjCiqNRE4ZUHS1ierJ+oWstcw@mail.gmail.com>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
 <CAGstE8BR7bnpVt0298v22+FAtt4dSAZy_SrPNpx7q-5GPw+F8A@mail.gmail.com>
 <CA+enBd-7-qQxcjDXhoUOvaGth+=c=VPdY_yjzTQSd4bAJQK84w@mail.gmail.com> <CAGstE8CrZqnG2ZLNgfL=ObbXtXjCiqNRE4ZUHS1ierJ+oWstcw@mail.gmail.com>
Message-ID: <CA+enBd_wpidx5y6_QHZO=De34rg--p2=AQrjgY3o9aEWKS8z9A@mail.gmail.com>

Hi Ludovic,

The idea is to enable applications that rely specifically on PC/SC to
be delivered as web apps instead of native apps.

The AusweisApp2[1] for instance uses APDUs and sends control commands
to tell the reader device to establish a PACE channel with the card.
It also sends another control command to detect if the reader at hand
declares PACE support in the first place, because otherwise it
implements PACE directly in the host. And then you have the browser
talking to this app. That API would enable AusweisApp2 to be a web app
for instance.

Another example is remote access (or "remote desktop") applications.
They can enable the remote system, and the applications in that remote
system, to transparently access the card reader in the computer that
is running that remote access app. That also requires PC/SC API level.

Or a web-based kiosk with a card reader that reads RFID tags/badges
and changes its Web UI accordingly.

[1] https://www.ausweisapp.bund.de/en/home





On Sat, Aug 13, 2022 at 3:25 PM Ludovic Rousseau
<ludovic.rousseau at gmail.com> wrote:
>
> Hello Daniel,
>
> Le ven. 12 ao?t 2022 ? 17:44, Daniel d'Andrada <dandrader at google.com> a ?crit :
> > [1] https://chromestatus.com/feature/6411735804674048
>
> From the web page above:
> "Motivation
>
> Smart cards are popular in the enterprise and governmental sectors. A
> governmental website could identify a citizen by communicating with a
> government-issued smart ID card inserted in a card reader without the
> need of external, native, applications. Similarly, an enterprise that
> issues smart cards to their employees could authenticate them in its
> corporate website using the employee's card inserted in a smart card
> reader needing only the browser itself."
>
> This is what PKCS#11 is used for. You can do a client web
> authentication using your employee badge.
>
> Do you plan to (re)implement a PKCS#11 library equivalent (something
> like OpenSC) in JavaScript in the web page?
>
> What are the problems with the "external, native, applications"?
>
> Regards,
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From ludovic.rousseau at gmail.com  Sat Aug 20 07:08:07 2022
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Sat, 20 Aug 2022 16:08:07 +0200
Subject: [Pcsclite-muscle] Change the error code when PC/SC access is
 refused by polkit?
In-Reply-To: <CAH=wB8y2wEHGu6ZiamRcm09tMnYra1LC43osHsJ_R4uNi1Njug@mail.gmail.com>
References: <CAGstE8CH-bVuDVf=81XuXw8DWCWUL9p-+YGtrm44qWKvTvOWHA@mail.gmail.com>
 <CAH=wB8y2wEHGu6ZiamRcm09tMnYra1LC43osHsJ_R4uNi1Njug@mail.gmail.com>
Message-ID: <CAGstE8CuBcaTdyNGY1pT+1SjhVK0rC8LJjZJURxqcovo3dKGhg@mail.gmail.com>

Hello,

Thanks Martin and Maksim for your comments.

I implemented the change in
https://github.com/LudovicRousseau/PCSC/commit/68f629ffecaec3886c717021e70ac62c22b38bd8
and https://github.com/LudovicRousseau/PCSC/commit/1935b6997b281f0d836b829b4cfeeab6c81c3ded

You can get a snapshot of pcsc-lite from
http://ludovic.rousseau.free.fr/softwares/pcsc-lite/pcsc-lite-1.9.8-1935b69.tar.bz2
Please test it, in particular if you use Polkit (i.e. RedHat or Fedora).

Regards,

Le jeu. 11 ao?t 2022 ? 14:04, Maksim Ivanov <emaxx at google.com> a ?crit :
>
> Hi,
>
> Just my 2 cents: the "SCARD_W_SECURITY_VIOLATION" error code sounds like a reasonable reply for the "NOT authorized for action" error.
>
>
> Regards,
> Maksim
>
>
> On Fri, Jul 29, 2022 at 4:33 PM Ludovic Rousseau <ludovic.rousseau at gmail.com> wrote:
>>
>> Hello,
>>
>> I am using PC/SC on CentOS/RedHat and I am often surprised when I get the error:
>> $ pcsc_scan
>> SCardEstablishContext: RPC transport error.
>>
>> The error code is SCARD_F_COMM_ERROR
>> https://pcsclite.apdu.fr/api/group__ErrorCodes.html#ga93d3cf468d69423eab1d478a7a870408
>>
>> From the pcscd logs I see:
>> 00000003 [139737213696960] pcscdaemon.c:133:SVCServiceRunLoop() A new
>> context thread creation is requested: 10
>> 00019807 [139737012623104] auth.c:139:IsClientAuthorized() Process
>> 41685 (user: 1000) is NOT authorized for action: access_pcsc
>> 00000107 [139737012623104] winscard_svc.c:335:ContextThread() Rejected
>> unauthorized PC/SC client
>>
>> So I get SCARD_F_COMM_ERROR because auth.c (in fact polkit) decided I
>> should not have access to PC/SC.
>> For example this happens when I connect to the computer using ssh, and
>> not from the console.
>>
>> The error is even more confusing if you enable logs in the client:
>> $ PCSCLITE_DEBUG=0 pcsc_scan
>> winscard_clnt.c:605:SCardEstablishContextTH() Your pcscd is too old
>> and does not support CMD_VERSION
>> SCardEstablishContext: RPC transport error.
>>
>> The problem is NOT that pcscd is too old :-)
>>
>>
>> I was thinking: maybe a more explicit error code would be better?
>> Maybe SCARD_E_SYSTEM_CANCELLED or SCARD_W_SECURITY_VIOLATION
>>
>> I do not want to invent a new WinSCard return value.
>> We should use one form the list
>> https://docs.microsoft.com/en-us/windows/win32/secauthn/authentication-return-values
>>
>> I don't know if it is easy to implement. When polkit refuses the
>> connection the pcscd server just closes the socket without sending
>> *anything* to the client.
>>
>> Any comment?
>>
>> Regards,
>>
>> --
>>  Dr. Ludovic Rousseau
>>
>> _______________________________________________
>> pcsclite-muscle mailing list
>> pcsclite-muscle at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>
>


-- 
 Dr. Ludovic Rousseau


From ludovic.rousseau at gmail.com  Wed Aug 24 09:08:29 2022
From: ludovic.rousseau at gmail.com (Ludovic Rousseau)
Date: Wed, 24 Aug 2022 18:08:29 +0200
Subject: [Pcsclite-muscle] Know the interface connection type with a card
In-Reply-To: <VE1P192MB0701C7940B3B0DC36F9D8A78A66B9@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
References: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <fe23ce31-df35-6e3d-055d-8c52d5943bc3@comcast.net> <b8415038-2a3c-4064-6069-5e2262f674b2@comcast.net>
 <VE1P192MB0701C7940B3B0DC36F9D8A78A66B9@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
Message-ID: <CAGstE8BO3wuUXc+UY9z8nvysqK_DXkTeqiM7V9xUjZNECYAVNw@mail.gmail.com>

Le mar. 16 ao?t 2022 ? 12:53, Antoine FERRON <aferron at cardhoc.com> a ?crit :
>
> > SCardGetAttrib with SCARD_ATTR_CURRENT_PROTOCOL_TYPE should get you
> > what you want...
> > Forgot to mention that T=CL is probably encoded as T=15
>
> Well, I tried similar things, and this provides always 1, 2 or 3 (T0, T1, T0/T1), at least on Windows. It never provides 8 nor 15 value. Maybe in Linux ?
> For now, I'm using pyscard connection.getProtocol(), and this is the same? This reads SCARD_ATTR_CURRENT_PROTOCOL_TYPE ? You think SCARD_ATTR_CURRENT_PROTOCOL_TYPE will provide a different value from connection.getProtocol() ? That will provide 8 or 15 on Windows? To me, the Winscard interface never tells you about contactless protocol used.

connection.getProtocol() will not return what you want.
Use something like attrib =
card_connection.getAttrib(SCARD_ATTR_CURRENT_PROTOCOL_TYPE)

See https://ludovicrousseau.blogspot.com/2020/04/scardattrchannelid-and-usb-devices.html

Bye

-- 
 Dr. Ludovic Rousseau


From sebastien at lorquet.fr  Thu Aug 25 01:35:46 2022
From: sebastien at lorquet.fr (Sebastien Lorquet)
Date: Thu, 25 Aug 2022 10:35:46 +0200
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <CA+enBd_wpidx5y6_QHZO=De34rg--p2=AQrjgY3o9aEWKS8z9A@mail.gmail.com>
References: <CA+enBd80rjxH02viTzBJQd74VahbBPodM+diWJQ5wpiUpyvBtg@mail.gmail.com>
 <CAGstE8BR7bnpVt0298v22+FAtt4dSAZy_SrPNpx7q-5GPw+F8A@mail.gmail.com>
 <CA+enBd-7-qQxcjDXhoUOvaGth+=c=VPdY_yjzTQSd4bAJQK84w@mail.gmail.com>
 <CAGstE8CrZqnG2ZLNgfL=ObbXtXjCiqNRE4ZUHS1ierJ+oWstcw@mail.gmail.com>
 <CA+enBd_wpidx5y6_QHZO=De34rg--p2=AQrjgY3o9aEWKS8z9A@mail.gmail.com>
Message-ID: <b0db4613-5cb6-ccc6-85f2-770c1c62d5b6@lorquet.fr>

Hi Daniel,

Your API feels like a very good idea (GP and PKCS11 are too applicative) 
and would be useful for us, we are stuck with a proprietary activeX 
running in Edge in IE mode)

However it feels a bit like XKCD #927...

It would be good however if such an API managed to enter the mainline 
browsers or be implementable with simple plugins that would work across 
all OSes and browsers. In particular Firefox (and chrome) on Windows, 
which are probably the largest market share.

Sebastien

Le 17/08/2022 ? 18:35, Daniel d'Andrada a ?crit?:
> Hi Ludovic,
>
> The idea is to enable applications that rely specifically on PC/SC to
> be delivered as web apps instead of native apps.
>
> The AusweisApp2[1] for instance uses APDUs and sends control commands
> to tell the reader device to establish a PACE channel with the card.
> It also sends another control command to detect if the reader at hand
> declares PACE support in the first place, because otherwise it
> implements PACE directly in the host. And then you have the browser
> talking to this app. That API would enable AusweisApp2 to be a web app
> for instance.
>
> Another example is remote access (or "remote desktop") applications.
> They can enable the remote system, and the applications in that remote
> system, to transparently access the card reader in the computer that
> is running that remote access app. That also requires PC/SC API level.
>
> Or a web-based kiosk with a card reader that reads RFID tags/badges
> and changes its Web UI accordingly.
>
> [1] https://www.ausweisapp.bund.de/en/home
>
>
>
>
>
> On Sat, Aug 13, 2022 at 3:25 PM Ludovic Rousseau
> <ludovic.rousseau at gmail.com> wrote:
>> Hello Daniel,
>>
>> Le ven. 12 ao?t 2022 ? 17:44, Daniel d'Andrada <dandrader at google.com> a ?crit :
>>> [1] https://chromestatus.com/feature/6411735804674048
>>  From the web page above:
>> "Motivation
>>
>> Smart cards are popular in the enterprise and governmental sectors. A
>> governmental website could identify a citizen by communicating with a
>> government-issued smart ID card inserted in a card reader without the
>> need of external, native, applications. Similarly, an enterprise that
>> issues smart cards to their employees could authenticate them in its
>> corporate website using the employee's card inserted in a smart card
>> reader needing only the browser itself."
>>
>> This is what PKCS#11 is used for. You can do a client web
>> authentication using your employee badge.
>>
>> Do you plan to (re)implement a PKCS#11 library equivalent (something
>> like OpenSC) in JavaScript in the web page?
>>
>> What are the problems with the "external, native, applications"?
>>
>> Regards,
>>
>> --
>>   Dr. Ludovic Rousseau
>>
>> _______________________________________________
>> pcsclite-muscle mailing list
>> pcsclite-muscle at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From martin at martinpaljak.net  Thu Aug 25 07:37:46 2022
From: martin at martinpaljak.net (Martin Paljak)
Date: Thu, 25 Aug 2022 17:37:46 +0300
Subject: [Pcsclite-muscle] Proposal for a Web API for smart cards
In-Reply-To: <b0db4613-5cb6-ccc6-85f2-770c1c62d5b6@lorquet.fr>
References: <b0db4613-5cb6-ccc6-85f2-770c1c62d5b6@lorquet.fr>
Message-ID: <A30DD8C3-1A84-4886-866E-29AFABE46E71@martinpaljak.net>

Could be that the issue was ?solved? from browser perspective with the introduction of native messaging extensions. This solves it for desktop browsers, at least. If there is some kind of ?harmonization? inside the industry for a specific javascript API - even better. The use case is _very_ niche. From browser perspective - it _is_ possible to talk to smart card readers with the help of webextensions and native messaging, so case closed.

Where standardization _would_ make sense is mobile browsers, but that is a very long road and nothing that resembles pcsc makes sense in that world.

There are specific interfaces that get exposed - FIDO/CTAP, NDEF. Seems like asking for a block device access API, when use cases revolve around file abstraction.

Web-nfc has actually evolved somewhere, but even that deals with ?files? rather than pipes/disk blocks, and for a good reason (and I personally don?t believe it is a viable thing).

For future I?d rather start working with UWB sector-specific standards and relevant API-s that could be exposed on (mobile) browsers?

Best,
Martin

> On 25. Aug 2022, at 11:39, Sebastien Lorquet <sebastien at lorquet.fr> wrote:
> 
> ?Hi Daniel,
> 
> Your API feels like a very good idea (GP and PKCS11 are too applicative) and would be useful for us, we are stuck with a proprietary activeX running in Edge in IE mode)
> 
> However it feels a bit like XKCD #927...
> 
> It would be good however if such an API managed to enter the mainline browsers or be implementable with simple plugins that would work across all OSes and browsers. In particular Firefox (and chrome) on Windows, which are probably the largest market share.
> 
> Sebastien
> 
>> Le 17/08/2022 ? 18:35, Daniel d'Andrada a ?crit :
>> Hi Ludovic,
>> 
>> The idea is to enable applications that rely specifically on PC/SC to
>> be delivered as web apps instead of native apps.
>> 
>> The AusweisApp2[1] for instance uses APDUs and sends control commands
>> to tell the reader device to establish a PACE channel with the card.
>> It also sends another control command to detect if the reader at hand
>> declares PACE support in the first place, because otherwise it
>> implements PACE directly in the host. And then you have the browser
>> talking to this app. That API would enable AusweisApp2 to be a web app
>> for instance.
>> 
>> Another example is remote access (or "remote desktop") applications.
>> They can enable the remote system, and the applications in that remote
>> system, to transparently access the card reader in the computer that
>> is running that remote access app. That also requires PC/SC API level.
>> 
>> Or a web-based kiosk with a card reader that reads RFID tags/badges
>> and changes its Web UI accordingly.
>> 
>> [1] https://www.ausweisapp.bund.de/en/home
>> 
>> 
>> 
>> 
>> 
>>> On Sat, Aug 13, 2022 at 3:25 PM Ludovic Rousseau
>>> <ludovic.rousseau at gmail.com> wrote:
>>> Hello Daniel,
>>> 
>>> Le ven. 12 ao?t 2022 ? 17:44, Daniel d'Andrada <dandrader at google.com> a ?crit :
>>>> [1] https://chromestatus.com/feature/6411735804674048
>>> From the web page above:
>>> "Motivation
>>> 
>>> Smart cards are popular in the enterprise and governmental sectors. A
>>> governmental website could identify a citizen by communicating with a
>>> government-issued smart ID card inserted in a card reader without the
>>> need of external, native, applications. Similarly, an enterprise that
>>> issues smart cards to their employees could authenticate them in its
>>> corporate website using the employee's card inserted in a smart card
>>> reader needing only the browser itself."
>>> 
>>> This is what PKCS#11 is used for. You can do a client web
>>> authentication using your employee badge.
>>> 
>>> Do you plan to (re)implement a PKCS#11 library equivalent (something
>>> like OpenSC) in JavaScript in the web page?
>>> 
>>> What are the problems with the "external, native, applications"?
>>> 
>>> Regards,
>>> 
>>> --
>>> Dr. Ludovic Rousseau
>>> 
>>> _______________________________________________
>>> pcsclite-muscle mailing list
>>> pcsclite-muscle at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
>> _______________________________________________
>> pcsclite-muscle mailing list
>> pcsclite-muscle at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle
> 
> _______________________________________________
> pcsclite-muscle mailing list
> pcsclite-muscle at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/pcsclite-muscle


From aferron at cardhoc.com  Thu Aug 25 13:58:46 2022
From: aferron at cardhoc.com (Antoine FERRON)
Date: Thu, 25 Aug 2022 20:58:46 +0000
Subject: [Pcsclite-muscle] Know the interface connection type with a card
In-Reply-To: <CAGstE8BO3wuUXc+UY9z8nvysqK_DXkTeqiM7V9xUjZNECYAVNw@mail.gmail.com>
References: <VE1P192MB0701E377CFE6F34042CBD250A6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <VE1P192MB07018F1BC8DB338D29DC11AEA6649@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <fe23ce31-df35-6e3d-055d-8c52d5943bc3@comcast.net>
 <b8415038-2a3c-4064-6069-5e2262f674b2@comcast.net>
 <VE1P192MB0701C7940B3B0DC36F9D8A78A66B9@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>
 <CAGstE8BO3wuUXc+UY9z8nvysqK_DXkTeqiM7V9xUjZNECYAVNw@mail.gmail.com>
Message-ID: <VE1P192MB07013B2A5F00052A6EF9612DA6729@VE1P192MB0701.EURP192.PROD.OUTLOOK.COM>

Thanks, I have tried what you suggest. And as I was afraid of, in Windows this never gives you a hint of the interface type. One can't know using SCARD_ATTR_CURRENT_PROTOCOL_TYPE if this is contact or not.

Here's an example, in Windows :
connection.getAttrib(SCARD_ATTR_CURRENT_PROTOCOL_TYPE)
Contact interface :
[2, 0, 0, 0]
Contactless interface :
[2, 0, 0, 0]
No difference at all. This can't be used as a discriminator whether we talk to a smartcard using the contact or the wireless interface, at least in Windows. And this is pretty much the heart of my initial question, how can I know in a reliable and easy way.  Now, I think that this is not possible.
So far, in our software, I combine various heuristic information, to estimate whether this is a contact connection or not. This is pretty reliable to tell the interface type, still quite complex and long to do it.

Regards, AF

-----Original Message-----
From: pcsclite-muscle <pcsclite-muscle-bounces at lists.infradead.org> On Behalf Of Ludovic Rousseau
Sent: 24 August 2022 18:08
To: pcsclite-muscle at lists.infradead.org
Subject: Re: [Pcsclite-muscle] Know the interface connection type with a card

Le mar. 16 ao?t 2022 ? 12:53, Antoine FERRON <aferron at cardhoc.com> a ?crit :
>
> > SCardGetAttrib with SCARD_ATTR_CURRENT_PROTOCOL_TYPE should get you 
> > what you want...
> > Forgot to mention that T=CL is probably encoded as T=15
>
> Well, I tried similar things, and this provides always 1, 2 or 3 (T0, T1, T0/T1), at least on Windows. It never provides 8 nor 15 value. Maybe in Linux ?
> For now, I'm using pyscard connection.getProtocol(), and this is the same? This reads SCARD_ATTR_CURRENT_PROTOCOL_TYPE ? You think SCARD_ATTR_CURRENT_PROTOCOL_TYPE will provide a different value from connection.getProtocol() ? That will provide 8 or 15 on Windows? To me, the Winscard interface never tells you about contactless protocol used.

connection.getProtocol() will not return what you want.
Use something like attrib =
card_connection.getAttrib(SCARD_ATTR_CURRENT_PROTOCOL_TYPE)

See https://ludovicrousseau.blogspot.com/2020/04/scardattrchannelid-and-usb-devices.html

Bye

--
 Dr. Ludovic Rousseau

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

