Re: [opensc-devel] Java and pkcs11
The latest OCF package at [1] has support for smartcardio - so if you need more than just the APDU interface. Andreas [1] http://www.openscdp.org/ocf/download.html Am 12.08.2011 12:11, schrieb resoli - libero: Il giorno mer, 10/08/2011 alle 08.36 +0200, NdK ha scritto: On 09/08/2011 20:48, Vlastimil Pavicek wrote: I haven't read the whole thread, but you might find this library useful (it is easier to use than JNI/JNA): http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS-11-Wrapper Tks. Found last night. It's used by j4sign[1] that targets multiple platforms. By its own it seems it's not enough, but it have to be used in parallel with the OCF wrapper (for card detection). I'm the main developer of j4sign; as someone already suggested, smartcardio is better suited at the moment for interfacing pcsc directly. j4sign will switch soon to smartcardio . bye, Roberto Resoli I'll have to dig better... [1] http://j4sign.sourceforge.net/index.html BYtE, Diego. ___ 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] Java and pkcs11
You might consider this useful as well (card detection): http://download.oracle.com/javase/6/docs/jre/api/security/smartcardio/spec/javax/smartcardio/package-summary.html it works very well under Sun/Oracle Java. Best regards VLP __ Od: NdK ndk.cla...@gmail.com Komu: opensc-devel@lists.opensc-project.org, helpcrypto helpcrypto helpcry...@gmail.com Datum: 10.08.2011 08:36 Předmět: Re: [opensc-devel] Java and pkcs11 On 09/08/2011 20:48, Vlastimil Pavicek wrote: I haven't read the whole thread, but you might find this library useful (it is easier to use than JNI/JNA): http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS-11-Wrapper Tks. Found last night. It's used by j4sign[1] that targets multiple platforms. By its own it seems it's not enough, but it have to be used in parallel with the OCF wrapper (for card detection). I'll have to dig better... [1] http://j4sign.sourceforge.net/index.html BYtE, Diego. ___ 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] Java and pkcs11
On 09/08/2011 20:48, Vlastimil Pavicek wrote: I haven't read the whole thread, but you might find this library useful (it is easier to use than JNI/JNA): http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS-11-Wrapper Tks. Found last night. It's used by j4sign[1] that targets multiple platforms. By its own it seems it's not enough, but it have to be used in parallel with the OCF wrapper (for card detection). I'll have to dig better... [1] http://j4sign.sourceforge.net/index.html BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
Hi, I haven't read the whole thread, but you might find this library useful (it is easier to use than JNI/JNA): http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/PKCS-11-Wrapper Best regards VLP __ Od: NdK ndk.cla...@gmail.com Komu: opensc-devel@lists.opensc-project.org Datum: 02.08.2011 13:52 Předmět: [opensc-devel] Java and pkcs11 Hi all! Maybe it's nearly OT, but I think it could be useful for other readers. I've found that a quite recurring problem in accessing tokens from java is the PKCS11 not found exception. Disabling hot plug support, as suggested in the past to another user, didn't work in my case. The -Djava.security.debug=sunpkcs11 'workaround' is quite unsatisfactory (really slows down startup), but I've found that using SunPKCS11 and a config file containing: -8-- name = smartcard library = /usr/lib/opensc-pkcs11.so slotListIndex=1 -8-- (so, specifying the slotListIndex) I can actually avoid that exception. But every user should determine his own slotListIndex (and, IIUC, it changes if there are certs under different PINs). What I still miss: - why can't I read certs out of the card even if they're publicly readable? - once I can read a cert, how could I determine which slot I should authenticate against to use the corresponding private key? - should I avoid SunPKCS11 and base my program on simple PC/SC? Tks, Diego. ___ 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] Java and pkcs11
If any of you dont agree with any of the following, just let me know. - should I avoid SunPKCS11 and base my program on simple PC/SC? Absolutely not. Do yo code on assembly for you web pages? PCSC should be used only if your smartcard doesnt have a higher level of abstraction possible (like opensc) If you need to stick to Java, maybe JNI is the answer. I dont like it very much, but we have some legacy toools which use this technology I usually do C, but this time I need a java applet for: 1) a web-based password manager I have to write for the office If you explain more, i can tell you my opinion about what you could need/do 2) safely and strongly authenticate users to a plain HTTP page (very shared-hosting friendly!) -- I already can authenticate users w/ a smartcard (on https), but it needs Firefox to load its PKCS11 that locks the card and no other process can use it. must be a problem with your code. Actually, our card is used by firefox+thunder+ie+local apps at the same time. I don't really like JNI since it usually needs uncommon client-side libraries, that's why I thought about pcsc (even if, after all, it's JNI anyway), since I already studied it and deps-wise it doesn't need anything more than the minimum. You can observe what others do: Spanish tax ministry dont use Applets (use native componentes), which doesnt require the user to have java. https://www.agenciatributaria.gob.es/AEAT.sede/Inicio/Inicio.shtml Spanish ecofirma (also from gov) uses an applet that downloads a jnlp that install everything needed on your computer http://oficinavirtual.mityc.es/javawebstart/soc_info/ecofirma/index.html In our company, we use smartcard for client/user authentication using certificates, and also mail signing and document signing. For web applications we use a signed applet. This applet is done using Oracle/Sun JCE (java 1.6). Seems that SUN = 1.6 jre its the only one which had cryptography some time ago. Maybe this has changed and now openjdk include it. You should ask on java lists (and update me with the news, PLEASE!). The applet side is made by another person, but im the developer of the pkcs11 library that runs on osx, win and linux. Its not made using opensc due its a legacy code that have been re-coded just a few months ago, and 'cause our card its not pkcs#15, either really criptographic. (at least its PCSC!) Anyhow, on a recent discussion on mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=654939), i was sadly surprised to read things like: If Java is trying to load Firefox's NSS libraries, it deserves to not work. Having external apps digging through the Mozilla cert store is not recommended or supported in any case. This is not something that we intend to support or fix. No, writing enterprise apps which poke into the Firefox certificate store is not a desired use-case, especially while the app is running. I know that JSS is used for server applications written in Java. I was not even aware that it's possible to use JSS inside browser applets. ... (and many more) So, in other words...altough Java has examples, doc and code to explain how to use JSS (Java to NSS) and its working perfectly, this seems to be a bad thing for mozilla's people. I still have to discuss at https://lists.mozilla.org/listinfo/dev-platform On IE, you should code a CSP/CNG to access the smartcard and on Safari, you could use opensc or a tokend. Chrome depends on the system. At your position i will: -Check smartcard features to check if its opensc compatible -Implement your card at opensc or doing your own pkcs#11/csp/tokend (watch out lion 10.7 smartcard services!) if needed. This involves PCSC. -Use SUNPKCS11, or JSS if you want to rely on dangerous and evil undocumented behaviour Anything you need, dont hesitate to contact me. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
Il 03/08/2011 09:32, helpcrypto helpcrypto ha scritto: Do yo code on assembly for you web pages? PCSC should be used only if your smartcard doesnt have a higher level of abstraction possible (like opensc) I'd even prefer higher APIs, since doing security really well is hard. I usually do C, but this time I need a java applet for: 1) a web-based password manager I have to write for the office If you explain more, i can tell you my opinion about what you could need/do I need to implement a multiuser web password manager that allows users to group-share passwords (so Linux sysadmins don't have access to Windows passwords -- yes, I know AD, it's just an example). Server NEVER knows plaintext passwords, so even if it gets hacked no sensitive information is disclosed. Passwords must not be displayed, just gets copied to the clipboard (so I can access firewall password even if I'm in a lab with a dozen users behind my shoulders). 2) safely and strongly authenticate users to a plain HTTP page (very shared-hosting friendly!) -- I already can authenticate users w/ a smartcard (on https), but it needs Firefox to load its PKCS11 that locks the card and no other process can use it. must be a problem with your code. Actually, our card is used by firefox+thunder+ie+local apps at the same time. Known bug in FF, IIUC. When you insert the card (or load opensc-pkcs11) it C_Login to every slot even if you're not accessing certs. So: 1) it asks for EVERY pin (even signature ones) 2) while opensc-pkcs11 is loaded in FF, thunderbird (nor any other PKCS11 'client') doesn't see the card Anyway, auth using 'internal' method is possible only on https sites (unavailable on shared-hosting plans, and it's now giving me headaches since I need to use SNI, that's not supported by IE on XP). You can observe what others do: Always useful. Spanish tax ministry dont use Applets (use native componentes), which doesnt require the user to have java. But, IIUC, that restricts use to only supported browser/platform -- I have labs w/ Linux machines, workstations w/ Windows XP (some w/ only IE, some w/ FF), quite a lot of Macs... The minimum common denominator can be Java w/ a minimum of must-have native libs (like pcsc-lite and ccid), even if it could be even better if those aren't needed. https://www.agenciatributaria.gob.es/AEAT.sede/Inicio/Inicio.shtml Spanish ecofirma (also from gov) uses an applet that downloads a jnlp that install everything needed on your computer http://oficinavirtual.mityc.es/javawebstart/soc_info/ecofirma/index.html This assumes that the user: - can install sw - usually uses only one machine In our company, we use smartcard for client/user authentication using certificates, and also mail signing and document signing. For web applications we use a signed applet. This applet is done using Oracle/Sun JCE (java 1.6). Seems that SUN = 1.6 jre its the only one which had cryptography some time ago. Maybe this has changed and now openjdk include it. You should ask on java lists (and update me with the news, PLEASE!). I'm using Sun JVM too, since professor's digital signing applet needs it, too. The applet side is made by another person, but im the developer of the pkcs11 library that runs on osx, win and linux. Its not made using opensc due its a legacy code that have been re-coded just a few months ago, and 'cause our card its not pkcs#15, either really criptographic. (at least its PCSC!) Well, I'm using Aventra cards, so they're both PKCS15 and cryptographic :) I thougt you can't have legally strong signature unless you're using a crypto card (at least here in Italy). Anyhow, on a recent discussion on mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=654939), i was sadly surprised to read things like: If Java is trying to load Firefox's NSS libraries, it deserves to not work. Having external apps digging through the Mozilla cert store is not recommended or supported in any case. This is not something that we intend to support or fix. No, writing enterprise apps which poke into the Firefox certificate store is not a desired use-case, especially while the app is running. I know that JSS is used for server applications written in Java. I was not even aware that it's possible to use JSS inside browser applets. ... (and many more) Sometimes I can't understand'em... Like for the support of DNS extensions (commonly used by voip, jabber, Active Directory...) to tell on which port is https listening... IIRC it's about 10 years that a patch is available but never got adopted! So, in other words...altough Java has examples, doc and code to explain how to use JSS (Java to NSS) and its working perfectly, this seems to be a bad thing for mozilla's people. I still have to discuss at https://lists.mozilla.org/listinfo/dev-platform On IE, you should code a CSP/CNG to access the smartcard and on Safari, you could use opensc or a tokend. Chrome depends on the system. That's
Re: [opensc-devel] Java and pkcs11
2011/8/3 NdK ndk.cla...@gmail.com: Il 03/08/2011 09:32, helpcrypto helpcrypto ha scritto: I need to implement a multiuser web password manager that allows users to group-share passwords (so Linux sysadmins don't have access to Windows passwords -- yes, I know AD, it's just an example). Server NEVER knows plaintext passwords, so even if it gets hacked no sensitive information is disclosed. Passwords must not be displayed, just gets copied to the clipboard (so I can access firewall password even if I'm in a lab with a dozen users behind my shoulders). As i understand, you want to develop like a wallte, where password stored on server (crypted) are copied to clipboard (altough a simply CTRL+V will display it), to let the user authenticate in toher services. Right? You need applets cause the access to this wallet is using smartcard? certificate? I agree, its the most homogenic way of doint it cross-browser Known bug in FF, IIUC. When you insert the card (or load opensc-pkcs11) it C_Login to every slot even if you're not accessing certs. So: 1) it asks for EVERY pin (even signature ones) Whats IIUC means? With our company card+spanish ID (dnie) on different readers, while doing client auth, it ask for 2 pins (one for each slot), to retrieve ALL the certs from all the slots/tokens. That, let FF to show a windows to select all possible certs. Is this the scenario you are pointing? Can you give me the bugzilla number? (From my experience, NSS or the part responsible from retrieving the certs its not very efficient...for example, it request like 150 times for vendor objects on my token, altough the first time i say i have no one) I think we should exchange experiences :P 2) while opensc-pkcs11 is loaded in FF, thunderbird (nor any other PKCS11 'client') doesn't see the card Thats a opensc desired/undesired behaviour. If OpenSC did that for any reason, you could ask here (or martin). But i can tell you, its not FF the one who locks, cause my smartcard can be used and viewed by many at the same time. (Thanks god PCSC's BeginTransaction and EndTransaction methods) Anyway, auth using 'internal' method is possible only on https sites (unavailable on shared-hosting plans, and it's now giving me headaches since I need to use SNI, that's not supported by IE on XP). No idea of what internal means, SNI, or what are you taliking about. Spanish tax ministry dont use Applets (use native componentes), which doesnt require the user to have java. But, IIUC, that restricts use to only supported browser/platform -- I have labs w/ Linux machines, workstations w/ Windows XP (some w/ only IE, some w/ FF), quite a lot of Macs... The minimum common denominator can be Java w/ a minimum of must-have native libs (like pcsc-lite and ccid), even if it could be even better if those aren't needed. We have that 3 systems, and support for 3 major browser on each Firefox/Chrome/IE/Safari. I thinks thats neough for end users...come on, dont make me support lynx please. BTW, dont expect a friendly environment using Java on OSX, this guys hate them. Again, similar scenario, maybe we could exchange more info. https://www.agenciatributaria.gob.es/AEAT.sede/Inicio/Inicio.shtml Spanish ecofirma (also from gov) uses an applet that downloads a jnlp that install everything needed on your computer http://oficinavirtual.mityc.es/javawebstart/soc_info/ecofirma/index.html This assumes that the user: - can install sw Copying files its not always needed, but access to the system its. Signed applets will let you access the system, and you could whatever you want. - usually uses only one machine Not true...it just extract and run, even better that installing a client software. There are many ways to allow this without much headhache...and clean the temp files before shutting down :P I Agree its slower, but anyone could use it anywhere (desktop computer) Well, I'm using Aventra cards, so they're both PKCS15 and cryptographic :) I thougt you can't have legally strong signature unless you're using a crypto card (at least here in Italy). According to our law (Spain), to have the higher level of recognized sign, equivalent (and even more) to a hand made sign, you need a secure signing device (keypair generated inside the card). This, for example, doesnt let the users export the key to a pkcs#12 file that could compromise the key. ---MAYBE IM WRONG ON THIS, so anyone can correct me and, please, do it if im wrong--- Anyway, the sing has legal value and its recognized as an advanced sign, the different can be resumed as: In case of trial, -recognized signatures (created using a secure signing device) are truthworthy unless the the opposite is proved (defense should prove it) -advances signatures arent truthworthy unless can be proved (prosecutor should prove it) Sometimes I can't understand'em... Like for the support of DNS extensions (commonly used by voip, jabber, Active Directory...) to tell on which port is https
Re: [opensc-devel] Java and pkcs11
Il 03/08/2011 11:08, helpcrypto helpcrypto ha scritto: As i understand, you want to develop like a wallte, where password stored on server (crypted) are copied to clipboard (altough a simply CTRL+V will display it), to let the user authenticate in toher services. Right? Yup. Right. Ctrl-V is the smallest problem (a bigger one is KDE's cache in system tray) and should be solved politically (even KDE's cache can be cleared inserting enough random strings. But that's really OT here. You need applets cause the access to this wallet is using smartcard? certificate? The wallet must allow for use of a smart card or a simple password (obviously highly sensitive passwords will have to be restricted to stronger method). Not really different at the programmatic level, since I can store anything in the encryptedPrivateKey field: an actual key or a reference to a token. Known bug in FF, IIUC. When you insert the card (or load opensc-pkcs11) it C_Login to every slot even if you're not accessing certs. So: 1) it asks for EVERY pin (even signature ones) Whats IIUC means? If I Understand Correctly. With our company card+spanish ID (dnie) on different readers, while doing client auth, it ask for 2 pins (one for each slot), to retrieve ALL the certs from all the slots/tokens. That's exactly what I noticed. Seems the key is the friendly flag that's (IMVHO) badly thought (since I can access both friendly and unfriendly tokens w/ the same lib). And (more general question) why a slot identifies a pin? What about insecure keys and their certs? See below. That, let FF to show a windows to select all possible certs. Is this the scenario you are pointing? Can you give me the bugzilla number? (From my experience, NSS or the part responsible from retrieving the certs its not very efficient...for example, it request like 150 times for vendor objects on my token, altough the first time i say i have no one) Well, just searching smart card in bugzilla pops up quite a lot of issues. 460985 e 378476 (always selects the first cert from a card), 453025 (security devices only loaded on application start) and many more... I think we should exchange experiences :P Mine is just: too buggy to be actually used w/ smartcards, useful only in the simplest scenarios. 2) while opensc-pkcs11 is loaded in FF, thunderbird (nor any other PKCS11 'client') doesn't see the card Thats a opensc desired/undesired behaviour. If OpenSC did that for any reason, you could ask here (or martin). But i can tell you, its not FF the one who locks, cause my smartcard can be used and viewed by many at the same time. (Thanks god PCSC's BeginTransaction and EndTransaction methods) I can't retrieve now the bug #, but IIRC it keeps the session to the token open. Maybe your card allows for more than one channel. Anyway, auth using 'internal' method is possible only on https sites (unavailable on shared-hosting plans, and it's now giving me headaches since I need to use SNI, that's not supported by IE on XP). No idea of what internal means, SNI, or what are you taliking about. Internal is when the https server asks for a client cert. SNI is an extension to TLS that allows more than one https virtual host on an IP/port by giving the requested server name at the start of the handshake. We have that 3 systems, and support for 3 major browser on each Firefox/Chrome/IE/Safari. I thinks thats neough for end users...come on, dont make me support lynx please. No, but writing 9 different apps is not the solution, IMVHO. BTW, dont expect a friendly environment using Java on OSX, this guys hate them. I'll have to fight whith it, then :) This assumes that the user: - can install sw Copying files its not always needed, but access to the system its. Signed applets will let you access the system, and you could whatever you want. Nope. You can install sw only if the policy allows you to do it. And often (think about a kiosk) it's forbidden. A signed applet can AT MOST have the same rights of the user, IIRC (I don't remember a poliy to give an applet more rights than the ones assigned to the user running it...). - usually uses only one machine Not true...it just extract and run, even better that installing a client software. Uh, right... jnlp headaches... :) Still needs JVM, pcsc, etc... And it's anyway better if the downloaded app is signed... So I don't see real dvantages here. If only SunPKCS11 would be more versatile... Maybe the simplest thing is to get its source and hack it, so that it: - supports plain on-card keypairs - only asks PIN when needed AFAIK, both can be done. Not w/ standard SunPKCS11. See below. - handles multiple slots What you mean with this? That's something I still couldn't understand well... Reading PKCS11-v2.30b specs, it seems a slot is just a physical object where a card can be placed. So a reader should present more than one slot only if it accepts more than one token: Cryptoki provides an interface to
Re: [opensc-devel] Java and pkcs11
2011/8/3 NdK ndk.cla...@gmail.com: The wallet must allow for use of a smart card or a simple password (obviously highly sensitive passwords will have to be restricted to stronger method). Not really different at the programmatic level, since I can store anything in the encryptedPrivateKey field: an actual key or a reference to a token. Understood. Java signed applets seems the most homogeinic way of doing it. (Better than writing one script for each browser) That's exactly what I noticed. Seems the key is the friendly flag that's (IMVHO) badly thought (since I can access both friendly and unfriendly tokens w/ the same lib). Is that a opensc flag? (remember i dont use opensc, so dont know the internals) And (more general question) why a slot identifies a pin? What about insecure keys and their certs? See below. An slot doesnt need to have a PIN, as stated on PKCS#11 standard. Even if FF does a bad implementation, and always require a PIN using C_Login, the slot/token could return CKR_OK and continue. Our public cert is stored on a public area of our card, that can be readed and added to NSS without prompting for PIN. Maybe we are talking about different issues here. I think we should exchange experiences :P Mine is just: too buggy to be actually used w/ smartcards, useful only in the simplest scenarios. In my experience, i can guarantee that NSS is enough stable to be used with smartcard among with Java Applet. We have lot of users, and just a few of known problems. (I already talked about a PSM/NSS deep review)... I can't retrieve now the bug #, but IIRC it keeps the session to the token open. Maybe your card allows for more than one channel. No. Our card is a stupidcard rather than smartcard. I noticed FF try to retrieve the session that was previosly used (that is closed when smartcard removed and inserted on reader), but this is easily solved saying CKR_INVALID_HANDLE (was this CKR_, right?) Anyway, i agree...PSM/NSS has aspect that could be improved. (And the community...including you and me, could improve) No, but writing 9 different apps is not the solution, IMVHO. We just have one applet (to rule them all) and some cross.browser js support to detect them. Nope. You can install sw only if the policy allows you to do it. And often (think about a kiosk) it's forbidden. A signed applet can AT MOST have the same rights of the user, IIRC (I don't remember a poliy to give an applet more rights than the ones assigned to the user running it...). Totally right. Then, your applet should be self-running...and that means no JSS. You should look for a method to locate your PKCS#11 module and so. If you go in this direction, let me know, cause will be our next target soon. - handles multiple slots What you mean with this? That's something I still couldn't understand well... Reading PKCS11-v2.30b specs, it seems a slot is just a physical object where a card can be placed. So a reader should present more than one slot only if it accepts more than one token: Cryptoki provides an interface to one or more cryptographic devices that are active in the system through a number of “slots”. Each slot, which corresponds to a physical reader or other device interface, may contain a token. A token is typically “present in the slot” when a cryptographic device is present in the reader. Of course, since Cryptoki provides a logical view of slots and tokens, there may be other physical interpretations. It is possible that multiple slots may share the same physical reader. The point is that a system has some number of slots, and applications can connect to tokens in any or all of those slots. (page 17). 1 - PKCS#11 standard was designed a long time ago, so consider it has several lacks, for example concurrent access, multiple pin auth/virtual slots...or this strange/complex explanation about slots In the smartcard approach you and me are using, this is translated as: One slot for each reader When the card is inserted in the slot, the token info is retrieved and shown. In my case, as user should have only 1 card, we want to avoid problems, 'cause we have to code our library... we have just 1 slot, no matter which number of readers you have, and when a card is inserted, we loop trough all the readers to check if our card is present. Its not perfect, but works like a charm. So I can understand that when I plug in another reader I get another set of slots. Well..more or less, that will be the idea. What I don't understand is why I get a slot for every PIN on my card, plus a PnP (always empty) slot. You dont simply get an slot for evrey PIN... (as usual, EXPERTS: correct me if im wrong) If your smartcard has multiple pin auth system (like many applications, each on with a pin), thers should be a way to login on each one. Consider the following: smartcard with 2 apps, both of them containing certificates. How you should do to use any of these? If you map slot-reader-card, this cant
Re: [opensc-devel] Java and pkcs11
Il 03/08/2011 13:35, helpcrypto helpcrypto ha scritto: And (more general question) why a slot identifies a pin? What about insecure keys and their certs? See below. An slot doesnt need to have a PIN, as stated on PKCS#11 standard. Then why I get *exaxtly* one slot per PIN (and in the slot name there's the label I associated with the PIN? Maybe it's opensc-specific, but I doubt. 1 - PKCS#11 standard was designed a long time ago, so consider it has several lacks, for example concurrent access, multiple pin auth/virtual slots...or this strange/complex explanation about slots In 2.30 concurrent access is explained quite well. Both multitasking and multithreading -wise. In the smartcard approach you and me are using, this is translated as: One slot for each reader When the card is inserted in the slot, the token info is retrieved and shown. Should be this way. Experiments say otherwise. What I don't understand is why I get a slot for every PIN on my card, plus a PnP (always empty) slot. You dont simply get an slot for evrey PIN... (as usual, EXPERTS: correct me if im wrong) I do. And they're named after the labels I gave to my PINs. If your smartcard has multiple pin auth system (like many applications, each on with a pin), thers should be a way to login on each one. Consider the following: smartcard with 2 apps, both of them containing certificates. How you should do to use any of these? You'd have to select the app before. IIUC you can't switch app while card is in use (well, you an but it's like disconnecting a card and inserting a new one, with its own ATR). Discovering which apps are available on a card is another issue. But if I need PKCS15, i select app A300 'just to be sure'. All the rest tends to be too OT here and I'm replying privately. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
2011/8/3 NdK ndk.cla...@gmail.com: Then why I get *exaxtly* one slot per PIN (and in the slot name there's the label I associated with the PIN? Maybe it's opensc-specific, but I doubt. must be opensc is adding an slot for each application/pin. You should check this with someone/martin, but im pretty sure is this. In 2.30 concurrent access is explained quite well. Both multitasking and multithreading -wise. ...tell me when developing :P We have thread support+lock+transactions to avoid process interference, but all this was happily superseeded qhen logical channels arrived at 7816-4 (which our card doesnt support either) Should be this way. Experiments say otherwise. OpenSC implemente in other way, because PKCS#11 doesnt include multiple pin/virtual slot applications (Anex D?E?...was removed, and talked about this. check version 2.0 or earlier) I do. And they're named after the labels I gave to my PINs. Did you read the example i gave you to understand what happend? OpenSC must be doing it like this. You'd have to select the app before. IIUC you can't switch app while card is in use (well, you an but it's like disconnecting a card and inserting a new one, with its own ATR). Discovering which apps are available on a card is another issue. But if I need PKCS15, i select app A300 'just to be sure'. Absolutely wrong: Consider applications as directories. One of them can be protected for reading, other for writing, or even public. Your app could need to go trough some of then and your card will not be disconnected at all. PCSC common operation sum up: -establish context (get access to the pcsc service) -connect (comunicate with card...the ATR is received here, just once) -begin transaction (lock for exclusive access) -select 23 applications/DF, read 234232 EF... -entransaction -disconnect -release context What really happened here is that PKCS#15 helps a lot handling objects, but the interface its still #11. intended for cryptoki operations and without virtual slots defined. If you want different certificates depending on which URL you are, PKCS#11 doesnt range this, and the you are out of standard If your application(Java) should use different certs (stored on different apps), then the simplest way is to connect to different PKCS#11 modules or slots Thats why opensc will show an slot for each Application/PIN. Its a way of accepting virtual slots, allowing multiple applications and readers, and making the coding harder. As always, any expert comment showing any mistake will be fine. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
You say you are using FF, so have you looked at JSS? http://www.mozilla.org/projects/security/pki/jss/ As I read this, it is a java interface to NSS, and thus avoid the sunPKCS11 and its limitations, but still allow the use of OpenSC. On Windows, you could also use the Windows CAPI via the SunMSCAPI, and OpenSC on Windows can still be used via the OpenSC mindriver. See below. On 8/3/2011 5:52 AM, NdK wrote: Il 03/08/2011 11:08, helpcrypto helpcrypto ha scritto: As i understand, you want to develop like a wallte, where password stored on server (crypted) are copied to clipboard (altough a simply CTRL+V will display it), to let the user authenticate in toher services. Right? Yup. Right. Ctrl-V is the smallest problem (a bigger one is KDE's cache in system tray) and should be solved politically (even KDE's cache can be cleared inserting enough random strings. But that's really OT here. You need applets cause the access to this wallet is using smartcard? certificate? The wallet must allow for use of a smart card or a simple password (obviously highly sensitive passwords will have to be restricted to stronger method). Not really different at the programmatic level, since I can store anything in the encryptedPrivateKey field: an actual key or a reference to a token. Known bug in FF, IIUC. When you insert the card (or load opensc-pkcs11) it C_Login to every slot even if you're not accessing certs. So: 1) it asks for EVERY pin (even signature ones) Whats IIUC means? If I Understand Correctly. With our company card+spanish ID (dnie) on different readers, while doing client auth, it ask for 2 pins (one for each slot), to retrieve ALL the certs from all the slots/tokens. That's exactly what I noticed. Seems the key is the friendly flag that's (IMVHO) badly thought (since I can access both friendly and unfriendly tokens w/ the same lib). And (more general question) why a slot identifies a pin? What about insecure keys and their certs? See below. That, let FF to show a windows to select all possible certs. Is this the scenario you are pointing? Can you give me the bugzilla number? (From my experience, NSS or the part responsible from retrieving the certs its not very efficient...for example, it request like 150 times for vendor objects on my token, altough the first time i say i have no one) Well, just searching smart card in bugzilla pops up quite a lot of issues. 460985 e 378476 (always selects the first cert from a card), 453025 (security devices only loaded on application start) and many more... Here are 3 others: 357025, 613496, 613507, These deal with selecting the best slot, supporting CK_ALWAYS_AUTHENTICATE if needed, and cutting down on searching for any object when it should be searching for a cert only, which may be your 150 times. I think we should exchange experiences :P Mine is just: too buggy to be actually used w/ smartcards, useful only in the simplest scenarios. 2) while opensc-pkcs11 is loaded in FF, thunderbird (nor any other PKCS11 'client') doesn't see the card Thats a opensc desired/undesired behaviour. If OpenSC did that for any reason, you could ask here (or martin). But i can tell you, its not FF the one who locks, cause my smartcard can be used and viewed by many at the same time. (Thanks god PCSC's BeginTransaction and EndTransaction methods) I can't retrieve now the bug #, but IIRC it keeps the session to the token open. Maybe your card allows for more than one channel. Anyway, auth using 'internal' method is possible only on https sites (unavailable on shared-hosting plans, and it's now giving me headaches since I need to use SNI, that's not supported by IE on XP). No idea of what internal means, SNI, or what are you taliking about. Internal is when the https server asks for a client cert. SNI is an extension to TLS that allows more than one https virtual host on an IP/port by giving the requested server name at the start of the handshake. We have that 3 systems, and support for 3 major browser on each Firefox/Chrome/IE/Safari. I thinks thats neough for end users...come on, dont make me support lynx please. No, but writing 9 different apps is not the solution, IMVHO. BTW, dont expect a friendly environment using Java on OSX, this guys hate them. I'll have to fight whith it, then :) This assumes that the user: - can install sw Copying files its not always needed, but access to the system its. Signed applets will let you access the system, and you could whatever you want. Nope. You can install sw only if the policy allows you to do it. And often (think about a kiosk) it's forbidden. A signed applet can AT MOST have the same rights of the user, IIRC (I don't remember a poliy to give an applet more rights than the ones assigned to the user running it...). - usually uses only one machine Not true...it just extract and run, even better that installing a client software. Uh, right... jnlp headaches...
Re: [opensc-devel] Java and pkcs11
On 03/08/2011 16:16, Douglas E. Engert wrote:
You say you are using FF, so have you looked at JSS?
http://www.mozilla.org/projects/security/pki/jss/
Nope. Proprietary (available only for FF).
As I read this, it is a java interface to NSS, and thus avoid the
sunPKCS11 and its limitations, but still allow the use of OpenSC.
It uses SunPKCS11.
On Windows, you could also use the Windows CAPI via the SunMSCAPI,
and OpenSC on Windows can still be used via the OpenSC mindriver.
Still proprietary solutions.
And what about smartphones? Standard Java is more likely to be adapted
than proprietary interfaces.
Well, just searching smart card in bugzilla pops up quite a lot of
issues. 460985 e 378476 (always selects the first cert from a card),
453025 (security devices only loaded on application start) and many more...
Here are 3 others: 357025, 613496, 613507, These deal with selecting
the best slot, supporting CK_ALWAYS_AUTHENTICATE if needed, and
cutting down on searching for any object when it should be searching for
a cert only, which may be your 150 times.
Well... The user should be responsible for selecting the best slot.
That IMHO shouldn't be a slot in the first place, but just a
certificate. The browser should only filter certs so that only
acceptable ones are proposed to the user.
If an object isn't accessible ('cause it's marked private), it should
user's responsibility to login w/ the correct credentials first.
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
2011/8/3 NdK ndk.cla...@gmail.com:
On 03/08/2011 16:16, Douglas E. Engert wrote:
You say you are using FF, so have you looked at JSS?
http://www.mozilla.org/projects/security/pki/jss/
How can you say so, if JSS is not recommended/supported for Java Applets?
(as said in the infamous bug
https://bugzilla.mozilla.org/show_bug.cgi?id=654939)
Anyway, AFAIK, using JSS doesnt avoid using sunPKCS11.
JSS avoids using smartcardio to list modules using a conf file, and
gives direct access to a PKCS#11 module
On Windows, you could also use the Windows CAPI via the SunMSCAPI,
and OpenSC on Windows can still be used via the OpenSC mindriver.
Still proprietary solutions.
And what about smartphones? Standard Java is more likely to be adapted
than proprietary interfaces.
AFAIK, Java applet should attack the system keystore no matter how.
Having a cert on keystore (loaded from smartcard) is done using CSP or
CNG. At least, thats the way we do it.
Here are 3 others: 357025, 613496, 613507, These deal with selecting
the best slot, supporting CK_ALWAYS_AUTHENTICATE if needed, and
cutting down on searching for any object when it should be searching for
a cert only, which may be your 150 times.
My 150 times its a vendor_defined object (CKO_VENDOR_DEFINED), and its
a bad implementation of NSS/PSM (i really dont know the internals).
Well... The user should be responsible for selecting the best slot.
That IMHO shouldn't be a slot in the first place, but just a
certificate. The browser should only filter certs so that only
acceptable ones are proposed to the user.
Thats what actually is done, isnt it? At least, after the pin request,
a window with certs is shown to select one...
If an object isn't accessible ('cause it's marked private), it should
user's responsibility to login w/ the correct credentials first.
The NSS should detect the flag, and if needed, call C_Login or do the
operations needed. Sometimes the object is not extractable from the
smartcard, so it depends.
Maybe the PIN should be cached cause sometimes card can be reset
between calls, and that loose the security access.
Thats the reason why spanish ID its requesting the PIN all the time(?)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
Hello, On Aug 3, 2011, at 6:22 PM, NdK wrote: On Windows, you could also use the Windows CAPI via the SunMSCAPI, and OpenSC on Windows can still be used via the OpenSC mindriver. Still proprietary solutions. And what about smartphones? Standard Java is more likely to be adapted than proprietary interfaces. I don't believe that current smartphone platform vendors will embrace PKCS#11 as we know it on the desktop. At least I hope they will not. It would IMHO be a stupid choice. Java is a platform itself, so JCE/JCA could be the key, if anything. It might not be perfect or even most suitable. I agree with Anders that enrollment with mobile devices (with built-in security tokens) should eventually become as important as using keys. Take Android - it does not make use of standard Java API-s (Swing), yet it is very successful. Being able to run the code does not mean having sensible support for a platform with minimal or no code changes. When developing a portable application (in Java..) I would not bet much on PKCS#11 or similar. For optimal results assume that PKCS#11 is not available. My personal suggestion is to omit the proprietary excuse. Whenever running *anything* on Windows (or OS X), you are using a proprietary platform. Either refuse to run on it or try to live with it and make the most out of it by using the services provided by the platform is possible and providing users with as good experience as possible. Best, m. -- @MartinPaljak.net +3725156495 smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
On 03/08/2011 19:40, helpcrypto helpcrypto wrote:
Well... The user should be responsible for selecting the best slot.
That IMHO shouldn't be a slot in the first place, but just a
certificate. The browser should only filter certs so that only
acceptable ones are proposed to the user.
Thats what actually is done, isnt it? At least, after the pin request,
a window with certs is shown to select one...
Yes. But in my head it should work the other way around: ask for the PIN
only if no suitable object is found. If user wants to use a private
object, he must authenticate first.
If an object isn't accessible ('cause it's marked private), it should
user's responsibility to login w/ the correct credentials first.
The NSS should detect the flag, and if needed, call C_Login or do the
operations needed. Sometimes the object is not extractable from the
smartcard, so it depends.
Usually just private (or secret) keys are unextractable.
Maybe the PIN should be cached cause sometimes card can be reset
between calls, and that loose the security access.
Unless the object is marked for user consent.
Thats the reason why spanish ID its requesting the PIN all the time(?)
Probably 'cause it's for signature, so it's marked user-consent
(uncacheable).
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
On 03/08/2011 21:25, Martin Paljak wrote: And what about smartphones? Standard Java is more likely to be adapted than proprietary interfaces. I don't believe that current smartphone platform vendors will embrace PKCS#11 as we know it on the desktop. At least I hope they will not. It would IMHO be a stupid choice. Java is a platform itself, so JCE/JCA could be the key, if anything. It might not be perfect or even most suitable. I agree with Anders that enrollment with mobile devices (with built-in security tokens) should eventually become as important as using keys. Take Android - it does not make use of standard Java API-s (Swing), yet it is very successful. Being able to run the code does not mean having sensible support for a platform with minimal or no code changes. Well, I hope that those portability issues are handled by someone else :) since I'm too lazy to code the same thing w/ small differences for the various platform (or I wouldn't use Java in the first place...). When developing a portable application (in Java..) I would not bet much on PKCS#11 or similar. For optimal results assume that PKCS#11 is not available. I'm planning other possible auth methods, but I'll have to experiment what happens if I try to load my applet on a platform where there's no SunPKCS11 available. My personal suggestion is to omit the proprietary excuse. Whenever running *anything* on Windows (or OS X), you are using a proprietary platform. Either refuse to run on it or try to live with it and make the most out of it by using the services provided by the platform is possible and providing users with as good experience as possible. I simply don't want to adapt my code too much. I don't mind if the platform is proprietary as long as my app works as expected. If I could do that with C, I'd do it. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Java and pkcs11
Hi all! Maybe it's nearly OT, but I think it could be useful for other readers. I've found that a quite recurring problem in accessing tokens from java is the PKCS11 not found exception. Disabling hot plug support, as suggested in the past to another user, didn't work in my case. The -Djava.security.debug=sunpkcs11 'workaround' is quite unsatisfactory (really slows down startup), but I've found that using SunPKCS11 and a config file containing: -8-- name = smartcard library = /usr/lib/opensc-pkcs11.so slotListIndex=1 -8-- (so, specifying the slotListIndex) I can actually avoid that exception. But every user should determine his own slotListIndex (and, IIUC, it changes if there are certs under different PINs). What I still miss: - why can't I read certs out of the card even if they're publicly readable? - once I can read a cert, how could I determine which slot I should authenticate against to use the corresponding private key? - should I avoid SunPKCS11 and base my program on simple PC/SC? Tks, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
2011/8/2 NdK ndk.cla...@gmail.com Hi all! Maybe it's nearly OT, but I think it could be useful for other readers. I've found that a quite recurring problem in accessing tokens from java is the PKCS11 not found exception. Disabling hot plug support, as suggested in the past to another user, didn't work in my case. The -Djava.security.debug=sunpkcs11 'workaround' is quite unsatisfactory (really slows down startup), but I've found that using SunPKCS11 and a config file containing: -8-- name = smartcard library = /usr/lib/opensc-pkcs11.so slotListIndex=1 -8-- (so, specifying the slotListIndex) I can actually avoid that exception. But every user should determine his own slotListIndex (and, IIUC, it changes if there are certs under different PINs). What I still miss: - why can't I read certs out of the card even if they're publicly readable? Java Cryptographic is based on JCA/JCE arquitecture. The document at http://download.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html , preety much explains everything you need to know. It says, for example, that only trusted certificates or pairs (key, certificates) are listed as aliases from a Java perspective. - once I can read a cert, how could I determine which slot I should authenticate against to use the corresponding private key? The slot is fixed at the properties file. SUNPKCS #11 demands that you use diferent properties files for diferent slots. - should I avoid SunPKCS11 and base my program on simple PC/SC? I would say no. If you can code in C, it is better to use pure C PKCS #11 (or some helper like libp11 or pkcs11-helper), since working with APDU's is not easy (nor necessary). If you need to stick to Java, maybe JNI is the answer. Tks, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel Cheers, -- Felipe Menegola Blauth ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
On 02/08/2011 16:22, Felipe Blauth wrote: Java Cryptographic is based on JCA/JCE arquitecture. The document at http://download.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html , preety much explains everything you need to know. I'll have to reread it. It says, for example, that only trusted certificates or pairs (key, certificates) are listed as aliases from a Java perspective. Noticed that. So no way to use plain keypairs w/o certs... - once I can read a cert, how could I determine which slot I should authenticate against to use the corresponding private key? The slot is fixed at the properties file. SUNPKCS #11 demands that you use diferent properties files for diferent slots. I'm generating the 'config' file on-the-fly anyway, but I'd need a method to know what-is-where. - should I avoid SunPKCS11 and base my program on simple PC/SC? I would say no. If you can code in C, it is better to use pure C PKCS #11 (or some helper like libp11 or pkcs11-helper), since working with APDU's is not easy (nor necessary). If you need to stick to Java, maybe JNI is the answer. I usually do C, but this time I need a java applet for: 1) a web-based password manager I have to write for the office 2) safely and strongly authenticate users to a plain HTTP page (very shared-hosting friendly!) -- I already can authenticate users w/ a smartcard (on https), but it needs Firefox to load its PKCS11 that locks the card and no other process can use it. I don't really like JNI since it usually needs uncommon client-side libraries, that's why I thought about pcsc (even if, after all, it's JNI anyway), since I already studied it and deps-wise it doesn't need anything more than the minimum. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
