Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
Just to sum up: -TPM (fail?) -Intel IPT (seem to be a draft and only for intel?) -SC (Welcome 1970) -Virtual/Cloud wallets (obscure?) -A mobile device to replace sc (standard?) IMHO, SC are old enough/well known to continue existing for quite long, until someone brings a new/better/big idea. Also, considering how governments are involved in technology, probably many countries will adopt them, like eID, DNIe, and so in the next years. In 1024bit mode, of course. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
On Wed, Sep 5, 2012 at 12:57 PM, helpcrypto helpcrypto helpcry...@gmail.com wrote: Also, considering how governments are involved in technology, probably many countries will adopt them, like eID, DNIe, and so in the next years. In 1024bit mode, of course. Huh, I'd guess (hope) nobody would be deploying *RSA* below 2048 bits (smart cards doing 3k and 4k are also slowly emerging) and elliptic curves are already becoming a viable option (in commodity software) as well.. There's also a bunch of applications and use cases where the new age vision of wave your phone around is not a good idea (for example I'd better avoid taking my smartphone out unless I want/have to, and using crowded public transport is not one of the places I'd like to do it...) And IMHO device-attached containers (TPM, Intel etc) are totally different from transportable key-containers (like smart cards or USB tokens) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
Huh, I'd guess (hope) nobody would be deploying *RSA* below 2048 bits (smart cards doing 3k and 4k are also slowly emerging) and elliptic curves are already becoming a viable option (in commodity software) as well.. The most advanced i have seen here so far is 2048 :P There's also a bunch of applications and use cases where the new age vision of wave your phone around is not a good idea (for example I'd better avoid taking my smartphone out unless I want/have to, and using crowded public transport is not one of the places I'd like to do it...) And IMHO device-attached containers (TPM, Intel etc) are totally different from transportable key-containers (like smart cards or USB tokens) So, IYHO, whats the better option? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
-Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of helpcrypto helpcrypto Sent: Wednesday, September 05, 2012 1:29 PM To: opensc-devel@lists.opensc-project.org Subject: Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card Huh, I'd guess (hope) nobody would be deploying *RSA* below 2048 bits (smart cards doing 3k and 4k are also slowly emerging) and elliptic curves are already becoming a viable option (in commodity software) as well.. The most advanced i have seen here so far is 2048 :P They (4K, ECC) are there for a couple of years, see: http://www.infineon.com/dgdl/Infineon+Chip+Card+and+Security+ICs+Portfolio-Overview_neu.pdf?folderId=db3a3043243b5f170124a48543c040a0fileId=db3a3043243b5f170124a4898a2440a4 __ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
On 2012-09-05 13:29, helpcrypto helpcrypto wrote: Huh, I'd guess (hope) nobody would be deploying *RSA* below 2048 bits (smart cards doing 3k and 4k are also slowly emerging) and elliptic curves are already becoming a viable option (in commodity software) as well.. The most advanced i have seen here so far is 2048 :P There's also a bunch of applications and use cases where the new age vision of wave your phone around is not a good idea (for example I'd better avoid taking my smartphone out unless I want/have to, and using crowded public transport is not one of the places I'd like to do it...) And IMHO device-attached containers (TPM, Intel etc) are totally different from transportable key-containers (like smart cards or USB tokens) So, IYHO, whats the better option? As I wrote, the majority of eIDs will be used as secure bootstrap of credential clones so there really is no option here although BSI probably claims something else. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
On Wed, Sep 5, 2012 at 2:29 PM, helpcrypto helpcrypto helpcry...@gmail.com wrote: And IMHO device-attached containers (TPM, Intel etc) are totally different from transportable key-containers (like smart cards or USB tokens) So, IYHO, whats the better option? Do you want my Humble or Honest opinion ? :) It shall depend on the use case. I doubt that there will ever be a single, universal keychain, but many. VPN authentication with device based (TMP etc) keys which get auto-provisioned and a movable identity in the form of an eID smart card for digital signatures or cross-domain authentication have different requirements. Key containers for encryption is yet another story. And embedded keystores (phones, vpn devices, whatnot) that need a provisioning scheme is also quite obvious, with the smartphone scene creating the firsthand need for it. Martin As always, there's no golden bullet solution. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
Do you want my Humble or Honest opinion ? :) None. Hacker one :P It shall depend on the use case. I doubt that there will ever be a single, universal keychain, but many. VPN authentication with device based (TMP etc) keys which get auto-provisioned and a movable identity in the form of an eID smart card for digital signatures or cross-domain authentication have different requirements. Key containers for encryption is yet another story. And embedded keystores (phones, vpn devices, whatnot) that need a provisioning scheme is also quite obvious, with the smartphone scene creating the firsthand need for it. Martin As always, there's no golden bullet solution. I think the perfect solution will be DNA. In fact, i gave you the one-billion idea: A mouse/keyboard/device with a DNA sequencing/reader system which sends your public DNA profile. A simple way of matching your public DNA with your thoughts, memories and personality, to match both. As you can guess, that works as a keypair You develop it. For tomorrow. Free. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
Il 05/09/2012 13:29, helpcrypto helpcrypto ha scritto: The most advanced i have seen here so far is 2048 :P I bought (but haven't yet had time to experiment with) Cryptomate64: http://www.acs.com.hk/index.php?pid=productprod_sections=0id=CRYPTOMATE64 See my message dated 2012/05/23. Doesn't cost too much (less than 50€, and a lot is due to shipment). I'm even thinking about using a Raspberry PI to handle it and export functions via Ethernet. Another possible (and maybe WAY cheaper, in medium volumes) alternative would be to use a cut down Android phone (take one the cheapest one, remove or don't install radios, write a custom firmware and bootloader, and you'll have a cheap token that can handle RSA16384, EC, OTP even when disconnected from a PC, and pretty much everything you can think of). Non-stripped old smartphones are already quite cheap, way cheaper than any other comparable solution. And if you ask a supplier for a lot w/o radios they should come at bargain price... The SIM slot could easily host a crypto smartcard to unlock credentials stored in the device (on a microSD, maybe). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Supporting card Handelsbanken (SHB) BankID
Hello, On Tue, Aug 21, 2012 at 2:03 PM, Peter Åstrand astr...@cendio.se wrote: Hi! It would be nice if OpenSC could support cards from the Swedish bank Handelsbanken (SHB). This is a BankID type of cards. I've tried multiple versions of OpenSC and they all fail to communicate with the card, with one exception: We are using OpenSC 0.12.1 in our ThinLinc Client, loading the opensc-pkcs15 module. If you start the client first, then inserts the cards, the certificates are listed! However, this does require that the proprietary BankID application is installed on the machine (install.bankid.com). If you insert the card first, then start the ThinLinc Client, no certs are found. It seems to me that the BankID application somehow unlocks the card when it reads it, and during this window of time, our client with OpenSC can read the card as well. I've done a few logs with OPENSC_DEBUG=9. In the case when the certs are found, we get: card.c:322:sc_unlock: called iso7816.c:103:iso7816_check_sw: File not found iso7816.c:471:iso7816_select_file: returning with: -1201 (File not found) When no certs are found, we get: card.c:322:sc_unlock: called iso7816.c:103:iso7816_check_sw: Instruction code not supported or invalid iso7816.c:471:iso7816_select_file: returning with: -1204 (Unsupported INS byte in APDU) Any chance of having proper support for this card in OpenSC in the future? The error is not really useful by itself, please follow the ReportingBugs [1] page from the wiki to send useful logs (which driver, which card, which reader etc) What I suspect is that the application is not the default one on the card and the bankid software selects the right applet, after what OpenSC gets further than without the bank application installed. This is just a wild guess though... Martin [1] https://www.opensc-project.org/opensc/wiki/ReportingBugs ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SafeNet/Aladdin new eToken PRO (Java) - driver
I'm using it on Linux, but all I had to do was: pkcs11-tool --module libeToken.so.8 -l -O I don't know what the equivalent is on Mac OS X. Thanks, Peter On Tue, Sep 4, 2012 at 5:19 AM, Martin Čmelík martin.cme...@gmail.com wrote: Hi Peter, oh, really? I was playing with that 5 hours. Seems that I maybe somehow ruined official SafeNet libraries (but auth client works fine...). One more note: I'm using it on Mac OS Can you send me please your openssl and opensc settings? Something like described here in Testing with OpenSSL - http://www.opensc-project.org/opensc/wiki/QuickStart I read everywhere that Java cards are unusable with OpenSC. Did you initialize eToken with SafeNet Auth Client or pkcs15-init? Thank you very much! — Martin Čmelík 2012/9/4 Peter Bowen pzbo...@gmail.com: On Mon, Sep 3, 2012 at 9:54 AM, Martin Čmelík martin.cme...@gmail.com wrote: I would like to ask you if someone can help with drivers for new SafeNet eToken (Aladdin) 5100 (Java Card). Based on this http://www.opensc-project.org/opensc/wiki/AladdinEtokenPro it seems to be evolution version of eToken PRO (Java), more info here: http://www.safenet-inc.com/Products/Data_Protection/two-factor-authentication/SafeNet_eToken_5100/ Middle-ware communication works fine (pcscd -d -f -a) I'm also able to use SafeNet Authentication Client, but unable use pkcs11/15 tools at all. I've got this same card and have no problems with the SafeNet eToken PKCS#11 library with pkcs11-tool. However the OpenSC PKCS#11 library or PKCS#15 tools have issues. I haven't found a way to use the 5100 with only open source software. Thanks, Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SafeNet/Aladdin new eToken PRO (Java) - driver
Hello On Tue, Sep 4, 2012 at 3:19 PM, Martin Čmelík martin.cme...@gmail.com wrote: Hi Peter, oh, really? I was playing with that 5 hours. Seems that I maybe somehow ruined official SafeNet libraries (but auth client works fine...). One more note: I'm using it on Mac OS Can you send me please your openssl and opensc settings? Something like described here in Testing with OpenSSL - http://www.opensc-project.org/opensc/wiki/QuickStart I read everywhere that Java cards are unusable with OpenSC. Did you initialize eToken with SafeNet Auth Client or pkcs15-init? OpenSC does NOT support the Aladdin PKI applet. What you *can* do is sniff the APDU-s used with the Aladdin middleware with pcsc-spy for example and reverse-engineer a driver. I'd *hope* it would be something close to standards (whichever standards) thus you could re-use existing code and existing documentation. What are the chances of this being the case I don't have a clue. You could as well as SafeNet for card reference manual... Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Two back-to-back runs, different results
I am trying to debug an issue with the SCM 311 reader and Oberthur ID One card in order to better support Macs and smart card-enabled sites. I've been using pkcs15-tool to list certificates on the card. The result is that on the first run with the card inserted for the first time, certificates are listed. On the next, second run, no certificates are listed; pkcs15-tool reports no certificates. Turning up the debugging volume, I get the following unified diff output (/tmp/run-11 is the first run, /tmp/run-22 is the second run, timestamps stripped). On the first run, the card is detected as a T0 protocol card. On the second run, the card is detected as a T1 protocol card. I'm fairly certain this is a problem (listing certificates requires APDU messages, not TPDU messages, no?), but not sure where to go look in the code to propose a patch. (*) --- /tmp/run-11 2012-09-05 10:12:04.0 -0700 +++ /tmp/run-22 2012-09-05 10:12:08.0 -0700 @@ -21,7 +21,7 @@ reader-pcsc.c:325:refresh_attributes: current state: 0x0120 reader-pcsc.c:326:refresh_attributes: previous state: 0x0120 reader-pcsc.c:380:refresh_attributes: card present -reader-pcsc.c:497:pcsc_connect: Initial protocol: T0 protocol +reader-pcsc.c:497:pcsc_connect: Initial protocol: T1 protocol card.c:868:match_atr_table: ATR : 3b:db:96:00:80:1f:03:00:31:c0:64:b0:f3:10:00:07:90:00:80 card.c:879:match_atr_table: ATR try : 3B:DD:18:00:81:31:FE:45:80:F9:A0:00:00:00:77:01:00:70:0A:90:00:8B card.c:882:match_atr_table: ignored - wrong length Leading up to this difference, both files have the same lines (again, timestamps stripped): sc.c:195:sc_detect_card_presence: called reader-pcsc.c:388:pcsc_detect_card_presence: called reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check reader-pcsc.c:325:refresh_attributes: current state: 0x0120 reader-pcsc.c:326:refresh_attributes: previous state: 0x0122 reader-pcsc.c:380:refresh_attributes: card present reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5 sc.c:200:sc_detect_card_presence: returning with: 5 Using reader with a card: SCM SCR 331 00 00 sc.c:195:sc_detect_card_presence: called reader-pcsc.c:388:pcsc_detect_card_presence: called reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check reader-pcsc.c:325:refresh_attributes: current state: 0x0120 reader-pcsc.c:326:refresh_attributes: previous state: 0x0120 reader-pcsc.c:380:refresh_attributes: card present reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5 sc.c:200:sc_detect_card_presence: returning with: 5 card.c:125:sc_connect_card: called reader-pcsc.c:468:pcsc_connect: called reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check Any clues? -scooter (*) Would it be permissible to mark unused parameters in static functions as unused? Really. It gets in the way of tracking down interesting problems, like signed/unsigned conversions, integer length issues, ... If the code has to compile with -Wall, then the code could be selective with respect to which are really important warnings, no? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Two back-to-back runs, different results
On 9/5/2012 12:48 PM, Scott Michel wrote: I am trying to debug an issue with the SCM 311 reader and Oberthur ID One card in order to better support Macs and smart card-enabled sites. I've been using pkcs15-tool to list certificates on the card. The result is that on the first run with the card inserted for the first time, certificates are listed. On the next, second run, no certificates are listed; pkcs15-tool reports no certificates. Turning up the debugging volume, I get the following unified diff output (/tmp/run-11 is the first run, /tmp/run-22 is the second run, timestamps stripped). On the first run, the card is detected as a T0 protocol card. On the second run, the card is detected as a T1 protocol card. I'm fairly certain this is a problem (listing certificates requires APDU messages, not TPDU messages, no?), but not sure where to go look in the code to propose a patch. (*) --- /tmp/run-11 2012-09-05 10:12:04.0 -0700 +++ /tmp/run-22 2012-09-05 10:12:08.0 -0700 @@ -21,7 +21,7 @@ reader-pcsc.c:325:refresh_attributes: current state: 0x0120 reader-pcsc.c:326:refresh_attributes: previous state: 0x0120 reader-pcsc.c:380:refresh_attributes: card present -reader-pcsc.c:497:pcsc_connect: Initial protocol: T0 protocol +reader-pcsc.c:497:pcsc_connect: Initial protocol: T1 protocol card.c:868:match_atr_table: ATR : 3b:db:96:00:80:1f:03:00:31:c0:64:b0:f3:10:00:07:90:00:80 That looks like a DoD CAC, Oberthur ID One 128 v5.5 Dual and the ATR says the protocol is T0. But the card and reader may try and negotiate T1. In a number of Oberthur documents it talks about ISO 7816-3 from 2006 supporting higher baud rates, and the card reader needs to be up to data. It one it talks about a card appearing to be mute. A pcscd debug trace might show something too. Try a newer reader? Is this a dual CAC and PIV card? (Does not look like it as the ATR for PIV has the application.) OpenSC only supports PIV or dual PIV and CAC. You could also try coolkey that supports CAC. card.c:879:match_atr_table: ATR try : 3B:DD:18:00:81:31:FE:45:80:F9:A0:00:00:00:77:01:00:70:0A:90:00:8B card.c:882:match_atr_table: ignored - wrong length Leading up to this difference, both files have the same lines (again, timestamps stripped): sc.c:195:sc_detect_card_presence: called reader-pcsc.c:388:pcsc_detect_card_presence: called reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check reader-pcsc.c:325:refresh_attributes: current state: 0x0120 reader-pcsc.c:326:refresh_attributes: previous state: 0x0122 reader-pcsc.c:380:refresh_attributes: card present reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5 sc.c:200:sc_detect_card_presence: returning with: 5 Using reader with a card: SCM SCR 331 00 00 sc.c:195:sc_detect_card_presence: called reader-pcsc.c:388:pcsc_detect_card_presence: called reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check reader-pcsc.c:325:refresh_attributes: current state: 0x0120 reader-pcsc.c:326:refresh_attributes: previous state: 0x0120 reader-pcsc.c:380:refresh_attributes: card present reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5 sc.c:200:sc_detect_card_presence: returning with: 5 card.c:125:sc_connect_card: called reader-pcsc.c:468:pcsc_connect: called reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check Any clues? Try a different reader? -scooter (*) Would it be permissible to mark unused parameters in static functions as unused? Really. It gets in the way of tracking down interesting problems, like signed/unsigned conversions, integer length issues, ... If the code has to compile with -Wall, then the code could be selective with respect to which are really important warnings, no? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Windows minidriver and Secure PIN Entry
I have installed the drivers from HID Global for this reader. The same reader device driver will be used regardless of whether the PKCS#11 module, or the minidriver is used to interact with the Smart Card, right? And as I mentioned when I use the PCKS#11 driver, I'm prompted to enter my pin on the pinpad. When I use the opensc minidriver, I'm prompted to enter my pin in a windows dialog box using the PC keyboard. Is the opensc minidriver not able to detect and use the pinpad? - Tim On Sat, 2012-08-25 at 01:10 +0200, Frank Morgner wrote: The default Windows USB CCID driver does not support secure PIN entry. You need to get a better driver for your reader. Presumably OmniKey provides such a driver. Cheers, Frank. On Friday, August 24 at 03:03PM, Taylor, Tim wrote: Hello, I've been a long time user of the opensc project on linux. Now I'm trying to use OpenSC on Windows 7. The reader I'm using is an OmniKey 3821 USB CCID device with an LCD display and a PIN pad. Using the opensc PKCS#11 module in applications such as firefox or thunderbird works great, requiring the card PIN to be entered on the PIN pad of the reader as desired. Now I'm looking at using the opensc minidriver to provide access for applications that use the Windows crpyto API. After some fiddling around, I managed to change the driver for my smart card (Gemalto TOPDLGX4 144k) to the opensc minidriver. However, when I use an application that tries to access the card, I'm prompted to enter the PIN in a Windows dialog rather than the reader PIN pad. Is there a way to have the external PIN pad be used to enter card PINs when using the opensc minidriver? - Tim ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Windows minidriver and Secure PIN Entry
On 9/5/2012 4:32 PM, Taylor, Tim wrote: I have installed the drivers from HID Global for this reader. The same reader device driver will be used regardless of whether the PKCS#11 module, or the minidriver is used to interact with the Smart Card, right? And as I mentioned when I use the PCKS#11 driver, I'm prompted to enter my pin on the pinpad. When I use the opensc minidriver, I'm prompted to enter my pin in a windows dialog box using the PC keyboard. Is the opensc minidriver not able to detect and use the pinpad? With the PKCS#11 OpenSC calls pcsc_detect_readers and this calls the detect_reader_features. With the minidriver, the Microsoft code passes in the handles of open connections to PC/SC, and pcsc_detect_readers is not called, so no special features get detected. It might be possible call the pcsc_reader_features from the minidriver but it would require some code changes and testing. - Tim On Sat, 2012-08-25 at 01:10 +0200, Frank Morgner wrote: The default Windows USB CCID driver does not support secure PIN entry. You need to get a better driver for your reader. Presumably OmniKey provides such a driver. Cheers, Frank. On Friday, August 24 at 03:03PM, Taylor, Tim wrote: Hello, I've been a long time user of the opensc project on linux. Now I'm trying to use OpenSC on Windows 7. The reader I'm using is an OmniKey 3821 USB CCID device with an LCD display and a PIN pad. Using the opensc PKCS#11 module in applications such as firefox or thunderbird works great, requiring the card PIN to be entered on the PIN pad of the reader as desired. Now I'm looking at using the opensc minidriver to provide access for applications that use the Windows crpyto API. After some fiddling around, I managed to change the driver for my smart card (Gemalto TOPDLGX4 144k) to the opensc minidriver. However, when I use an application that tries to access the card, I'm prompted to enter the PIN in a Windows dialog rather than the reader PIN pad. Is there a way to have the external PIN pad be used to enter card PINs when using the opensc minidriver? - Tim ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Windows minidriver and Secure PIN Entry
On Thu, Sep 6, 2012 at 12:32 AM, Taylor, Tim ttay...@mitre.org wrote: Is the opensc minidriver not able to detect and use the pinpad? At the moment, no. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
