Re: [opensc-devel] W3C takes on Web+SecurityElements
Il 03/10/2012 13:23, Anders Rundgren ha scritto: > What do you decipher from the following? > http://lists.w3.org/Archives/Public/public-sysapps/2012Jun/0058.html That Gemalto is interested in being an early player? :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 29/09/2012 09:01, Frank Cusack ha scritto: > I knew something that didn't need "trusted software" (in the PC) should > exist. And Finally I found it: > http://www.ftsafe.com/product/epass/interpass > Seems quite near to my idea of a "really-smart card": big display to > show transaction details and button to review/confirm/cancel (and, I > hope, to insert a gesture that replaces the PIN...). > Just evolve that a bit and it's perfect :) > I agree, it's close. Not that I've contacted them, but I doubt it's an > actual shipping product. I've already seen a smartcard that hosts a battery, a display and a button in a standard ISO form factor (it uses the sc chip to henerate an OTP every time the key is pressed), so 'technically' we're quite near to a card that shows anamount to be authorized and a "blinding factor" for the PIN (5 digits, to be added one-to one to the actual PIN, so snooping the keyboard is useless), or even having an integrated pinpad to enter the PIN w/o relying on an external device. Too bad that producing such a card would require a "big" rethinking (well, not "too big", since something already exists along that lines), and that costs quite a lot... EMV could surely do that, an hobbyist no (unless his name is Bill Gates). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 23/09/2012 12:04, Andreas Jellinghaus ha scritto: > > In my mind, the SE should take over display and touch controller by > > hardware means, so absolutely no app can snoop user input or fake it. > > Too bad seems nobody really *needs* that level of security... > The problem with that is that is impossible for a user to distinguish > between a real PIN dialog and a fake ditto. The SKS' "work-around" to > this particular issue is that there is an OS-based PIN dialog and that > keys can specify that they only accepts PINs through the system PIN > dialog > (trusted path). I knew something that didn't need "trusted software" (in the PC) should exist. And Finally I found it: http://www.ftsafe.com/product/epass/interpass Seems quite near to my idea of a "really-smart card": big display to show transaction details and button to review/confirm/cancel (and, I hope, to insert a gesture that replaces the PIN...). Just evolve that a bit and it's perfect :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 25/09/2012 11:50, Peter Stuge ha scritto: >> IIUC that bit is not authenticated, so a MITM attack can force both the >> reader and the card think the other party doesn't support PIN auth, >> making the card sign the transaction anyway, regardless the amount >> involved. So IMVHO it's quite serious... > http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf Tks. That's the (or one of) article I remembered but couldn't find... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 25/09/2012 07:58, Andreas Jellinghaus ha scritto: >> EMV for sure: there's an unauthenticated bit that tells the card to >> authenticate the transaction without asking for the PIN... > Thats ok, it is a valid feature. If people buy something for less than a > dollar, and the transaction is authenticated with the > signature of a rsa key in the smart card, and we haven't reached the > consecutive lower boundary amount yet, then simply > approving the transaction is perfectly fine - getting a PIN or doing an > online transaction isn't worth doing for such a small > amount of money. IIUC that bit is not authenticated, so a MITM attack can force both the reader and the card think the other party doesn't support PIN auth, making the card sign the transaction anyway, regardless the amount involved. So IMVHO it's quite serious... > Most vending machines still use modems and dial up for every transaction > and hang up again later. The stupid thing is that it seems they do the same for cellular-based readers too... What a waste! > Thats why card transactions are so slow. Once the standard is to have a > permanent internet connection, that won't change anything: many banks still use *mainframes* ! Some still backup to (and transfer data with) tape *wheels* ! (when we dismissed our IBM 9000, I think one of the tape units got sold to the bank...). As long as "it works", they don't change it. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 24/09/2012 21:37, Andreas Jellinghaus ha scritto:
> no, I was refering to all the magic solutions that make things secure
> suddenly.
there was a good comic strip I can't find just now...
Hackers view: oh, no, this laptop is protected by 4096-bit RSA... no way
we can recover it even with $100!
Grunt view: this laptop is locked... take this $5 wrench and beat off
the pass from the user.
Too bad it proves right... Here in Italy we've had many episodes of
people kidnapped to make their families let robbers enter well-protected
houses... :(
> Like sms-tan instead of pin+tan, or funny devices reading flickering
> info on some banks online system,
> or smart cards with biometrics on board, or
> $government-identified-super-secure-signing-cards or
> stupid "de-mail" (email with a postage cost of half an euro) which they
> try to sell in germany, and all this stuff.
Not to speak of italian "posta certificata" ("certified mail", with
provable delivery so that it can have legal value)... :)
> EMV is of course totaly bloated and thus far too complex, and the whole
> idea of visa and mastercard keeping
> paypass and paywave confidential, even partners under NDA only get to
> see their bits, that is real stupid and insecure.
Maybe because they know it's not secure?
EMV for sure: there's an unauthenticated bit that tells the card to
authenticate the transaction without asking for the PIN...
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 23/09/2012 11:52, Andreas Jellinghaus ha scritto: >> In my mind, the SE should take over display and touch controller by >> hardware means, so absolutely no app can snoop user input or fake it. >> Too bad seems nobody really *needs* that level of security... > like "credsticks" from scifi novels decades ago? that owuld be a single use > appliance, and I think easy to hack, similar how it is trivial to have a > chip recording keystrokes placed inside a laptop etc. and I guess a multi > app would be extreme complex and unlikely to be secure either. Nope. Speaking of SE in smartphones here :) You don't have much space inside a phone... Hopefully not enough to add a logger chip. And a phone is really much more "tamper evident" than a laptop... > hmm, a datasheat I found on smartmx for example does not mention a MMU. > I guess it is onl a software implementation in the java interpreter, and > that could be well faulty. Software-emulated MMU, then. Since it's so simple, it could well be worth the reduction in gates at the expense of a little longer run time -- but you are already running java, not optimized asm... > also how are things managed - how easy is it to setup things wrong? That should be impossible, if the card only allows fixed-size apps and went under throrought testing. >> Another question: if the applet manager is secure, then why change >> master keys before giving a card to customers? > cards go throug a pipeline of ~4 entities and everyone has his own secret [...] Uhm... Found. If the key was publicly known, a reseller could easily remove an applet and replace it with another using the same app id and the final user wouldn't be able to know. If only the card manager would allow a per-app removal key... >>> My new impression is I would only need to use a smart card key&cert with >>> one site only - my SSO provider. Thus a plugin for that communication >>> only would work well with me. >> As long as you can import/export your cert (better if keeping it >> protected by a password) then you can have quite good security using >> openid and an identity provider like startssl that authenticates you >> using that cert. > certs don't need protection, only keys do. and being able to export a key > is always a bad idea. Unless you either can set up a multi-party RSA system or have another way to recover a damaged key. If exporting keys is always such a bad idea, then why root-CAs export theirs? Simply to have a backup and obtain business continuity in case of HSM failure. > it is much better to be able to get a new cert&key whenever you want on > demand. e.g. enter your credentials > (password, pin, tan, fingerprint, retina scan, secret handshake, whatever > you think is secure) and then get/generate > a new keypair and CSR and get the signed cert. Unless you run a CA. :) > as for openid, I thought there was some discussion about it - v1 too > complex, not much agreement on v2 or so? Complex? Seems quite easy... >> Always too many things under NDA or plainly unavailable, too often >> starting from comm specs... comm=communication , sorry. > common specs? I rather wonder: everyone invented something on his own, and > when a standard came around, any change would break compatibility and more > important require new certification rounds, thus would be expensive, thus > everyyone preferred to not implement the standard. after all who wants to > give users the choice to switch vendors? very bad idea, vendor lockin is > king, I'm still waiting for ACS to tell me something about how can I use my cryptomate64 token. I could have its "reader" recognized, but ACOS5 protocol is still unsupported (I found a project, but it seems still in its early stages...). > other java cards than JCOP. And JCOP again is a prime example of a NDA > thing, not a standard, right? or did it improve? I have some JCOP cards, but just lately I found how to authenticate with the card manager using Alexander Petric's hints for gpshell. If I have't to sign NDAs to develop my own applets and load'em on card, then for me it's "open enough". But I still don't know if I have enough info (for example: how do I handle RSA crypto? I hope there's a library with public API for that...). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 22/09/2012 19:37, Anders Rundgren ha scritto: >> In my mind, the SE should take over display and touch controller by >> hardware means, so absolutely no app can snoop user input or fake it. >> Too bad seems nobody really *needs* that level of security... > The problem with that is that is impossible for a user to distinguish > between a real PIN dialog and a fake ditto. The SKS' "work-around" to > this particular issue is that there is an OS-based PIN dialog and that > keys can specify that they only accepts PINs through the system PIN dialog > (trusted path). That's quite easy to avoid: once the SE takes over the display, it can prompt the user with an user-supplied message . Visa is doing something similar with "securecode auth": when you're doing a payment, you get redirected to their site, where you see a personalized prompt and have to enter another password. If you don't see your own prompt, you don't enter the password.. > If the user is presented a spoofed PIN dialog, the attacker may indeed get > the PIN. However, the attacker must also take the device as well in order > to use it which makes the attack much less useful. The only drawback would be that if the attacker, after stealing the phone and hacking it to include the right message in the spoofer, returns it to the legit user, waits for the spoof to intercept the PIN and then steals it again... Quite unlikely :) and easily detectable: if your phone "disappeared", change the prompt before connecting again to the payment service: if you still see the old prompt, better to reflash the phone and change *all* your passwords. > If the OS is hacked this doesn't help but it seems that this is not > the biggest problem with mobile devices; it is rather determine what > an app should be able to do or not. If SE takes over HW access (this could include accelerometers, since they could be used to infer where the user is tapping -- paranoid enoug?), then it can be secure even if the OS got hacked. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Technical Description - Android Embedded SE
Il 22/09/2012 12:41, Andreas Jellinghaus ha scritto: > In my mind keys could optionally contain application-oriented ACL > telling which > applications they trust so that even if you install a "bad" App, it > would for > example not be able to use your bank or eID-key in the background. In my mind, the SE should take over display and touch controller by hardware means, so absolutely no app can snoop user input or fake it. Too bad seems nobody really *needs* that level of security... > I must admit I don't know how many apps are managed and seperated. given > the restricted resources a smart card has, Think about how an MMU works: it keeps a table of "pages" assigned to an app, and maps 'em in app's address space. An app have no way to access a page outside its allowed address space. Nothing secret, here, and doesn't require great resources. > I only remember seeing code that would change master keys and put one > app into a card, thus never bothered how it works in detail or how to > manage resource, secure apps against each other etc. Also I wonder: does > the vendor claim to have the security thight enough to prevent a hostile > app from accessing data of another app? Or is it the usual "all is > secure", but we don't tell how it works, > how to use it, and make no real guaranties anyway? Another question: if the applet manager is secure, then why change master keys before giving a card to customers? > My new impression is I would only need to use a smart card key&cert with > one site only - my SSO provider. Thus a plugin for that communication > only would work well with me. As long as you can import/export your cert (better if keeping it protected by a password) then you can have quite good security using openid and an identity provider like startssl that authenticates you using that cert. > Not sure what to do about phone theft though - I really fear putting all > the access credentials into one basket (my phone), plus a lot of > personal information, so any thief would be able to > impersonate me and access my mail, documents, banks, and much more. For this I simply use keepass w/ its db synced over dropbox (and backed up offline in multiple places). Obviously a thief wouldn't have my master password, so the access to the db would be useless. > In summary: my old expectations how to secure communication and use > smart cards in them have gone many months ago, now I see the "world" > very differently. My adventures into smart card business also make me > wonder if trusting such an industry is a good thing. Always too many things under NDA or plainly unavailable, too often starting from comm specs... BYtE, Diego. ___ 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=product&prod_sections=0&id=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] Secure Credential Cloning. Was: Intel's Virtual Smart Card
Il 19/08/2012 15:50, Anders Rundgren ha scritto: > Everything you write is fine and probably correct as well. > The only "fly in the soup" is that *it is not happening*. I think it will be just like the TPM: when enough people will realize what it is, it won't get accepted by the public. It's not long since "restricted boot" 'failed' and memory isn't so short. > The smart card community has failed creating a cheap a readily > available token that can be provisioned on-line while for example > iPhone and Android already ships with built-in enrollment software. It's still WIP: look at OpenKMS... > However, there will always be a small market that prefers something > special. That's for sure :) > I'm rather talking about the 99.999% that believes cost and availability > matter. I also think that the poor GUI support offered by smart cards > will make these look quite dated compared to virtual smart cards having > cool logotypes and stuff. SCs *are really* dated as concept. Old, messy interface, conflicting high-level "standards" (so many that everybody uses his own)... That's why a token or even a small "calculator format" w/ USB connectivity (and a standardized 'KISS' interface over the USB bus) would be better. Such a device could easily cost less than $100 (you can already find Android tablets w/ 7" display and cap ts at about $65, with wifi or even GSM connectivity! -- probably the only really needed piece of software needed could be a driver to use the SIM reader as a CAD, plus some "glue"). BYtE, Diego. ___ 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 19/08/2012 10:14, Anders Rundgren ha scritto: > Virtual smart cards have unlimited capacity and doesn't occupy space in > your pocket either. Then an USB token paired with some form of "unsecure" storage and have RSA capabilities and a button or a small keypad (display w/ touchscreen?) to enter consent/authorization code in a way that can't be intercepted/forged by software would be even better. The "unsecure storage" could be easily encrypted under a private key that then gets encrypted under any number of "token public keys", so no "single point of failure" exists and that storage can easily be shared/copied to any number of tokens. (IIRC, something along this line should/could be in next OpenPGP token). This way you would have benefits of both virtual (practically "unlimited" number of certs/keys: if you use a 32G uSD as storage you'd have to spend your life receiving certs before filling it...) and real smart cards (bring it wherever you like, having full control). If such a token would be issued by govs (so coming with a "universally trusted" cert to certify that extra keys are generated by the token), it would be the really universal "card". I don't like those "vendor lock-ins". Maybe I saw too many burnt mobos, or just 'cause I prefer AMDs :), or simply it seems another way to introduce "crippled boot feature" and have users be happy with that (a "virtual smart card", implemented in SW, requires some form of "certified boot", so it only works with a "certified OS"), or reintroduce the dear old TPM (that have been cracked[1], BTW)... On the other hand, a token/card is platform-agnostic... [1] http://www.computerworld.com/s/article/9151158/Black_Hat_Researcher_claims_hack_of_chip_used_to_secure_computers_smartcards BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial support for SmartCard-HSM
Il 06/08/2012 10:15, Andreas Schwier ha scritto: > the name's just a name ;-) Probably he (like me) hoped it was something more like (would-be) MicroCA: a card taking a CSR and outputting a cert if constraints are satisfied... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Prompt for SO PIN in Firefox
Il 23/07/2012 08:49, helpcrypto helpcrypto ha scritto: > IIRC, C_Login can accept user type CKU_SO to login as admin, the > problem might be "what you could do as admin". Probably that depends > on the card. The problem with FF (and TB) is that it calls C_login only once, then assumes the login is still valid. Even if card got reset. Even worse, it asks for *ALL* PINs when the token gets added. That made me give up having pkcs#11 enabled in FF/TB. IIRC there are a couple of bug reports in bugzilla, but seems they won't get fixed. "Friendly token" (or something similar...) setting helps a bit, but IMO it remains unsafe to have a token accessed by FF. BYtE, Diego ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CRYPTOMATE64
Il 12/06/2012 10:05, Ludovic Rousseau ha scritto: > Your device is not know by pcscd because it is not support by my CCID driver. > The first step is to follow > http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant Tks to Ludovic I've been able to get a first answer from the token: $ pkcs11-tool --module /usr/lib64/opensc-pkcs11.so -L Available slots: Slot 0 (0x0): Gemalto GemPC Twin 00 00 (empty) Slot 1 (0x4): ACS CryptoMate64 01 00 (empty) So reader seems recognized. Now, when trying "pkcs15-tool -D", I have: APDU: 00 CA DF 30 05 2025 SW: 6E 00 > Class not supported (???) 00274375 APDU: 00 A4 04 00 05 A0 00 00 00 01 00013943 SW: 69 86 > Command not allowed 00279813 APDU: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 3326 SW: 69 86 > Command not allowed 00279168 APDU: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00012787 SW: 69 86 > Command not allowed 00274885 APDU: 00 C0 00 00 00 > "get_response"? to a "command not allowed"? ??? 00016464 SW: 32 C0 6C 41 7A C0 17 42 90 CB 12 59 91 00 A6 FE 54 D9 6C 62 F4 4B 32 0E 64 FF 06 EA FF 91 06 1A FE 4E 98 F5 A0 44 31 D1 BB 5E 90 C1 E4 F4 0D 38 FE 69 42 90 DF AE 9C D4 1F 51 32 C4 A9 6B D1 14 4E A4 4C 06 A6 FE 92 DF 71 7E 90 C7 B7 62 C4 B8 5B 91 C9 17 61 43 92 C1 3C 8F BF 7C 91 D1 16 61 A3 84 CB 6D 89 31 04 BB FE 92 7B 6C 35 90 C4 BB 77 91 08 E6 FE 5B B4 54 E9 9F 32 00 A1 FE C3 38 F9 58 13 4C 90 D0 67 5A 7B 39 47 31 CE E3 8A D5 66 5A A2 F8 92 75 B4 52 75 A1 89 31 D8 2B FE 05 21 FF D1 34 F9 C9 6F 7E AF 92 C8 68 98 32 D2 AA 5F 07 36 FF B5 74 90 05 1D FE C8 E3 4E 90 00 B7 FF 77 C5 BA 74 96 C7 23 FF 91 C2 1D 7E CE 1B 7E A0 43 32 D1 E8 82 08 19 FF 5E E6 AF 62 AD FE A8 7A 06 E5 FE 91 C1 21 FE 03 A2 FF DB 2A FF 4A 38 47 C9 6F 96 55 A0 85 91 75 E0 61 90 D3 1B FB C5 90 00 > OK. 00272668 APDU: 00 A4 08 00 02 2F 00 2742 SW: 69 86 > Command not allowed Any hint? In the meantime I'm building a VM to experiment better. Tks, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CRYPTOMATE64
Il 23/05/2012 15:12, Joemar Mante ha scritto: >> Someone already tested that token? It's the only one I could find that >> handles RSA4096... >> http://www.acs.com.hk/index.php?pid=product&prod_sections=0&id=CRYPTOMATE64 Finally arrived -- shipment got "lost" and took quite a lot :( > I have worked with ACS before handling products related to ACOS5/ACOS5 64K. > Though we have not any test with open-sc using this particular card. Are > you using it via a PKCS#11 middleware? Trying to use opensc and openssl to handle it. All I could obtain from it is: [root@jago media]# pcscd -afd debuglog.c:265:DebugLogSetLevel() debug level=debug 0114 configfile.l:245:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 0025 configfile.l:287:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/GemPCTwin-serial.conf 0046 pcscdaemon.c:518:main() pcsc-lite 1.8.2 daemon ready. 2208 hotplug_libusb.c:421:HPEstablishUSBNotifications() Driver ifd-ccid.bundle does not support IFD_GENERATE_HOTPLUG. Using active polling instead. 0058 hotplug_libusb.c:430:HPEstablishUSBNotifications() Polling forced every 1 second(s) (now I plug it in) [1635886.755035] usb 6-1: new full speed USB device number 14 using uhci_hcd [1635886.919253] usb 6-1: New USB device found, idVendor=072f, idProduct=90db [1635886.919258] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1635886.919261] usb 6-1: Product: CryptoMate64 [1635886.919264] usb 6-1: Manufacturer: ACS (nothing gets printed by pcscd) [ndk@jago ~]$ pkcs11-tool --module /usr/lib/opensc-pkcs11.so -L Available slots: Slot 0 (0x): Virtual hotplug slot (empty) (pcscd prints the following lines) 96781613 winscard_msg_srv.c:230:ProcessEventsServer() Common channel packet arrival 0037 winscard_msg_srv.c:242:ProcessEventsServer() ProcessCommonChannelRequest detects: 4 0173 pcscdaemon.c:93:SVCServiceRunLoop() A new context thread creation is requested: 4 0149 winscard_svc.c:297:ContextThread() Thread is started: dwClientID=4, threadContext @0x8d86f20 0019 winscard_svc.c:315:ContextThread() Received command: CMD_VERSION from client 4 0084 winscard_svc.c:327:ContextThread() Client is protocol version 4:2 0095 winscard_svc.c:347:ContextThread() CMD_VERSION rv=0x0 for client 4 0163 winscard_svc.c:315:ContextThread() Received command: ESTABLISH_CONTEXT from client 4 0092 winscard.c:193:SCardEstablishContext() Establishing Context: 0x1030AAC 0015 winscard_svc.c:408:ContextThread() ESTABLISH_CONTEXT rv=0x0 for client 4 0156 winscard_svc.c:315:ContextThread() Received command: CMD_GET_READERS_STATE from client 4 0125 winscard_svc.c:315:ContextThread() Received command: CMD_GET_READERS_STATE from client 4 0570 winscard_svc.c:315:ContextThread() Received command: RELEASE_CONTEXT from client 4 0019 winscard.c:204:SCardReleaseContext() Releasing Context: 0x1030AAC 0090 winscard_svc.c:423:ContextThread() RELEASE_CONTEXT rv=0x0 for client 4 0774 winscard_svc.c:307:ContextThread() Client die: 4 0023 winscard_svc.c:918:MSGCleanupClient() Thread is stopping: dwClientID=4, threadContext @0x8d86f20 0085 winscard_svc.c:924:MSGCleanupClient() Freeing SCONTEXT @0x8d86f20 So it seems Cryptomate64 is *not* (yet, I hope...) supported :( Is there something I can do to make it supported? Tks. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SO pin in pkcs11-tool?
On 30/05/2012 11:42, Alon Bar-Lev wrote: > PKCS#11 is weak in term of privileges, not always it is possible to > access the complete feature set via this interface without proprietary > extensions. IIRC, that's why profiles are needed when you use the card, not only when you initialize it, right? But shouldn't a copy of the ACLs be stored in PKCS15 metadata so it's parseable after init w/o requiring the profile? And shouldn't SO-PIN be just another PIN (on MyEID card it have id ff, on others cards it might be different) so that you can specify it in profile? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACR122U + MyEID dual interface
Il 25/05/2012 11:51, Aventra - Hannu Honkanen ha scritto:
> ACR122U reader gives a different ATR than a contact reader for the same dual
> interface card but otherwise the reader works just like a contact reader
> with PKI cards. If you force usage of the myeid driver, it should work.
Perfect. I'll *try* not to brick another card, this time. I promise. :)
> There is an API specification for the reader available at ACS's website, ATR
> generation is explained there:
> http://www.acs.com.hk/drivers/eng/API_ACR122U_v2.01.pdf
That's the one I used to "decode" Mifare ATR.
> Maybe we should add this ATR to card-myeid.c. Could someone with access to
> the sources help and modify it like this?
> static const char *myeid_atrs[] = {
> "3B:F5:18:00:FF:81:31:FE:45:4D:79:45:49:44:65",
> "3B:F5:18:00:00:81:31:FE:45:4D:79:45:49:44:9A",
> "3B:85:80:01:4D:79:45:49:44:78",
> "3B:89:80:01:09:38:33:B1:4D:79:45:49:44:4C",
> NULL
> };
For now I'll edit my local copy, so I can use it.
BTW couldn't it be better to keep ATRs in a config file?
> The last ATR is from another version of ACR122U. I think it is possible to
> affect the way the ATR is generated by altering the "PICC Operating
> Parameter" of the reader. BTW, bytes 4D:79:45:49:44 which are present in all
> of the ATR's are the text "MyEID".
That's what made me think
>> Is it possible to make that reader handle multiple cards "in parallel"
>> (both placed on the reader)?
> I don't think it is possible and haven't tried it, but ACS lists "Built-in
As usual I like pushing things to their limits... :)
> anti-collision feature (only 1 tag is accessed at any time)." as a feature
> of the reader. It probably means that the reader selects one card and
> ignores others in its range. Even if that would be possible by hardware, I
> don't know how you could access multiple cards in the same reader through
> PCSC.
The idea would be to use different slots. But there's a problem
(probably): when you send HaltA to a card, login status gets lost, like
it's been extracted (well, the app is yours and probably you could make
it keep the state between HaltA and wakeup, since it's still receiving
power...).
PS: any way to define a sign pin (so that it have to be re-entered after
each crypto op -- useful with pinpad readers)?
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CRYPTOMATE64
Il 25/05/2012 10:59, Martin Paljak ha scritto: > Hello, > > On Wed, May 23, 2012 at 2:57 PM, NdK wrote: >> I'm thinking to use one to store our internal root CA's key (4096bit >> RSA). [actually I'm thinking more about a "ring of roots", but that's >> another story] > Care to share the story? Yup. Sure. A bit OT, but I'll try to keep it terse. It's just an idea, still have to test it. Might be that it pushes cert parsing "over its limits". I'm assuming the chain checking is stopped as soon as a trusted cert is found. It's based on good old FidoNet routing: - 3 'root' CAs - Every CA is root for only one of the other two - the 'root' CAs are equipotent. - there's no self-signed certificate - users choose to trust one, two or three of the 'root' CAs (the more the better and faster verifications). Say CAs are A, B, C. A's cert is signed by B, B's cert is signed by C and C's cert is signed by A. Worst case: the user chose to only trust B and connects to an intranet http server. He's presented a cert signed by C.C1s.C1www (C signed C1s' cert delegating 's'ervers and C1s signed C1www's cert delegating http servers certs issuance). Then cert chain is checked: site, C1www, C1s, C and finally A that, being signed by B validates all the chain. If the user chose to trust A and C too, then last two steps could be avoided, omitting costly verifications with large keys. This makes the system quite scalable, with a tradeoff between number of root certs to store and (computational and network) resources used to verify received certs. This schema 'requires' (unless you want to change all root-CAs certs quite often) quite a static root set, so it's not for "general" use (say between different CAs). But I think it could well accomodate our needs. Any evident pitfalls? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACR122U + MyEID dual interface
On 24/05/2012 18:33, Ludovic Rousseau wrote: > ACS forked my CCID driver. I got no contract with ACS. Argh! > Your "ACS ACR122U PICC Interface" reader should work with my CCID driver. Seems so. Might be useful to look at the differences? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACR122U + MyEID dual interface
On 24/05/2012 17:56, NdK wrote: Found some docs. Actually the reader's docs from ACS, that seems really well-written (API_ACR122U_v2.01). > BTW for the other ATR > (3b:8f:80:01:80:4f:0c:a0:00:00:03:06:03:00:01:00:00:00:00:6a) > I already found: it's a Mifare One card (just tested with others I had > around). 3b : initial header 8f : t0 80 : td1 4f : td2 80 : t1 4f : Tk: Application identifier presence indicator 0c : Tk: length a00306: Tk: registered application provider identifier (RID) 03 : Tk: standard (14443-*3*) 0001: Tk: card 'name' * : RFU 6a : tck (xor from t0 to Tk) Card name: 0001: Mifare 1K 0002: Mifare 4K 0003: Mifare ultralight 0026: Mifare mini f004: Topaz and Jewel f011: FeliCa 212K f022: FeliCa 424K ff: SAK (undefined) Maybe it's worth updating ATR table. HIH. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACR122U + MyEID dual interface
On 24/05/2012 15:39, Martin Paljak wrote: >> Too bad the cards aren't recognized by default: >> $ opensc-tool -a -n >> Using reader with a card: ACS ACR122U PICC Interface 00 00 >> 3b:85:80:01:4d:79:45:49:44:78 >> Unsupported card > I'm not certain about all ACS products, but one of the 122 reader > marketed as tikitag/touchatag is CCID, but it requires a special APDU > wrapping to actually talk to the RF interface. Maybe this reader is > similar. I think this one is well supported: its driver sources have 'rousseau' in nearly all headers :) Seems Ludovic got a contract with ACS (I hope for him) in 2009... If I insert one of the cards in the contact reader, I get the same ATR as standard MyEID cards: $ opensc-tool -a -n Using reader with a card: Gemalto GemPC Twin 00 00 3b:f5:18:00:00:81:31:fe:45:4d:79:45:49:44:9a MyEID cards with PKCS#15 applet But (obviously) if I place it on NFC reader I can't use it: $ pkcs15-init -C --pin --puk Using reader with a card: ACS ACR122U PICC Interface 01 00 Couldn't bind to the card: Not supported Is there any way I could "force" pkcs15-init in recognizing it as myeid (like "-c myeid" for pkcs11-tool)? BTW for the other ATR (3b:8f:80:01:80:4f:0c:a0:00:00:03:06:03:00:01:00:00:00:00:6a) I already found: it's a Mifare One card (just tested with others I had around). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] ACR122U + MyEID dual interface
Hi all. Just received $subj and started testing. Too bad the cards aren't recognized by default: $ opensc-tool -a -n Using reader with a card: ACS ACR122U PICC Interface 00 00 3b:85:80:01:4d:79:45:49:44:78 Unsupported card Is it only matter of unknown ATR and I can safely use force myeid? Or should I add support for 'em digging in the code (for this, help from Aventra would be really welcome -- big task!). Is it possible to make that reader handle multiple cards "in parallel" (both placed on the reader)? PS: the card in "MyLogin for Windows" kit reports an ATR of 3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A Does someone know something about this card? Tks, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CRYPTOMATE64
On 23/05/2012 15:12, Joemar Mante wrote: > I have worked with ACS before handling products related to ACOS5/ACOS5 > 64K. Though we have not any test with open-sc using this particular > card. So the only way is to buy it and try... Worst case: about 50€ wasted. Best case: a good token. In the worst case: have ACS been collaborative in the past, supplying info to add support? > Are you using it via a PKCS#11 middleware? I'm going to order it, but I'd prefer to have something usable :) I'd use it from XCA or openssl. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CRYPTOMATE64
On 23/05/2012 20:18, Peter Koch wrote: > Someone already tested that token? It's the only one I could find that > handles RSA4096... > So does the OpenPGP card and the CryptoStick (which contains that card) I evaluated it, but it's *currently* usable only from GPG. And the info I found said it could handle 3 keys up to 3072bits. I still have to understand the whole "subkeys" concept, but haven't yet actually started digging it. Maybe, tks to the work of Nguyễn Hồng Quân et al, it'll be the next token I'll get. Or, more probably, I'll wait the new version. :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] CRYPTOMATE64
Hello all. Someone already tested that token? It's the only one I could find that handles RSA4096... http://www.acs.com.hk/index.php?pid=product&prod_sections=0&id=CRYPTOMATE64 I'm thinking to use one to store our internal root CA's key (4096bit RSA). [actually I'm thinking more about a "ring of roots", but that's another story] Intermediate CAs will use other cards/tokens (still undecided between Aventra's MyEID and Gooze's ePass2003 token), that are way cheaper and up to the job :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] BT reader
Il 22/05/2012 14:32, Martin Paljak ha scritto: > Regarding PIN codes, communication is protected with AES, in addition > to BT pairing. How does the AES key exchange work? 'cause it's the weak link... If the attacker can obtain the AES key (for example if it's printed on the unit and the attacker could see it), then it's the same as cleartext. BYtE, Diego ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] BT reader
Il 21/05/2012 14:11, helpcrypto helpcrypto ha scritto: >> http://ubertooth.sourceforge.net/ about ~100 EUR including shipping. > how do you insert the smartcard there?...and how to connect it to the > android/iphone? You don't. It's useful to mount an attack against any BT sc reader (if sc doesn't support sm, or reader doesn't implement some extra security over bt). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] BT reader
Il 21/05/2012 10:50, j.witvl...@mindef.nl ha scritto: > Anyone around who had the chance to look at > http://www.biometricassociates.com/products-baimobile/smart-card-reader-iphone-android.html > I know that there exist for some time BT-readers, but those from RIM present > themselves only as a `rim` device. Urgh... I wouldn't use a BT reader unless the card uses SM. It's trivial, if you sniff the pairing, to decode the whole BT traffic. And non-SM cards receive the pin as cleartext. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Biometric integraiton?
Il 26/04/2012 12:22, helpcrypto helpcrypto ha scritto: >> If you can edit a root file you can do anything much more evil. > having root acces < having pin => using private key Just install a keylogger (maybe an HW one on the PS/2 cable? I've seen one that is quite hard to recognize... or even one INSIDE the keyboard...) and root (or user w/ physical access to the computer... that quite easily translates to "root" anyway) knows your PIN. Simply put, you can't make it secure, regardless of the effort you place in it. The best you can obtain is to design it in a way that who have physical access to it, is the party interested in keeping it secure. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Biometric integraiton?
Il 26/04/2012 11:32, helpcrypto helpcrypto ha scritto: > and, what if i edit your current config and replace the lib with my > modified evil lib? And what if I replace the trusted reader w/ another, hacked? Not too hard, it seems, since many supermarkets got hacked this way... The only really trusted method (for the user) would be a card with integrated display and pinpad and/or fingerprint sensor. Maybe impractical for a card, quite feasible for a token (there already are thumb drives with fingerprint reader and matcher that doesn't require SO support except for mass-storage). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Ownership issue and consequences on OpenSC project
On 23/03/2012 19:10, Peter Stuge wrote: > The problem is not that the code can not be reviewed, but that noone > is doing review. Anyone can do it. I'd do reviews, but the last time I tried to really understand OpenSC's flow, all I got was an headache (a big one...) :( So it's not a will issue, it's more an understandig issue. At least for me. And I'd really like to be able to help, but it seems only a handful of people fully understand code flow... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Managing devices simultaneously
Il 21/03/2012 11:27, Szabó Áron ha scritto: > What is the maximum number (if any exists at this level) of regular smart > cards, USB tokens (and keys) that can be used and managed by OpenSC in the > same environment (USB controller supports up to 127 devices, up to seven > tiers, including the root tier and five non-root hubs)? IIUC, each "PIN" uses a slot. So, for example, on a single Aventra card you could need 14 slots! BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] proving a key is on a smart card
Il 19/01/2012 09:16, Peter Stuge ha scritto: > Christian Hohnstaedt wrote: >> Anything that can be signed by the card can be signed by a software >> key, too. > Yes of course. But the point is that the card can come with the > special key pre-installed. I see at least two ways here: 1) the 'technical' way: have a card that, when issued (= before being given to the user), already contains a cert for a key generated on-card. When the user requests a new cert, the old (referencing the same private key) must be included as a proof (actually, the 'public key' part could be taken from this cert, simplifying CSR that could even be a simple web form for the other infos). 2) the 'legal' way (might not be applicable everywhere): when the user submits a CSR, (s)he must swear that the key have been generated on-card and is not extractable It's the usual chicken-and-egg problem. :) PS: a doubt just popped in my mind: can I store multiple certs for the same private key? How? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSSL OpenSC PKCS11 engine integration with 2 smart cards
Il 16/01/2012 07:29, Scott Thomas ha scritto: > I am using Cryptoflex e-gate v4 32k card which contains 8 slots for > certificates. I have tried slot0-id_45 to slot7-id_45. > On slot 0 it works fine but from slot 1-7 it gives error of empty slot > which means that other 7 slots will must work fine > but if i try slot 8-onwards, it gives error of invalid slot number by > which it can be assumed that it does not work with 2 cards in this way. Nope. IIUC, "slot" means "PIN" (or "authentication method"). You "log in" to a slot and then can use all the keys in that slot. So your card could easily have just one slot, containing up to 8 keys and certs. IIRC Aventra MyEID cards can handle 14(15?) different PINS (plus SO-PIN), so they could need 15 (or 16?) slots to be fully used. In pcscd.conf you can define how many slots are available for each reader and system-wide. IIRC by default you should have 4 slots for each reader and up to 4 readers. So, in your case, to use the key w/ ID 45 on the second card you should use slot5-id_45... unless having keys with the same ID confuses the system, even if they're in different slots. Try: $ pkcs11-tool --module /usr/lib/opensc-pkcs11.so -L -T BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Slowness opening card
On 21/12/2011 19:59, Peter Stuge wrote: > NdK wrote: >> But I noticed that lastly every command is sluggish. > .. >> Is there something I should check or some more debugging I should enable? > > Probably libusb bug #56 which has been fixed but not available > everywhere just yet. What distribution do you use? Mandriva Cooker. I didn't see the error -121 in dmesg that IIUC should be symptom of libusb bug 56... Anyway I tested replacing my libusb and it seems it resolves the issue. Conclusion: test w/ fixed libusb anyway :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Slowness opening card
Hi all. Being on vacation I could finally resume my experiments. But I noticed that lastly every command is sluggish. Running "pcscd -f -d" I could pin down the slow op to the SCardConnect: 0028 Card ATR: 3B F5 18 00 00 81 31 FE 45 4D 79 45 49 44 9A 0007 winscard.c:328:SCardConnect() powerState: POWER_STATE_INUSE 0006 prothandler.c:128:PHSetProtocol() Attempting PTS to T=1 0036 ifdhandler.c:695:IFDHSetProtocolParameters() protocol T=1, usb:08e6/3437:libusb-1.0:7:2 (lun: 0) 0009 ifdhandler.c:1863:extra_egt() Extra EGT patch applied winscard.c:406:SCardConnect() Active Protocol: T=1 0051 winscard.c:426:SCardConnect() hCard Identity: 12663 0010 winscard_svc.c:443:ContextThread() CONNECT rv=0x0 for client 4 0152 winscard_svc.c:314:ContextThread() Received command: CONTROL from client 4 It's obviously the line with all those 9. But that's not fixed. On another run it hung on 60079903 winscard_svc.c:598:ContextThread() TRANSMIT rv=0x0 for client 4 [maybe that could related to having opensc-pkcs11.so loaded both in FF and TB, but slowness remains]. $ time pkcs15-tool --list-pins Using reader with a card: Gemalto GemPC Twin 00 00 PIN [Security Officer PIN] Object Flags : [0x3], private, modifiable ID : ff Flags : [0xB0], initialized, needs-padding, soPin Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 3 Type : ascii-numeric PIN [Card Auth] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x30], initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 1 Type : ascii-numeric PIN [User Auth] Object Flags : [0x3], private, modifiable ID : 02 Flags : [0x30], initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 2 Type : ascii-numeric real4m0.982s user0m0.000s sys 0m0.004s And attached is the full output of pcscd for that run: I'm now using opensc-0.12.1 and lib64pcsclite-1.6.6 (packages from Mandriva Cooker). Same card (Aventra MyEID) and same reader (Gemalto GemPC Twin) worked OK some months ago (with 0.12.0). Is there something I should check or some more debugging I should enable? BYtE, Diego. pcscd-slow.log.bz2 Description: application/bzip ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Experiences with Java smartcardio
On 23/11/2011 22:44, Douglas E. Engert wrote: >> javax.smartcardio.* = Total crap IMNSHO. IMVHO: Java and smartcards don't work really well together... > Does this help: > http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunPCSCProvider > "The system property sun.security.smartcardio.library may also be set to the > full > filename of an alternate libpcsclite.so implementation." I remember seeing more problems than advantages. The bigger one is that it tries to handle SCs as a Java KeyStore. So no publicly readable objects. And needs to have ALL the card keys. And quite a granitic config system. And so on. I gave up for the moment. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] About OpenSC PKCS#11
Il 09/11/2011 18:39, Viktor Tarasov ha scritto: > I would like to 'touch' the PKCS#11 module of OpenSC and looking for your > opinions/suggestions about: Regarding "touches"... Is some level of restructuration planned? I'm thinking about something object-oriented, a-la GTK+ (OO C, not C++). I'm sure it could attract more developers (at least I'd try again to get involved) and simplify adding features (as long as the internal API is well-planned)... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ISO's "new" Smart Card Middleware: 24727
On 14/10/2011 12:34, Tomas Gustavsson wrote: > There was still mentioning about smart card middleware in the article. I > didn't quite get it, but anything that still requires installation of > different middle-wares for different cards does not bring us much closer > to a "token enabled" world imho. Well, as long as you use 24727-compliant cards you can have only one middleware installed. Surely someone will be able to misinterpret specs so that incompatible cards will appear... but that's another story. The (not-so-)"bad" thing is that it won't map well on pkcs-11, so many programs will need a different middleware... I hope that finally Firefox will work "as expected" :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ISO's "new" Smart Card Middleware: 24727
Il 14/10/2011 08:11, Anders Rundgren ha scritto: > http://www.ecsec.de/pub/2007_TrustBus.pdf > http://openidtrustbearer.wordpress.com/2009/12/11/first-impressions-of-isoiec-24727 > > Is this for real? Seems so. Maybe could even help opensc: many card drivers could be grouped as one. The resulting structure could be quite cleaner and understandable even for who misses a "global view" (like me...). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC in multi-thread
On 09/09/2011 21:22, Douglas E. Engert wrote: > One possible way would be to turn off some drivers > in the opensc.conf file. Comments and an OpenSC web > page would say how to turn it back on, and how to request > that it not be dropped. The only way that works: break it in a way that requires user intervention. When in office you don't exactly know who is using some service, disable it and listen to complaints :) If (after some time) nobody complains, then nobody is using it and you can remove. Maybe that code could rot for about a year before being removed. Better if a page with instruction on how to reenable it is created FIRST, then the drivers get disabled only when it have been indexed by search engines. Comments in config file should tell packagers *not* to reenable those drivers by default... If some1 is still using those drivers, it *must* be considered a regression. Just my .02 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 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
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
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 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
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
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
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,
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
[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] OpenSC shared mode
On 06/05/2011 21:23, Juan Antonio Martinez wrote: > Sure: there are some cases where these approach fails: > SSL renegotiation when signing applet is running; two pkcs11 > trying concurrent access to the card... but this is not > as usual as thought. IMHO you could avoid troubles using a simple state machine: when the "server" sends a command to the card, it sets a busy flag to prevent access from other apps. Once card answers (could take a long time, like when generating an RSA key, but since card is actually "in use" there's no way to avoid it) a timer is started. If another command comes in from the same client, timer gets reset and cycle starts again. If no command is received before timer expires, then card is reset and busy flag is cleared. This way you can be sure that only an active app keeps control of the card. For example, for Firefox it will be like a card removal. It should reread it anyway (maybe a cert got added...). In your example, SSL renegotiation (or signing app) would be delayed the time needed to complete the other operation. An hung app could not lock the card for others. The only drawback I see is that no user intervention is possible during a command sequence: you can't stop to ask PIN, you have to know that a PIN is needed (by parsing PKCS#15 structs or by issuing a crypto op), ask for it and restart sending commands from the beginning. Unless (maybe) if reader comes with a pinpad and its "read PIN" is atomic (that is: no answer till user enters PIN). Or maybe I'm completely gone... :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Profiles
On 29/04/2011 15:35, Viktor TARASOV wrote: >>> From your point of view, where the UPDATE access to 4402 and friends >>> should be defined ? >> Since UPDATE refers to an existing object, it belongs to that object. > 4402 is not an object that can be described by PKCS#15, it's the PKCS#15 > itself -- AODF descriptor of the PKCS#15 structure. Uh, OK. I didn't study PKCS#15 yet... just a really quick glance. Then it have to be (at least) readable. Like 3F00 and 5015 :) All other objects, on a properly "formatted" PKCS#15 token, should be described by AODF or other "standard" files. So it should be enforced that ACLs are set only when creating a new filesystem and not taken from profile every time. > The only place where its UPDATE access is defined (beside the file's FCP) is > the profile. Then it should be defined statically: no room for playing, here. >> But CREATE, being referred to a non-existing object, should belong to >> container (parent) object. > Once more, parent is not an PKCS#15 object. But we know we are working on a PKCS#15-formatted card. > If 'SELECT' parent do not return FCP data, there is no way to get the real > ACLs. Unless they're stored in another object we know something about. > The only hope is that the profile settings correspond to the real (hidden) > ACLs. We can *require* that access conditions stored in object metadata match the ones stored in PKCS#15 files by doing it ourselves, at least for newly-formatted cards. Using just pkcs15-init (and maybe pkcs15-tool), it must not be possible to create an object whose ACL is different than the one stored in metadata EFs. As it is now, it's possible (gone there, done that). >> It's not "good" that problems arise if I create a card using >> pkcs15+onepin and a user creates a key using just pkcs15 profile! > It's up to you to educate your users. Sure, but you can see that it gets completely unmanageable when you have many users (haven't had discussions with some university professors 'that are always right'? Lucky you! :) ). > Once more, actually, the pkcs15init is designed to make possible the > administration of the cards (probably absolutely obsolete cards) > that do not always return all necessary information. Missing information for > such a cards is looked for in the profiles. > It presumes some 'stability' of the profiles. Sure. That's why I'm suggesting to move handling of these cards to their own emulator, that exposes a standard interface. But, first of all... > Probably these precautions is not more (was never) valid. > Pkcs15init has to be reviewed/retested to see if these precautions are still > necessary. ... is some card driver actually using 'em? > No, you will be prompted for the PIN that was deduced from the FCP of the > parent that has been selected at the > moment just before generation . If 'SELECT' of your parent do not returns > FCP, then your profile will be asked to > create virtual instance of you parent and this one will certainly have the > needed ACL. Ok. > ID '02' will silently go into the authId of a new PKCS#15 object. Nothing > more. So creating a mismatch between what PKCS#15 knows aout that object and what card mandates... And we end up having to look at (possibly out-of sync) profiles. > Then, when you will try to use this generated key, for ex. to make a > signature, > your PIN value argument will be used in the VERIFY command with the 02 as > pin-reference . But since profile only says CRYPTO=$PIN, ACL is created with a requirement for VERIFY CHV1 (given that CHV1 have ID 01)... >>> If it's not like that, get us look at the extended logs or the detailed >>> description of your actions. >> Didn't dig this deep into card-specific code. > It's going about the logs from your 'suspicious' session where SOPIN was > blocked. Too late. Definitely locked SOPUK, too. Not worth resending to Aventra to reload their app... I'll try to recycle it as a test card for my app implementing neural cryptography when it will be ready (in the mean time I'll try OpenPGP to make some practice). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [OpenSC] #327: pkcs15-init allows multiple keys and certs w/ same id
Il 29/04/2011 15:01, OpenSC ha scritto: > #327: pkcs15-init allows multiple keys and certs w/ same id > Anyone has a patch ? :) I'll try to have a look at it. Since we're already parsing quite some data when scanning to create a new key, it shouldn't bee too hard. I hope. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Profiles
Il 29/04/2011 14:38, Martin Paljak ha scritto: > Hello NdK (Diego?) Yup. It's me. > A side note: PKCS#15 profiles related parts of OpenSC are quite undocumented > and difficult to understand/follow (as you probably have experienced yourself) I know. But since they're there and have to be followed we should at least try to follow'em... > If you feel like improving what you read, as you go on, what about updating > - pkcs15-profile (should it be renamed to pkcs15.profile?) manual page [1] > - CardPersonalization [2] wiki page (or better yet, create a new page for a > "writing/modifying a PKCS#15 profile") Since I'm not an expert, it could be better to start wit wiki, adding a big fat warning on top :) > Martin, off to gardening for the weekend. Too much green makes me grey :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Profiles
Il 29/04/2011 13:49, Viktor TARASOV ha scritto: > Please, precise what standards are you talking about? PKCS#15, ISO7816 and every applicable one. > From your point of view, where the UPDATE access to 4402 and friends should > be defined ? Since UPDATE refers to an existing object, it belongs to that object. But CREATE, being referred to a non-existing object, should belong to container (parent) object. > For me this discussion is about coherence in usage of the OpenSC tools, of > the OpenSC libraries and profiles . > Profiles are not to be changed inside the card lifecycle . If a profile is used only when creating objects, then there's no need to have it at all when just using a card (w/o creating new objects on it). But it seems that the need to change profiles is quite common, since "options" have been included. It's not "good" that problems arise if I create a card using pkcs15+onepin and a user creates a key using just pkcs15 profile! > If user is asked for the $PIN (User PIN) the prompt should show an > appropriate (more or less) label. > The same for SOPIN. So, if I specified -a 02 to -G, I should get prompted for "label of pin with ID = 02" (in my case CHV2, that I use as "user auth", while CHV1 is "card auth" to limit access to creation and deletion of objects on card). Till now, the only way I could find to obtain that is to change the profile before generating the key (and making sure that profile-given PIN and -a -given PIN are actually the same object, or PKCS#15 data and object-acl gets out of sync). > Afaiu, your card can return all necessary information to authorize some > operation. > Your profile 'should not be' asked for the ACLs of an existing file/objects. Then it's OK. > If it's not like that, get us look at the extended logs or the detailed > description of your actions. Didn't dig this deep into card-specific code. >>> Actually, when using pkcs15-init, one needs to choose the '--auth-id' >>> corresponding exactly to the ACLs settings in the profile . >> Forgot to ask: then why allow the user to specify it? > Historical reasons ? This should not be a compelling reason. If my vars patch works, it becomes quite easy to convert "--insecure" to "-d auth=NONE" and "-a 01" to "-d auth=CHV1". > Difficulty to deduce the auth-id from the real ACLs for the 'usefull' object > operations ? I have to look at how "real ACLs" look like. > If you see how to improve it -- heartily welcome. I think the vars patch I'm preparing could be useful for that... >> As I see it, profiles should only be used for creation of objects. All >> the infos needed later should be sccessible throught PKCS#15 (or other >> standards) descriptions, or even set by card drivers... > I'm absolutely agree -- 'should be' . > But, for a while have take into account that not all cards can. Those, then, should be "emulated" by a *fixed* profile. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Profiles
Il 29/04/2011 12:23, Toni Sjoblom - Aventra ha scritto:
>>> Agree, but not every card always returns all necessary information.
>>> The missing part can be looked for in the card profiles.
>> Uhm... Doesn't standards mandate that, for example, 3F00 must always be
>> readable, 4402 contains auth info, etc?
> Yes, see the PKCS#15 specification from RSA.
That's why I didn't expect Viktor's answer.
> AFAIU the profile is used only when creating new objects. Once the object
> (DF or EF) has been created the ACLs are read from the card. Everything
> describing the structure is on the card (or at least is should be, if it's
> not there's an error). This is what the PKCS#15 standard is for, it
> describes the structure and content of the card.
So I understood it correctly. But it seems Viktor is right, and profile
gets in the way even when just using the card. But changing that is
beyond my current competence on opensc :(
> PKCS#15 emulated cards are
> then another question, these are handled separately in OpenSC by emulators.
IMHO emulators should have their own "internal" (as "not end-user
tamperable") profiles, since they have to adhere (and emulate) a
standard, plus an "end-user editable" profile just like PKCS#15 cards.
> I thought you wanted to generate a key on the card and the use it without a
> PIN, so requiring PIN to create the key is no problem.
> Have I understood you correctly?
Yes. It's just that I moved a bit farther than that. If I can make
profile parser to support "user defined vars" (like its macros, but more
versatile and useable from the command line), then I can simply change
profile to have
acl = CRYPTO=$usepin, CREATE=$createpin, READ=NEVER, UPDATE=$updpin,
DELETE=$deletepin
and have a "vars" block where I define default values for these
variables to keep current behaviour:
option default {
macros { [...] };
vars {
usepin=$PIN;
createpin=$PIN;
updpin=$PIN;
deletepin=$SOPIN;
}
}
Then if I issue
$ pkcs15-init -G rsa/2048 -d usepin=NONE --insecure -l "Insecure key"
I get what I want: a key that doesn't require a PIN to be used (still
sub-optimal, since I have to use --insecure just to avoid an error...
but disabling -a and --insecure might be problematic for other
side-effects).
Too bad macros don't work this way (I'd have to define a macro for
CRYPTO=NONE, not just for NONE). Doable, but less intuitive for who
should need to change profile.
The second step will be to support "extended syntax" vars, simplifying
even more profile syntax: instead of a block of vars, I can simply have
acl = CRYPTO=$usepin:$PIN ...
meaning "if usepin is not defined, use $PIN as default".
ATM I'm trying to implement vars without a block but with basic syntax.
Extended syntax should go in a separate (quite trivial) patch.
> Actually, when using pkcs15-init, one needs to choose the '--auth-id'
>> corresponding exactly to the ACLs settings in the profile .
>> Forgot to ask: then why allow the user to specify it?
> This is where the profile settings should be overridden, i.e. if the user
> specifies "-G .. -a 2" the key should be generated using a pin with
> reference 2.
> Other ACL information is read from profile, and if the user does not specify
> any auth-id, the one specified in the profile is used.
> It is this feature that is currently missing from the MyEID driver, now it
> only reads the profile and ignores the command line parameter "-a X".
> I think other card drivers must have this feature, and it should be added to
> MyEID as well.
Should find one that have it to see how it's implemented... But if I can
make the "more general" syntax work, it becomes more or less useless.
BTW, I still couldn't understand *what* -a should override, since it
seems (from Viktor's comments) $PIN is not the right candidate.
PS: Is it correct to specify "CREATE" as an object's acl? IMHO it should
belong to container object... Or there's a different handling based on
the contained object type (I can create a binary data file w/o
restrictions, to create a keypair I have to authenticate with CHV1, to
create a DF I have to authenticate with CHV2, etc)?
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Profiles (was: --insecure ?)
Il 29/04/2011 09:20, Viktor TARASOV ha scritto: >>> We cannot replace $PIN macro with the one that can be modified by >>> '--auth-id'. >>> $PIN macro can be used to protect, for ex. the xxDF files itself, >> Well, I don't see why it shouldn't work :) > When $PIN translation can change from one init command to another, > and when $PIN macro is largely used in the card profiles -- one need to be > careful. Surely profiles have to be checked. >> Urgh! That's not good. :( Access conditions for existing objects should >> only be read from card... Profile should only be used for new objects... > Agree, but not every card always returns all necessary information. > The missing part can be looked for in the card profiles. Uhm... Doesn't standards mandate that, for example, 3F00 must always be readable, 4402 contains auth info, etc? > some DF have $PIN in its profile settings. In the first init command it was > created with certain $PIN value translated to its ACLs . > In the next init command pkcs15init may ask profile to retrieve the ACL of > this DF and obtain the authorization for some operation . > So, the $PIN translation has to be the same in the both cases. Imagine that a card gets initialized on a system where profile has been customized to ask SOPIN to create keys, then an user tries to add keys on another machine, where profile says $PIN is to be asked. The result might be a locked SOPIN, since interface asks for user pin but card requires sopin... (might be what happened to me...). >>> Actually, when using pkcs15-init, one needs to choose the '--auth-id' >>> corresponding exactly to the ACLs settings in the profile . Forgot to ask: then why allow the user to specify it? >>> Otherwise the PKCS#15 description will not correspond to the real ACLs . >>> It's not quite friendly . >> It seems quite dangerous and error-prone, to me... As I see it, profiles should only be used for creation of objects. All the infos needed later should be sccessible throught PKCS#15 (or other standards) descriptions, or even set by card drivers... > So, waiting to hear from you soon. Working on macros just now :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
On 28/04/2011 20:23, Viktor TARASOV wrote: >> Maybe I could try to write a patch to support $AUTH (or something more >> generic, see below) for this purpose? > Yes you can. Ok. On TODO. > You have a reason, probably we'll need to introduce a new auth method. > The one that could be overwritten with '--auth-id' and used to define access > for the operations with objects/object-data-files. > I don't think that it can be more general. > It has to be used only for the operations for which the access could be > described in PKCS#15 xxDFs -- with authId, accessControlRules, ... I'd go for a new parameter, then. Too bad -D is already taken. Falling back to --define MACRO=value . Or maybe -m/--macro MACRO=value? > We cannot replace $PIN macro with the one that can be modified by '--auth-id'. > $PIN macro can be used to protect, for ex. the xxDF files itself, Well, I don't see why it shouldn't work :) > and pkcs15init can (in theory) address the card profile to find out the > access condition for DFs or xxDF files. Urgh! That's not good. :( Access conditions for existing objects should only be read from card... Profile should only be used for new objects... > It will expect the $PIN value that has been used at the > creation(initialization) time. Why? > Needs more reflexion. Yup. Before starting to code, it's better to clarify all aspects. Just popping up: CREATE acl, IIUC, must be set on the PARENT DF, not on the EF (that doesn't exist yet...). >> $PIN is ambiguous... > $PIN should be read as $USERPIN That makes sense only in onepin option or when just PIN and SOPIN exists. >> Even better, something like >> CRYPTO=$AUTH:$SOPIN:NONE Handling of this syntax will be in another patch :) > Actually, when using pkcs15-init, one needs to choose the '--auth-id' > corresponding exactly to the ACLs settings in the profile . > Otherwise the PKCS#15 description will not correspond to the real ACLs . > It's not quite friendly . It seems quite dangerous and error-prone, to me... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
Il 28/04/2011 14:24, Viktor TARASOV ha scritto: >> Why is it fixed? > Let's say 'translated'. > 'PIN', 'SOPIN' in human language are translated to CHV## in APDU language . Well, I understand that it must be translated to what APDUs need. But why "fix" it in the profile, since we already have CHVn notation? >>> If your card contains the User PIN authentication object >>> with the reference 1, the $PIN is translated to CHV1. >> And how should I say, in profile, "use the authentication object specified >> by --auth" ? > Use for what? As $PIN :) So, if I have CHV1 (ID 01) and CHV2 (ID 02) and an ACL saying CRYPTO=$PIN, if I use -a 01 it will be translated to CRYPTO=CHV1 and if I use -a 02 it becomes CRYPTO=CHV2. Maybe I could try to write a patch to support $AUTH (or something more generic, see below) for this purpose? $PIN is ambiguous... > Language of pkcs15init tool's arguments is a poor language. It's difficult to > specify all parameters for a new object: > import with SOPIN, delete with PIN, PSO_DST with SignPIN, ... > The details come from the card profiles. That can be good, but even a source of ambiguity. At least it can be useful for allowing override in a controlled (but not too strict) way. > Probably the '--auth' argument should overwrite the object's 'usage' ACLs > from the profile . That would be reasonable and will answer your expectation. > We will lost the fine granularity (PSO_DST with PIN, PSO_Auth none, ...) -- > but I don't think we really need it . No. I wouldn't do that. IMHO there should be some way to override (part of) profile from command line. Maybe simply defining more variables (like the proposed $AUTH) that gets translated in a controlled way. Even better, something like CRYPTO=$AUTH:$SOPIN:NONE meaning "for CRYPTO, use command line -a parameter, if not specified, use $SOPIN, if even it is not defined, use NONE" (doesn't make too sense, but it's only an example). It can be extended to support arbitrary lists. As soon an object is defined, parsing stops and translation happens. > Now it's a certitude -- '-a' has to overwrite the object's usage ACLs from > the profile. Maybe it only needs better docs (even only a slightly different help text). So the users don't expect the wrong behaviour. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
On 28/04/2011 12:07, Viktor TARASOV wrote: > $PIN, $SOPIN and others are the profile macros > and correspond to the SC_AC_SYMBOLIC authentication method. Ok. I already found this digging code. > They are resolved using the pin flags of the PIN pkcs15 > objects already present on the card. > Look into sc_pkcs15init_get_pin_reference() . Now I'm starting to get lost... Why is it fixed? > If your card contains the User PIN authentication object > with the reference 1, the $PIN is translated to CHV1. And how should I say, in profile, "use the authentication object specified by --auth" ? > '-a 02' only (to be confirmed) means that the > CommonObjectAttributes.authId of your object will be set to '02' and > written to the PrKDF . And that means what? If use is regulated by profile (as it seems), it's useless to set another (different) value. If I say "-G ... -a 02" I mean "create a new key and require authentication with 'pin2' to use it" (now assuming 'pin2' maps to CHV2). If the default profile says CRYPTO=$PIN and that gets translated to CHV1, that's not what I expect... > Look into you profile (which one?) myeid.profile , just reset to default one for these tests. > -- how generation/creation of new file/object is protected in your parent DF? Urgh! Parent permission! I was looking at EF permissions and not parent DF ones... That explains something. 3F00 have acl= CREATE=$PIN, DELETE=$SOPIN > how write operation for xxDFs is protected ? ... If one of them is > protected by CHV1 ($PIN) -- you will be asked for CHV1. I see. Uhm... Tuning profiles can be a very hard job... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
On 28/04/2011 10:51, Martin Paljak wrote:
>> Don't know how this could be done for OpenSC, since it caches PIN codes.
> Only if the PIN does not cache "user consent" keys and only if PIN caching is
> enabled.
Found relevant code.
> Yes it does support using such PIN-s. OpenSC does not cache the PIN if any
> private key with user consent has the PIN as authentication ID. Creating them
> is AFAIK not possible through command line (a feature request ticket might be
> good)
IIUC, user_consent is never set. Unless you have it set in an imported
certificate. Doesn't "sound right" to me.
Here's a patch to test:
--- pkcs15-init.h.ori 2010-12-22 18:14:39.0 +0100
+++ pkcs15-init.h 2011-04-28 11:36:33.805873246 +0200
@@ -189,6 +189,8 @@
const char *puk_label;
const unsigned char * puk;
size_t puk_len;
+
+ int user_consent;
};
struct sc_pkcs15init_keyarg_gost_params {
--- pkcs15-lib.c.ori2010-12-22 18:14:39.0 +0100
+++ pkcs15-lib.c2011-04-28 11:38:51.895233831 +0200
@@ -908,6 +908,9 @@
sc_profile_get_pin_info(profile, SC_PKCS15INIT_USER_PIN, pin_info);
pin_info->auth_id = args->auth_id;
+ /* Mark it as 'user consent' pin (uncacheable) */
+ pin_obj->user_consent = args->user_consent;
+
/* Now store the PINs */
sc_debug(ctx, SC_LOG_DEBUG_NORMAL, "Store PIN(%s,authID:%s)",
pin_obj->label, sc_pkcs15_print_id(&pin_info->auth_id));
r = sc_pkcs15init_create_pin(p15card, profile, pin_obj, args);
--- pkcs15-init.c.ori 2010-12-22 18:14:33.0 +0100
+++ pkcs15-init.c 2011-04-28 11:39:41.483645061 +0200
@@ -133,6 +133,7 @@
OPT_PUK_LABEL,
OPT_VERIFY_PIN,
OPT_SANITY_CHECK,
+ OPT_USER_CONSENT,
OPT_PIN1 = 0x1, /* don't touch these values */
OPT_PUK1 = 0x10001,
@@ -185,6 +186,7 @@
{ "insecure", no_argument, NULL,
OPT_UNPROTECTED },
{ "use-default-transport-keys",
no_argument, NULL, 'T' },
+ { "user-consent", no_argument, NULL,
OPT_USER_CONSENT },
{ "no-prompt", no_argument, NULL,
OPT_NO_PROMPT },
{ "profile",required_argument, NULL,'p' },
@@ -240,6 +242,7 @@
"Private key stored as an extractable key",
"Insecure mode: do not require PIN/passphrase for private key",
"Do not ask for transport keys if the driver thinks it knows the
key",
+ "Require user to re-authorize every transaction (no PIN caching)",
"Do not prompt the user; if no PINs supplied, pinpad will be used",
"Specify the general profile to use",
@@ -314,6 +317,7 @@
static unsigned intopt_actions;
static int opt_extractable = 0,
opt_unprotected = 0,
+ opt_user_consent= 0,
opt_authority = 0,
opt_no_prompt = 0,
opt_no_sopin = 0,
@@ -783,6 +787,10 @@
args.puk = (u8 *) opt_pins[1];
args.puk_len = opt_pins[1]? strlen(opt_pins[1]) : 0;
+
+ if (opt_user_consent)
+ args.user_consent=1;
+
return sc_pkcs15init_store_pin(p15card, profile, &args);
failed:fprintf(stderr, "Failed to read PIN: %s\n", sc_strerror(r));
@@ -2496,6 +2504,9 @@
this_action = ACTION_STORE_PUBKEY;
opt_infile = optarg;
break;
+ case OPT_USER_CONSENT:
+ opt_user_consent++;
+ break;
case OPT_UNPROTECTED:
opt_unprotected++;
break;
It compiles and seems to work... At least --user-consent option is
accepted and SHOULD get stored in PIN object.
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
On 25/04/2011 11:01, Viktor TARASOV wrote:
>> For what I've understood, "-a N" makes $PIN in profile be replaced by
>> CHVN, hence IMO --insecure<=> $PIN->NONE.
> No,
> '-a N' means in fact '-a .
> The real PIN reference, the one that can be used in the PINs APDU,
> is extracted from AODF record as PinAttributes.pinReference .
>
> The 'N' in the CHVN syntax is directly pin reference that corresponds to
> PinAttributes.pinReference .
Ok.
Too bad it seems not to work this way, and $PIN anlways gets translated
to CHV1 :(
If I do
$ pkcs15-init -G rsa/2048 -a 02 -l "test a2"
the card still requires verification of CHVN1 to use the card.
PINs are defined as:
PIN [Card auth]
Object Flags : [0x3], private, modifiable
ID : 01
Flags : [0x30], initialized, needs-padding
Length : min_len:4, max_len:8, stored_len:8
Pad char : 0xFF
Reference : 1
Type : ascii-numeric
Path :
PIN [User auth]
Object Flags : [0x3], private, modifiable
ID : 02
Flags : [0x30], initialized, needs-padding
Length : min_len:4, max_len:8, stored_len:8
Pad char : 0xFF
Reference : 2
Type : ascii-numeric
Path :
so -a 02 should make $PIN get translated to CHV2, not to CHV1 as it
does. Or am I wrong?
> Personally, I'm ready to remove at all 'insecure' option -- never used it.
> All the stuff can be defined in the card profile. But let us wait for the
> other opinions.
I could finally workaround non-working-as-advertised --insecure by
patching profile and w/o touching code:
option default {
macros {
[...]
prkacl = CRYPTO=$PIN, UPDATE=$PIN, DELETE=$PIN,
GENERATE=$PIN;
}
}
option insecure {
macros {
prkacl = CRYPTO=NONE, UPDATE=$PIN, DELETE=$PIN, GENERATE=NONE;
}
}
[...]
EF template-private-key {
[...]
acl = $prkacl;
}
So now I can use
$ pkcs15-init --profile pkcs15+default+insecure -G rsa/2048 --insecure
-l "key usable without PIN"
It's a bit ugly, but makes the user think twice before generating an
insecure key :)
I still think that --insecure should "translate" $PIN to NONE, but
that's another story.
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
Il 28/04/2011 09:05, Toni Sjoblom - Aventra ha scritto: > I think that this feature is just missing from the drivers code. > Can you Martin say which card you have used the --insecure option with? > This could help find the missing code Yup! > (for us that that are not that > familiar with the OpenSC code structure and all that :). Present! :) > I agree. Also a very common scenario is to have 3 PINs, one for normal use, > one for signatures (PIN is reset after every use, so user need to enter PIN > explicitly for every signature) and one for administration. How can you tell that a PIN is actually a "signature PIN" that must not be cached? Really enorcing "re-enter PIN" policy could be done only if keyboard was on card (seen some prototypes online, w/ a display, too... but never seen 'em in shops :( ), but making card "forget" it + "hinting" driver not to cache it could often work well enough. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --read-public-keys
On 27/04/2011 09:15, jons...@terra.es wrote: > BTW: I'm not sure of OpenSSH pkcs11 way to retrieve keys: afaik extract > it from certificates, but not sure if also handles > keys found in pukdf ¿anyone knows? In my tests, OpenSSH used public keys from pukdf, not from certs (I tested only with keys generated with -G , not with keys in certs). Then it leaves the card locked, but that's another story. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On 26/04/2011 19:16, Anders Rundgren wrote: > As far as I know not a single HSM (even those who cost $20 000) > out there is able to certify that keys actually were created > inside of the HSM!!! A $10-$20 SKS always attests the origin > of created keys using a built-in device key and certificate. Then you have to trust that certificate, trust that it's been installed securely, trust who issued it... Quite a lot of things you can't control, don't you think? What about a "virgin" device that the first time you turn it on generates a new key and only accepts "set params", "generate new key", "get self-signed cert" and "store this cert" until *you* store a cert? You can do it on an offline PC, booted from a CD. You have full control. Fear TEMPEST attacks? Just use a jammer and do some random data transfer to other USB devices... If the device doesn't accept "store key" command, then all keys it uses must have been generated locally :) > With a planned addition to KeyGen2 you will be able to put > certificates in devices (servers, routers, etc) using a > SCEP-like process that (due to the device certificate) can > be performed [securely] without an enrollment password. I still miss the sense of SCEP. Must study it... But I fear it just shifts security perimeter to another entity. > SKS is a "simple smartcard". That it looks complex is because > provisioning is really 10 times as complex as performing an > "RSA Sign". IIUC, just because "you" are using the wrong security perimeter at the wrong time. *If* you can *securely* load a single cert on the HSM, then all is easy (even easier than RSA, if you want). If you can't, *nothing* can be trusted. If, at initialization, you store a second certificate for administrator (even if I'd prefer weights for a Tree Parity Machine to be used as a shared symmetric key generator, to have perfect forward secrecy even in case of compromise), you're OK and can administer securely the HSM from anywhere. And since you're working inside a trusted perimeter, you don't need convoluted protocols that only delegate security to another party. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On 26/04/2011 15:19, Alon Bar-Lev wrote: > Just wanted to note that exposing such device to IP stack makes it a > target to hack, That's why I'm quite reluctant to enable Ethernet port on such a dongle. > packaging is much more difficult. I don't want to compete with $20k HSM. They use dedicated HW for good reasons. I only want something I can plug in my servers at work to be sure that no *remote* intruder can compromise my keys and make me revoke all certs (can be quite costy!). > Also, that in crypto caching is not a problem as 99.99% of time > the content of the crypto device is constant. Unless you keep some state vars on the device (ugly). But when it changes (new key/cert added, PIN changed, etc), that change must be propagated atomically to all clients. > About using USB directly, well, I disagree... I see this much like GPS > device, with a simple optional multiplexer for applications (local and > remote). When you use libusb, you claim() a device to get exclusive access. Then you handle it as you like. Usually a daemon claims the device and listens for socket/pipe connections actually multiplexing access and abstracting low-level protocol. > Implementation of hardware independent stream protocol will allow > using crypto in many scenarios (serial, USB, unix sockets, tcp, ssh) > with the PKCS#11 forwarding features built-in. You need "something" to forward it (unless I missed an SSH option "forward this serial port"), be it serial, USB or socket. And once you have a running daemon (pcscd, maybe?) that accepts socket/pipe connections from localhost, you're OK. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
On 26/04/2011 18:51, Frank Morgner wrote: > You forgot to mention Virtual Smart Card Architecture Already seen that, but always "wrappers wrapped in other wrappers" :( The architecture can be greatly simplified: no need for APDUs encoding/decoding, no need to handle card insertion/extraction, no need to know if it's T=0 or T=1 ... Direct leveraging of USB should allow a really light interface. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 12:26, Peter Stuge ha scritto: > NdK wrote: >> Fox Board ( http://acmesystems.com/ ). > .it Good catch :) > I will probably get a gumstix board for another couple of projects, > and might prototype on that. I'm not sure the final system should run > Linux because it's a whole lot of code for a simple device and > because it does require more expensive hardware. The more expensive > boards are great for prototyping though. Well, having Linux is good for software reuse: you need openssl? It's there! Need GPG? Present! :) >> Too bad USB runs at most at 12Mbps, but that shouldn't be an issue. > I don't think that will be a problem, no. I don't think any of these devices can do tenths of RSA-2048 encryptions per second (unless you use the FPGA), so USB shouldn't get saturated :) But this makes me wonder if they can handle enough SSL handshakes for a web server... (probably yes, if keepalive is in effect and there aren't too many concurrent clients). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 12:41, Anders Rundgren ha scritto: > I don't know what you had in mind with an "USB P11 token" > but in case you would like to participate in an effort > making sort of a USB P11 token there is already a project > to dig in to: > http://webpki.org/auth-token-4-the-cloud.html Interesting. Didn't know about it. Seems a bit resource-constrained at a first look, but worth a deeper exam. > Just drop me a line if you are interested. I'm particularly > interested in USB, P11, Mac, Electronics, and Browser competences. Always interested in all what's security-related. > An unusual (unique?) aspect of the mentioned project is that > it is designed to be integrated in browsers. It aims at "client" security. My target is server security, so I don't have to leave .key files around. In case of server compromission, I only have to reinstall it, w/o having to revoke its certs. Actually, sort-of TPM module (I could even use TPM, but it's only available on some motherboards :( and I don't know how fast it can be). > Although maybe not exactly what you guys are looking for, the > prime target for the project are people who are NOT interested > in security or at least know very little about it! Since they > represent 99% of all users it looks a bigger market :-) They're not interested as long as theyr money isn't affected. If their money gets affected, then they become really interested :) My project is surely heavily overkill for a client. Just like a simple smartcard is not enough to handle SSL hanshakes on a (moderately to heavily) busy https server. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 11:28, Alon Bar-Lev ha scritto: >> Since speed is quite critical, I was thinking to use something like G20 >> Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it >> can be WAY cheaper than other solutions), but it's tiny, fast (400MHz >> ARM9), can work as USB device (and host, maybe to keep a master key on a >> standard smart card used only once at boot time), can accomodate a >> (small) display and many keys, and there's a module with an FPGA if you >> want/need to implement some crypto acceleration in HW. >> There's even an Ethernet port (better not to use it... :) ). Too bad USB >> runs at most at 12Mbps, but that shouldn't be an issue. > There is no reference for this board in the link you sent. Ops! Sorry: http://acmesystems.it ! Translated first level domain too :( > It would be a great solution if the device will be very small and run Linux! > It would be lovely to have PIN keypad and BIO reader on board as-well. There are a lot of IO lines available. Just don't count too much on serial (UART) interfaces: known to have some speed problems (should be fixed soon, BTW). > However, I want to raise some issues. > Developing an implementation that directly accesses the USB device > impose fundamental security issue. As it requires the user to have > special privilege. It is true that on modern linux, udev can deal with > some device privilege settings, but it would be better to emulate some > standard interface, such as serial over USB. Possible, but I'm sure we can come to something better :) Encapsulating too many protocols one inside the other always gives troubles. [...] > Then you need to deal with device sharing. Stateless implementation > (connect, operate, disconnect) would solve this, while creating some > authentication cookie with the device. I'm usually not for stateless implementations for stateful devices. To avoid DoS attacks, state can be kept (for a reasonable time) by client, in encrypted form. > And need to deal with channel encryption secured messaging is not > this strong... Since it's a completely new device with its own protocol, it's even possible to do something like: - get device's cert (or public key) together with an encrypted nonce - send it your cert (or public key) and another nonce - get first nonce's decryption key, encrypted under your public key and signed by device - setup session key as an hash of the two nonces - use this session key for the rest of the session But maybe it's "a bit" overkill: USB is "enough" point-to point (much more than standard card interface, that could be "received" from a certain distance by its interferences...). > And last, power management should be applied, so device will be able > to be powered down while inactive. This should be simple if stateless > mode is used and if authentication cookies are stored in non-volatile > memory. That's one of the last problems... It consumes so little (and aims a target where power saving is not really a priority) that you can simply use internal powersaving. Even if it gets detached, it's like if you detach a smart card while in use. > After solving the above, it is all about PKCS#11 API serialization. > Most of the PKCS#11 objects may be loaded into the host computer. Only > private key operations should be serialized and sent to device in > runtime. Well, since you can have up to *16GB* memory (SDHC) on that device, storing objects is not a real problem :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 13:47, Peter Stuge ha scritto: > "forces local communications" makes no sense. If the device is > connected via USB then it will be local regardless of which interface > class it uses. And you can even use UsbIP stack if you want... > Maybe you will argue that it should implement CDC Ethernet and expose > a network protocol over USB, so that the device can be anywhere on > the network. That would be simpler to use the included ethernet interface, then... > It's a bad idea because the standard interfaces do not fit the > purpose of the device. It's *very* difficult for people to get their > head around this - you're not the only one - but vendor specific is > very very useful in USB. It's not a bad thing, it just takes a bit of > detail knowledge about USB to see the benefits. And needs to be very well documented. :) Not like many closed vendor specific protocols that float around... > Networking the device is a new requirement. It could make good sense > to go there later, but I would like to start with something that fits > easily into the existing p11 model. Urgh... well, it could even "serve" many servers via lan, but I too think it's something that can come much later. >> How can two parties can communicate with each other while have >> nothing common? Do you prefer unconditional (information-theoretic) security or "simply" computational security? :) Too bad public-key crypto can only be computationally secure :( >> PGP/SSH like manual key exchange may be used, but it is too complex >> for most users. As I said in another mail, you have to define security perimeters. From when the device is manufactured to the moment you load a certificate on it, you must consider it "secure by definition" and always inside a trusted security perimeter. After a cert is loaded, it can leave the security perimeter for the real world. > I thought you meant encryption between applications and device? Do > you mean user to user? Keep different layers separed. If you mix 'em it becomes a mess. Users see "application" level, not p11 (or whatever) level. > The API can be implemented over USB just as well as over DLL. There's > really not a big difference. So using vendor-specific protocol as a sort of RPC? >> What I have in mind is to pull all objects from the device into main >> computer and implement PKCS#11 locally, while delegating only private >> key operations to the device. >> This way you have much faster implementation, and a very simple >> protocol implementation. > Go for it! It's also an interesting idea. Cache coherency issues pops up everywhere in this scenario :) BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] usb p11 token
Il 26/04/2011 09:51, Peter Stuge ha scritto: > NdK wrote: >> One of the projects on my TODO list (quite a long list :( ) is to >> implement a suitable interface (CCID+virtual token? Could be better to >> opt for something that doesn't require APDUs...) on an embedded system >> w/ USB device interface... > Right. This is the idea for a USB p11 token that I've been going on > about for a long time already. :) We could start a parallel project, then :) > I was thinking microcontroller size, but if you're using a more > powerful USB device hardware that can run Linux then it could be > realized pretty quickly using softhsm. Since speed is quite critical, I was thinking to use something like G20 Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it can be WAY cheaper than other solutions), but it's tiny, fast (400MHz ARM9), can work as USB device (and host, maybe to keep a master key on a standard smart card used only once at boot time), can accomodate a (small) display and many keys, and there's a module with an FPGA if you want/need to implement some crypto acceleration in HW. There's even an Ethernet port (better not to use it... :) ). Too bad USB runs at most at 12Mbps, but that shouldn't be an issue. Didn't know softhsm... I'll have a look at it. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
Il 26/04/2011 08:41, Martin Paljak ha scritto: >> Personally, I'm ready to remove at all 'insecure' option -- never used it. >> All the stuff can be defined in the card profile. But let us wait for the >> other opinions. > I've used it and I find it a generally useful option, for cases where > the card could get reset yet where the access to the key can be > controlled with physical means (like a server with a token, where > you'll just revoke the necessary certificates when the machine should > be stolen and controlled access to the key is not as necessary). The That's another interesting use, but on a server you'll usually need faster tokens (unless it's really low-traffic). One of the projects on my TODO list (quite a long list :( ) is to implement a suitable interface (CCID+virtual token? Could be better to opt for something that doesn't require APDUs...) on an embedded system w/ USB device interface... > problem is that it is not equally supported by card drivers and always > not well supported by applications (which insist on using C_Login > before any operations, disregarding CKF_LOGIN_REQUIRED) That's an app bug and to be reported as such. Trying to "fix" it at the wrong level doesn't do any good. But, for example, ssh doesn't require it unless the key is protected (but then it leaves the card in unusable state). But generating a protected key when --insecure is specified is a bug in opensc (or in the card driver). IMHO. Since you used --insecure, can you confirm that its misbehaviour is only for MyEID cards? >> I don't know quite well the world of 'controlled/trusted environment', >> my interest is rather to administrate the card through the >> 'uncontrolled/untrusted' environment. > That's a good philosophical difference. IMO the default "security > officer" profile of OpenSC is not OK for home users either and the > default could be onepin profile. Well, I think that at least two PINs are always a good idea: one for *use* and one for *administration*, so the user is forced to know he's doing something dangerous. If he doesn't like to remember'em, then he could simply use the same code for both. But having only one is, IMVHO, a really bad idea, just like using 'root' for browsing the web. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-tool --list-public-keys
On 25/04/2011 21:05, Jean-Michel Pouré - GOOZE wrote: > We need one simple command returning precise information. This is needed > for future GUIs. pkcs15-tool -D should list 'em all, or not? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenDNIe project is now ready for public test
On 25/04/2011 14:33, jons...@terra.es wrote: > > I can figure out at least these different popups: [...] > 7 - "You'are about to emit a digital signature. Please confirm operation" And, anyway, you expose yourself to malicious apps that ask for a crypto pin and use it to sign a document... As long as we haven't cards with a display that can give feedback to the user about the requested op *as seen by the card*, we can't do much about that, unless using different pins for different ops. But how many users would really remember at least two (encode/decode and sign) different PINs? And what about a malicious app that says you're about to sign what you actually asked to sign and in reality submits a different document to the card? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] --insecure ?
On 24/04/2011 14:18, Viktor TARASOV wrote: >> It seems the root of the problem lies in the profile: changing >> CRYPTO=$PIN to CRYPTO=NONE works around it, but it's surely sub-optimal. What I wanted to say: shouldn't --insecure replace $PIN with NONE ? For what I've understood, "-a N" makes $PIN in profile be replaced by CHVN, hence IMO --insecure <=> $PIN->NONE. If it should work this way, then there's a bug. If it works this way in other cards, I'll have to look at card-myeid.c, else I'll have to look at code in profile.c . But I only have MyEID cards... >> Another, maybe related, problem is that, IIUC the profile syntax, only >> one PIN can be specified, > It's not completely true. > The ACL profile definition "ACL = *=NEVER,READ=$PIN,READ=$SOPIN;" will define > two linked ACL entries for 'READ' operation. That's good. This syntax makes me understand some code I couldn't find a reason for. But does it mean that BOTH are required ? But then it should be much more expressive someting like READ=($PIN&CHVn)|SOPIN to mean "to read this file you need either SOPIN or both PIN and CHVn. But then, apart card-specific support, profile parser should be extended. > After that it's up to card specific part to encode this case into the FCP of > file/object to be created. > The encoding is quite different from one card to another . That's quite understandable. > Further arrives the question how to use the combined ACLs (properly parsed by > card specific part back into the linked ACL entries.), describe them in > PKCS#15, ... > Actually the common part of pkcs15init or pkcs15 cannot process combined ACLs > where there are more then one authentication method of the same type (for ex. > two PINs). Uhm... Can't follow you well, here. If I use a line like CRYPTO=$PIN, UPDATE=CHV5, DELETE=CHV4, GENERATE=CHV4 to make it so that the user identified by $PIN can generate and use a key, but to delete/update it an authorization by other users is needed, doesn't work? Or simply that pkcs15-init still can't handel READ=$PIN,READ=$SOPIN? >> - central office handles card initialization (w/ SO-PIN) > Central office could be presented by the other authentication method: SM or > external authentication. > (xPIN authentication is not quite secure for the administration tasks.) > Support of these authentication methods is in the road-map of OpenSC. Read that, but usually a PIN (used inside a controlled environment) can be enough. After all, central office should be trusted "by default" since it initializes the card. And unless you use open-source (or self-developed) applets, you're already trusting who wrote the applet (or he could have inserted a backdoor to bypass any access control using a special, undocumented APDU or a special key). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Small constants fixup
On 24/04/2011 13:17, Viktor TARASOV wrote:
The using of SC_PKCS15INIT_MAX_OPTIONS is not appropriate in this context.
SC_PKCS15INIT_MAX_OPTIONS is the number of profile options that can be defined
as an argument for the pkcs15init operations .
So I can use up to 16 +'option' ? :)
If you want to 'marconize' the raw value, you should introduce a new macro,
something like
Ok. Done that. Attached.
I think that's always better to use symbolic constants instead of
literal ones.
It's different from SC_MAX_AC_OPS -- maximal number of distinct card operations
that can be protected by some access condition.
Yup. For these I usually use a typedef enum instead of a series of
#define so that any constant can be included anywhere in the sequence
and the limit stays updated automatically.
Another patch for that is attached.
BYtE,
Diego.
--- src/pkcs15init/pkcs15-lib.c.ori2010-12-22 18:14:39.0 +0100
+++ src/pkcs15init/pkcs15-lib.c2011-04-24 21:04:25.0 +0200
@@ -79,6 +79,9 @@
#define TEMPLATE_INSTANTIATE_MIN_INDEX 0x0
#define TEMPLATE_INSTANTIATE_MAX_INDEX 0xFE
+/* Maximal number of access conditions that can be defined for one card
operation. */
+#define SC_MAX_OP_ACS 16
+
/* Handle encoding of PKCS15 on the card */
typedef int(*pkcs15_encoder)(struct sc_context *,
struct sc_pkcs15_card *, u8 **, size_t *);
@@ -3296,14 +3296,14 @@
SC_FUNC_CALLED(ctx, SC_LOG_DEBUG_NORMAL);
for (op = 0; r == 0 && op < SC_MAX_AC_OPS; op++) {
- struct sc_acl_entry acls[16];
+ struct sc_acl_entry acls[SC_MAX_OP_ACS];
const struct sc_acl_entry *acl;
const char *what;
int added = 0, num, ii;
/* First, get original ACLs */
acl = sc_file_get_acl_entry(file, op);
- for (num = 0; num < 16 && acl; num++, acl = acl->next)
+ for (num = 0; num < SC_MAX_OP_ACS && acl; num++, acl =
acl->next)
acls[num] = *acl;
sc_file_clear_acl_entries(file, op);
--- src/libopensc/types.h.ori 2010-12-22 18:14:47.0 +0100
+++ src/libopensc/types.h 2011-04-24 21:44:31.0 +0200
@@ -86,35 +86,36 @@
#define SC_AC_NEVER0x
/* Operations relating to access control */
-#define SC_AC_OP_SELECT0
-#define SC_AC_OP_LOCK 1
-#define SC_AC_OP_DELETE2
-#define SC_AC_OP_CREATE3
-#define SC_AC_OP_REHABILITATE 4
-#define SC_AC_OP_INVALIDATE5
-#define SC_AC_OP_LIST_FILES6
-#define SC_AC_OP_CRYPTO7
-#define SC_AC_OP_DELETE_SELF 8
-#define SC_AC_OP_PSO_DECRYPT 9
-#define SC_AC_OP_PSO_ENCRYPT 10
-#define SC_AC_OP_PSO_COMPUTE_SIGNATURE 11
-#define SC_AC_OP_PSO_VERIFY_SIGNATURE 12
-#define SC_AC_OP_PSO_COMPUTE_CHECKSUM 13
-#define SC_AC_OP_PSO_VERIFY_CHECKSUM 14
-#define SC_AC_OP_INTERNAL_AUTHENTICATE 15
-#define SC_AC_OP_EXTERNAL_AUTHENTICATE 16
-#define SC_AC_OP_PIN_DEFINE17
-#define SC_AC_OP_PIN_CHANGE18
-#define SC_AC_OP_PIN_RESET 19
-#define SC_AC_OP_ACTIVATE 20
-#define SC_AC_OP_DEACTIVATE21
-#define SC_AC_OP_READ 22
-#define SC_AC_OP_UPDATE23
-#define SC_AC_OP_WRITE 24
-#define SC_AC_OP_RESIZE25
-#define SC_AC_OP_GENERATE 26
-/* If you add more OPs here, make sure you increase SC_MAX_AC_OPS*/
-#define SC_MAX_AC_OPS 27
+typedef enum {
+SC_AC_OP_SELECT=0,
+SC_AC_OP_LOCK,
+SC_AC_OP_DELETE,
+SC_AC_OP_CREATE,
+SC_AC_OP_REHABILITATE,
+SC_AC_OP_INVALIDATE,
+SC_AC_OP_LIST_FILES,
+SC_AC_OP_CRYPTO,
+SC_AC_OP_DELETE_SELF,
+SC_AC_OP_PSO_DECRYPT,
+SC_AC_OP_PSO_ENCRYPT,
+SC_AC_OP_PSO_COMPUTE_SIGNATURE,
+SC_AC_OP_PSO_VERIFY_SIGNATURE,
+SC_AC_OP_PSO_COMPUTE_CHECKSUM,
+SC_AC_OP_PSO_VERIFY_CHECKSUM,
+SC_AC_OP_INTERNAL_AUTHENTICATE,
+SC_AC_OP_EXTERNAL_AUTHENTICATE,
+SC_AC_OP_PIN_DEFINE,
+SC_AC_OP_PIN_CHANGE,
+SC_AC_OP_PIN_RESET,
+SC_AC_OP_ACTIVATE,
+SC_AC_OP_DEACTIVATE,
+SC_AC_OP_READ,
+SC_AC_OP_UPDATE,
+SC_AC_OP_WRITE,
+SC_AC_OP_RESIZE,
+SC_AC_OP_GENERATE,
+SC_MAX_AC_OPS /* This *MUST* remain the *last* one */
+} _sc_ac_ops;
/* the use of SC_AC_OP_ERASE is deprecated, SC_AC_OP_DELETE should be used
* instead */
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Small constants fixup
Hello all.
Just noticed that there's a constant defined for maximum number of ACLs,
but the raw value is used in the code. This should fix it at least in
pkcs15-lib.c :
$ diff -u pkcs15-lib.c.ori pkcs15-lib.c
--- pkcs15-lib.c.ori2010-12-22 18:14:39.0 +0100
+++ pkcs15-lib.c2011-04-23 23:49:36.0 +0200
@@ -3296,14 +3296,14 @@
SC_FUNC_CALLED(ctx, SC_LOG_DEBUG_NORMAL);
for (op = 0; r == 0 && op < SC_MAX_AC_OPS; op++) {
- struct sc_acl_entry acls[16];
+ struct sc_acl_entry acls[SC_PKCS15INIT_MAX_OPTIONS];
const struct sc_acl_entry *acl;
const char *what;
int added = 0, num, ii;
/* First, get original ACLs */
acl = sc_file_get_acl_entry(file, op);
- for (num = 0; num < 16 && acl; num++, acl = acl->next)
+ for (num = 0; num < SC_PKCS15INIT_MAX_OPTIONS && acl;
num++, acl = acl->next)
acls[num] = *acl;
sc_file_clear_acl_entries(file, op);
Quite trivial, but should reduce errors if/when that constant will be
changed.
'16' is used in other places, too... Maybe another #define could be
useful (for example: is it mandatory or arbitrary that a PIN name cannot
exceed 16 chars? ).
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] --insecure ?
Hello all. Since Toni can't look at this issue soon, I'm trying to fix it myself. The problem is that, at least with Aventra MyEID, every key gets created in a way that requires CHV1 for crypto ops, even if --insecure is specified. It seems the root of the problem lies in the profile: changing CRYPTO=$PIN to CRYPTO=NONE works around it, but it's surely sub-optimal. Another, maybe related, problem is that, IIUC the profile syntax, only one PIN can be specified, so I can't say that (for example): - central office handles card initialization (w/ SO-PIN) - a key must be "authorized" (generated in presence of) a delegated technician (CHV1) -- maybe to later issue a certificate that requires face-to-face recognition - doing crypto ops on that key may be protected by a PIN (any CHV, as specified by -a N) or left unsecured (--insecure) - more keys can be generated by the user w/o requiring the technician While to leave it unprotected I can play with the profile, I don't see any way to protect it with a different pin (unless I can specify directly CHVn instead of $PIN, and even then I could think some scenarios where it would require quite a lot of profiles juggling). I still find it quite difficult to follow code flow, even if I'm beginning to understand it a bit... So any pointer could be helpful. Tks, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Automatic read binary in iso driver
Il 20/04/2011 22:24, Frank Morgner ha scritto: > But all other functions of libopensc require the caller to allocate > enough space. Vital for maintainable software: who needs memory, allocates (*and frees*) it. As a sage said a long time ago: "or you rewrite your project this way, or your project will rewrite you" :) > In the third solution the caller still allocates memory. He then > sequentially calls sc_read_binary with more and more space allocated. He > stops when the first error is thrown. What about allocating 'x' (32?) KB then reads the whole file? > The problem I have is to read a file with an unknown length. How is that possible? Aren't file sizes fixed at file creation time? Have I missed something? IIUC, when you issue a SELECT_FILE, you can see its size, too. I'm confused. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] How to make proper use of sc_card_cache
On 05/04/2011 20:58, Frank Morgner wrote: > My previous remarks in this mail apply to the inner structure of the SM > module. I consider your layout as the most promising. (Maybe because I > implemented something similar ;-) ) Beyond that what I have already said > about where to trigger SM, I have some other questions: Excuse me if I pop-in, but ... what about ISO/OSI stacking? I'm not an expert, but for what I understand you're "mixing" different layers. IIUC, SM should be an higher layer than APDU. Maybe a "virtual" UnsecureMessaging layer, peer of SM, could be useful for abstraction... Or, maybe, I completely misunderstood the whole thing... :) Just my .02 . BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ssh error
Il 23/02/2011 21:19, Martin Paljak ha scritto: >> But when I try to use it, I get: >> -8<-- >> $ ssh otheruser@myhost >> Enter PIN for 'MyEID (User Auth)': >> C_Sign failed: 257 > This means: #define CKR_USER_NOT_LOGGED_IN(0x101UL) > Having OpenSC debug.log would be useful - is the right PIN verified before as > it should be. Today I could do some more testing. I tried nearly step-by-step, adding complexity every time it worked (as expected or not). So, clean start (the script I'm using): -8<-- pkcs15-init -E pkcs15-init -C --pin --puk --so-pin $SOPIN --so-puk $SOPUK -l "NdK card" pkcs15-init -P -a 1 --pin $PIN1 --puk $PUK1 --so-pin $SOPIN -l "Card Auth" #pkcs15-init -P -a 2 --pin $PIN2 --puk $PUK2 --so-pin $SOPIN -l "User Auth" pkcs15-init -F pkcs15-init -G rsa/2048 --insecure --id 1000 -u digitalSignature -l "SSH:ndk" --pin $PIN1 -8<-- In this scenario ssh works, but *asks for CHV1* ! ??? But if I add another PIN (uncommenting the second -P ), I get again that "not logged in" error, even if key is still created with --insecure ! Maybe I'm triggering some untested path? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ssh error
On 23/02/2011 21:19, Martin Paljak wrote:
>> -8<--
>> $ ssh otheruser@myhost
>> Enter PIN for 'MyEID (User Auth)':
>> C_Sign failed: 257
> This means: #define CKR_USER_NOT_LOGGED_IN(0x101UL)
> Having OpenSC debug.log would be useful - is the right PIN verified before as
> it should be.
I tried to simplify: I added an UNPROTECTED (--insecure) key, just to
test. That's the one whose public-key I loaded on server.
The script used to init the card is attached (maybe it could be useful
for others).
The log is available at:
http://www.csshl.org/EXTRA_FILES/opensc-debug.log.err.gz
>> After that, I often find the card unresponsive after that error:
That's probably related. Before flooding with logs, better to have the
most basic part working :) That might fix this too (as usually happens
when programming in C)...
BYtE,
Diego.
#!/bin/bash
SOPIN=
SOPUK=
PIN1=
PUK1=
PIN2=
PUK2=
PIN3=
PUK3=
# Load a certificate on card. $1 is base name (and label)
function loadcert {
echo "Loading cert for $1"
pkcs15-init -S "$1.p12" -f PKCS12 --passphrase "$2" -v -a 2 -l "$1" --pin
$PIN1
}
# Generate a new key for SSL
# - Pin# (0 for no PIN)
# - ID
# - label
function genkey {
size=2048
echo "Generating key '$3' - ID=$2 size=$size"
if [ -z '$1' ]; then
auth="--insecure";
else
auth="-a $1";
fi
# Maybe only a subset is needed, but for now I'll enable all uses
keyuse=digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment,keyAgreement,keyCertSign,cRLSign
pkcs15-init -G rsa/$size $auth --id $2 -u $keyuse -l "$3" --pin $PIN1
k=`pkcs15-tool --read-ssh-key $2 2>/dev/null |tail -1`
echo "$k $3"
}
pkcs15-init -E -l "NdK card"
pkcs15-init -C --pin --puk --so-pin $SOPIN --so-puk $SOPUK
pkcs15-init -P -a 1 --pin $PIN1 --puk $PUK1 --so-pin $SOPIN -l "Card Auth"
pkcs15-init -P -a 2 --pin $PIN2 --puk $PUK2 --so-pin $SOPIN -l "User Auth"
pkcs15-init -P -a 3 --pin $PIN3 --puk $PUK3 --so-pin $SOPIN -l "Root CA"
pkcs15-init -P -a 4 --pin $PIN3 --puk $PUK3 --so-pin $SOPIN -l "Intermediate CA
1"
pkcs15-init -P -a 5 --pin $PIN3 --puk $PUK3 --so-pin $SOPIN -l "Intermediate CA
2"
pkcs15-init -F
# First it's better to put SSH keys
genkey 2 1000 "ndk"
genkey 0 1001 "da-tecnici"
# Import certs
#loadcert certfile privkeypass
# Generate other keys
#genkey 3 10 "Root CA"
#genkey 2 20 "Intermediate CA 1"
#genkey 1 21 "Intermediate CA 2"
#addcert___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ssh error
On 23/02/2011 21:19, Martin Paljak wrote: >> Enter PIN for 'MyEID (User Auth)': >> C_Sign failed: 257 > This means: #define CKR_USER_NOT_LOGGED_IN(0x101UL) > Having OpenSC debug.log would be useful - is the right PIN verified before as > it should be. I tried to enable debug.log, but only got an empty file... Is there a guide somewhere? So I tested w/ a key created as: keyuse=digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment,keyAgreement,keyCertSign,cRLSign pkcs15-init -G rsa/2048 --insecure --id 1001 -u $keyuse -l "da-tecnici" --pin $PIN1 And I still get that NOT_LOGGED_IN ! :( Since no pin is to be asked, why does it say I'm not logged in? BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Atomic cert import
Hi all. Could it be possible to check the available space on card files before importing PKCS12 certs? Or at least "rollback" already done additions. Now it could easily happen that a cert is only partially stored, since the private key goes first, then every cert in the chain. So after an import I could find a partial cert, maybe only the private key and a first-level cert, w/o the rest of the chain. Should I file it as an enhancement request in the tracker? Tks, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ssh error
Il 23/02/2011 20:04, NdK ha scritto: Extracted from pcscd log (just masked PIN): -8<-- openct/proto-t1.c:350:t1_transceive() SW: 90 00 winscard_msg_srv.c:317:SHMProcessEventsContext() command TRANSMIT received by client 11 winscard.c:1651:SCardTransmit() Send Protocol: T=1 APDU: 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5C 29 A6 37 70 CA 00 32 95 C7 64 4D 94 89 CA 5A 9D 46 25 F1 00 ifdhandler.c:1170:IFDHTransmitToICC() usb:04e6/5115:libhal:/org/freedesktop/Hal/devices/usb_device_4e6_5115_504012DD_if0 (lun: 0) commands.c:1990:CmdXfrBlockTPDU_T1() T=1: 41 and 260 bytes openct/proto-t1.c:570:t1_build() more bit: 0 sending: 00 40 29 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5C 29 A6 37 70 CA 00 32 95 C7 64 4D 94 89 CA 5A 9D 46 25 F1 00 F1 -> 00 6F 2D 00 00 00 00 66 00 00 00 00 40 29 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5C 29 A6 37 70 CA 00 32 95 C7 64 4D 94 89 CA 5A 9D 46 25 F1 00 F1 <- 00 80 06 00 00 00 00 66 00 00 00 00 40 02 69 82 A9 received: 00 40 02 69 82 A9 openct/proto-t1.c:350:t1_transceive() SW: 69 82 winscard_msg_srv.c:317:SHMProcessEventsContext() command TRANSMIT received by client 11 winscard.c:1651:SCardTransmit() Send Protocol: T=1 APDU: 00 20 00 02 08 3x 3x 3x 3x 3x 3x FF FF ifdhandler.c:1170:IFDHTransmitToICC() usb:04e6/5115:libhal:/org/freedesktop/Hal/devices/usb_device_4e6_5115_504012DD_if0 (lun: 0) commands.c:1990:CmdXfrBlockTPDU_T1() T=1: 13 and 258 bytes openct/proto-t1.c:570:t1_build() more bit: 0 sending: 00 00 0D 00 20 00 02 08 3x 3x 3x 3x 3x 3x FF FF 27 -> 00 6F 11 00 00 00 00 67 00 00 00 00 00 0D 00 20 00 02 08 3x 3x 3x 3x 3x 3x FF FF 27 <- 00 80 06 00 00 00 00 67 00 00 00 00 00 02 90 00 92 received: 00 00 02 90 00 92 openct/proto-t1.c:350:t1_transceive() SW: 90 00 winscard_msg_srv.c:317:SHMProcessEventsContext() command TRANSMIT received by client 11 winscard.c:1651:SCardTransmit() Send Protocol: T=1 APDU: 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5C 29 A6 37 70 CA 00 32 95 C7 64 4D 94 89 CA 5A 9D 46 25 F1 00 ifdhandler.c:1170:IFDHTransmitToICC() usb:04e6/5115:libhal:/org/freedesktop/Hal/devices/usb_device_4e6_5115_504012DD_if0 (lun: 0) commands.c:1990:CmdXfrBlockTPDU_T1() T=1: 41 and 260 bytes openct/proto-t1.c:570:t1_build() more bit: 0 sending: 00 40 29 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5C 29 A6 37 70 CA 00 32 95 C7 64 4D 94 89 CA 5A 9D 46 25 F1 00 F1 -> 00 6F 2D 00 00 00 00 68 00 00 00 00 40 29 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5C 29 A6 37 70 CA 00 32 95 C7 64 4D 94 89 CA 5A 9D 46 25 F1 00 F1 <- 00 80 06 00 00 00 00 68 00 00 00 00 40 02 69 82 A9 received: 00 40 02 69 82 A9 openct/proto-t1.c:350:t1_transceive() SW: 69 82 winscard_msg_srv.c:317:SHMProcessEventsContext() command END_TRANSACTION received by client 11 winscard.c:1212:SCardEndTransaction() Status: 0x winscard_msg_srv.c:306:SHMProcessEventsContext() Client has disappeared: 11 winscard_svc.c:146:ContextThread() Client die: 11 -8<-- IIUC it tries the sign, it fails because private key needs PIN, sends PIN (result OK: 90 00), retries the sign and fails again. BTW it's an awful authentication since the PIN is sent everytime in cleartext to the card, but that's another story... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ssh error
On 23/02/2011 21:19, Martin Paljak wrote: >> Waiting to "fix" CA issue, I'm trying to use an on-card key to >> authenticate a SSH user. > Which issue? http://www.opensc-project.org/pipermail/opensc-devel/2011-February/016065.html Seemed unrelated, but... >> But when I try to use it, I get: >> -8<-- >> $ ssh otheruser@myhost >> Enter PIN for 'MyEID (User Auth)': >> C_Sign failed: 257 > This means: #define CKR_USER_NOT_LOGGED_IN(0x101UL) Uhm... So it *might* be related. Always "user not logged in"... > Having OpenSC debug.log would be useful - is the right PIN verified before as > it should be. I'll post it on my site ASAP. The PIN is right: if I give the wrong one, it clearly says so. >> Just issuing multiple times the same command (w/o touching the card or >> the reader!) solves the issue. > That is interesting. I'm seeing this as well quite a lot with different > Estonian eID cards recently. I've not extracted logs from pcscd for this > problem but that might be useful. I tink it's "normal" if pkcs11 module is loaded in a Mozilla app (that "pings" the card continuously, practically hogging it... but that's IMHO a bug in Mozilla code, that should work more cooperatively). But I unloaded it, so it shouldn't be the root of this isue. > Does unpower/hard reset of the card work? If I take the card out and reinsert it, then it's OK the first time. > If you could produce a pcscd/libccid log with USB level output [1] > would be very good. I'll do it and post it w/ the other. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ssh error
On 23/02/2011 16:57, Peter Stuge wrote: >> Even an strace didn't help locating the lib that can't be loaded. > Was that strace -fF ? No. I'll try tomorrow to be consistent (on the same machine). But could reproduce on this one too. The only failing open is the one related to libgost.so . If I: ln -s /usr/lib64/openssl-1.0.0d/engines/libgost.so /usr/lib64/libgost.so then the message changes: -8<-- $ ssh pvs Enter PIN for 'MyEID (User Auth)': C_Sign failed: 257 ssh_rsa_sign: RSA_sign failed: error::lib(0):func(0):reason(0) -8<-- And all those zeroes make me think bad things... BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] ssh error
Hello. I'm always the one that finds problems :) Waiting to "fix" CA issue, I'm trying to use an on-card key to authenticate a SSH user. Key is there, and should have all needed flags set (generated w/ -u sign,decrypt since IIUC ssh requires both): -8<-- Private RSA Key [SSH: ndk] Object Flags : [0x3], private, modifiable Usage : [0x2E], decrypt, sign, signRecover, unwrap Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref: 6 Native : yes Path : 3f0050154b06 Auth ID: 02 ID : 1000 -8<-- Public key is loaded in the right authorized_keys, and it have the right permissions: tested w/ key in id_rsa file, that works). But when I try to use it, I get: -8<-- $ ssh otheruser@myhost Enter PIN for 'MyEID (User Auth)': C_Sign failed: 257 ssh_rsa_sign: RSA_sign failed: error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library Permission denied (publickey,password,keyboard-interactive). -8<-- Even an strace didn't help locating the lib that can't be loaded. After that, I often find the card unresponsive after that error: -8<-- $ pkcs15-tool -k Using reader with a card: SCM SCR 335 [CCID Interface] (504012DD) 00 00 Failed to connect to card: Unresponsive card (correctly inserted?) -8<-- Just issuing multiple times the same command (w/o touching the card or the reader!) solves the issue. Any hint? Tks! BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
On 19/02/2011 10:52, Martin Paljak wrote: > Unfortunately engine_pkcs11 (and OpenSSL in general) is not the best > interface for smart cards, especially for user interaction purposes. But a > patch against engine_pkcs11 might make the prompt a bit easier to understand > [1] But it's good for scripts :) I finally could make newest openssl load config file with pkcs11_section. It just needs to be the only engine, initialized immediately (only changed init=0 to init=1 to make it work!): -8<-- openssl_conf = openssl_init [openssl_init] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /usr/lib/openssl/engines/engine_pkcs11.so MODULE_PATH = /usr/lib/opensc-pkcs11.so init = 1 -8<-- IIUC openssl's config syntax, the first two non-empty rows could be removed, since the first just tells it to read the section defined by the second. Hope that can help others. Now I get: -8<-- $ openssl req -config openssl.cnf -new -engine pkcs11 -key 3:10 -keyform engine -extensions CA_ROOT -x509 -out root_ca/ca.pem -text -subj "/CN=csshl.org root CA" engine "pkcs11" set. PKCS#11 token PIN: 3075020424:error:8000A101:Vendor defined:PKCS11_rsa_sign:User not logged in:p11_ops.c:131: 3075020424:error:0D0C3006:asn1 encoding routines:ASN1_item_sign:EVP lib:a_sign.c:279: -8<-- Why "User not logged in"? PIN is correct and not locked (verified by opensc_explorer). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Multiple certs on a MyEID card?
On 22/02/2011 15:41, Toni Sjoblom - Aventra wrote: > Sorry, the public key size for the 2K was missing from that value. That > explains the 320 bytes difference. > Public key file for a 2K bit key is 270 bytes. Also, some space is occupied > when new files are added as well. Ok. So 32 2048bit keypairs, w/o certs, requires about 55K (32*(1296+270+180)), leaving about 5k for bookkeeping, labels, etc. This could be a "maxkeys" profile. A more balanced one could account for 14 private keys, 2 public keys and 18 certs (enough if all are issued by the same root CA and there aren't too many different intermediate CAs): (14*(1296+90) + 2*(270+90) + 18*(2048+90)) = 58608 14 private keys so that every key can have a different PIN. But that's a bit more "borderline". When creating more option profiles can I redefine only what's needed (inheriting from "default" the rest) or shoul I redefine all values? > Keep in mind that if you try to optimize the DIR file (CDF, PuKDF, PrKDF..) > sizes to the maximum, it means that you have no space left for other data > objects, e.g. images etc. Yup. That's the target, for now. :) > And also the time taken to read the card increases with large DIR files. This can be bad :( > This is due to the fact that the files are read in chunks over a somewhat > old and slow interface that the standard APDU protocol is. Yup. Chunks <=255 bytes, over a slow serial link. :( > Newer and improved interfaces exist, but are not widely supported/used. Shouldn't that be something taken care of by the driver? > My opinion is > that the profile should be tweaked for each use case, while at the same time > the default profile should be a reasonable compromise between using the > maximum space and no space. I agree that currently the MyEID profile has too > small file. This has historic reasons from a time when the memory size was > limited on javacards. Hope to see soon 1M cards w/ displays and keys :) Jokes apart (well... flexible displays and on-card buttons are already available... hint hint... what's missing is the "big memory"), having some specialized example profiles could greatly help who is tweaking a card for his specific needs, w/o the need to study in great detail how files are used. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Multiple certs on a MyEID card?
On 22/02/2011 13:56, Toni Sjoblom - Aventra wrote: > The private key files sizes are shown in bits not bytes. A 1K private key > uses approx. 960 bytes and 2K respectively approx. 1296 bytes. This consists > of both the private and public parts. This matches my experimental numbers better :) 28548 (free space before keypair gen) - 24052 (free space after keypair gen) - 2880 (pukdf) = 1616 It's still 320 extra bytes, but at least it's closer. Bookkeeping? > The DIR files do not grow when > creating new files, they are created once during initialization with a size > that's defined in the driver's profile. But it seems they get created only when needed: pukdf (EF 4403) was not present until keypair creation. So if I only import certificates I won't have pukdf anywhere (room for an extra cert :) ). I'll soon post some more tweaking since now I've better data to work on. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
On 21/02/2011 14:03, Christian Hohnstaedt wrote:
> XCA 0.8.x used the engine_pkcs11.
Ok. In Mandriva I had only 0.8.1 rpm.
> In version 0.9.0, I dropped the need of engine_pkcs11 and use the
> signing routines of the pkcs11 lib directly. Mainly to support multiple
> PKCS11 provider in parallel.
> So maybe XCA 0.9.0 will work for you.
Removed 0.8.1 from RPM and installed newly compiled 0.9.0. But when I
select Token -> Manage Security Token -> "MyEID (Root CA)" (argh! still
"slots" at work! so are they "users" in PIN<=>user 1:1 relation? and why
can't I have keys not associated w/ a PIN, for low-security needs?) it says:
-8<--
The following error occured:
(pki_scard:)
error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared
library
error:25070067:DSO support routines:DSO_load:could not load the shared
library
error:260B6084:engine routines:DYNAMIC_LOAD:dso not found
(pki_key.cpp:273)
-8<--
then says "The token 'MyEID (Root CA)' did not contain any keys or
certificates", but the keys are there (cut from pkcs15-tool -D):
-8<--
PIN [Root CA]
Object Flags : [0x3], private, modifiable
ID : 03
Flags : [0x30], initialized, needs-padding
Length : min_len:4, max_len:8, stored_len:8
Pad char : 0xFF
Reference : 4
Type : ascii-numeric
Path :
Private RSA Key [Root CA]
Object Flags : [0x3], private, modifiable
Usage : [0x4], sign
Access Flags : [0x1D], sensitive, alwaysSensitive,
neverExtract, local
ModLength : 2048
Key ref: 8
Native : yes
Path : 3f0050154b08
Auth ID: 03
ID : 10
Private RSA Key [Intermediate CA 1]
Object Flags : [0x3], private, modifiable
Usage : [0x4], sign
Access Flags : [0x1D], sensitive, alwaysSensitive,
neverExtract, local
ModLength : 1024
Key ref: 9
Native : yes
Path : 3f0050154b09
Auth ID: 02
ID : 20
Private RSA Key [Intermediate CA 2]
Object Flags : [0x3], private, modifiable
Usage : [0x4], sign
Access Flags : [0x1D], sensitive, alwaysSensitive,
neverExtract, local
ModLength : 1024
Key ref: 10
Native : yes
Path : 3f0050154b0a
Auth ID: 01
ID : 20
Public RSA Key [Root CA]
Object Flags : [0x2], modifiable
Usage : [0x4], sign
Access Flags : [0x0]
ModLength : 2048
Key ref: 0
Native : no
Path : 3f0050155503
ID : 10
Public RSA Key [Intermediate CA 1]
Object Flags : [0x2], modifiable
Usage : [0x4], sign
Access Flags : [0x0]
ModLength : 1024
Key ref: 0
Native : no
Path : 3f0050155504
ID : 20
Public RSA Key [Intermediate CA 2]
Object Flags : [0x2], modifiable
Usage : [0x4], sign
Access Flags : [0x0]
ModLength : 1024
Key ref: 0
Native : no
Path : 3f0050155505
ID : 20
-8<--
[Note that's the same card I used to test the "multiple keys w/ same id"
issue: the two intermediate CAs have ID 20]
Doing an strace and grepping for '.so' all I see is:
-8<--
open("/usr/lib/opensc-pkcs11.so", O_RDONLY) = 15
open("/etc/ld.so.cache", O_RDONLY) = 15
open("/usr/lib/libopensc.so.3", O_RDONLY) = 15
access("/lib/libpcsclite.so.1", R_OK) = -1 ENOENT (No such file or
directory)
access("/usr/lib/libpcsclite.so.1", R_OK) = 0
open("/usr/lib/libpcsclite.so.1", O_RDONLY) = 15
open("/etc/ld.so.cache", O_RDONLY) = 19
open("/lib/i686/libgost.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libgost.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/sse2/libgost.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libgost.so", O_RDONLY) = -1 ENOENT (No such file or
directory)
-8<--
Can't find any "gost" package, except perl-Crypt-GOST, that I think it's
not useful.
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
On 19/02/2011 10:52, Martin Paljak wrote: > XCA worked with OpenSC quite OK IIRC, you might want to try it as well. Done. All I get from XCA, when loading /usr/lib/opensc-pkcs11.so is: -8<-- The following error occured: Successfully loaded PKCS#11 library: /usr/lib/opensc-pkcs11.so SUCCESS: 'SO_PATH' : '/usr/lib/engines/engine_pkcs11.so' SUCCESS: 'ID' : 'pkcs11' SUCCESS: 'LIST_ADD' : '1' FAILED: 'LOAD' : '' error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library error:25070067:DSO support routines:DSO_load:could not load the shared library error:260B6084:engine routines:DYNAMIC_LOAD:dso not found -8<-- That's the same I get when using openssl directly (quite "obvious", since it seems XCA didn't reinvent the wheel and uses openssl as a backend). I used a text file and redirection to avoid errors when submitting commands, but it seems I still miss something. > Unfortunately engine_pkcs11 (and OpenSSL in general) is not the best > interface for smart cards, especially for user interaction purposes. > But a patch against engine_pkcs11 might make the prompt a bit easier > to understand [1] Well, I'm not scared of "complex" interfaces, if they're well documented. Too bad openssl docs about engine module are missing (or at least I can't find 'em). I could "more or less" understand what-does-what, but it's always something that could easily be wrong. BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
On 18/02/2011 10:54, NdK wrote: >>> *But* if I specify a slot too, it asks me for a PIN. Too bad *none* of >>> the PINs I created works: >>> $ openssl req -days 3650 -new -out rootca.csshl.org.csr -config >>> openssl.conf -engine pkcs11 -keyform engine -key 1:10 -sha1 Today openssl refusess to load engine from config (auto-upgraded to openssl-1.0.0a)... Already seen some old topics in list :( But, at least, using "interactive" mode seems to work. >> Have you tried some other format? slot_XX:id_XX ? (even though it should be >> the same). Having OpenSC log with the relevant C_OpenSession() and C_Login >> lines is useful as well. > Yup. All formats. Same result: slot 0 = no PIN, every other slot asks > 'who knows' PIN. Finally found by trial & error (after unlocking the PINs). In my case slot is 3 and ID is 10. So is slot the PIN# needed to unlock the key? But in that case, why isn't it auto-detected? > Using opensc-explorer, I could see that now I have a locked PIN (the #2). > But "pkcs15-tool -u" gives me a strange prompt: > Enter PUK [Security Officer PIN]: > Enter new PIN [Security Officer PIN]: > Enter new PIN again [Security Officer PIN]: > > So does it need PUK for CHV2, SOPIN or what else? Luckily this card is > just a "test" one, but I'd like *not* having to reformat it... 4 tries > left... Now "fixed" by using opensc-explorer, so I still have a working card. But can do some more tests if needed. BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
Il 18/02/2011 07:07, Martin Paljak ha scritto: >> Yup. That's why keys are generated on card :) > Unless the key is exportable Always asked why one needs to mark a private key exportable: if you need it exportable, create it externally and load to card. It's even faster. :) > If you want to sign certificates with a smart card (run a CA against a > PKCS#11 token) then EJBCA is the most feature complete solution I know. But > most probably too much hassle for a few certificates for home use. Well, for now it's personal, but I'm evaluating it for office use too. We'll need to setup a ZeroShell box to authenticate users, and it contains a (quite limited, but sufficient if it supported cards) CA. >> *But* if I specify a slot too, it asks me for a PIN. Too bad *none* of >> the PINs I created works: >> $ openssl req -days 3650 -new -out rootca.csshl.org.csr -config >> openssl.conf -engine pkcs11 -keyform engine -key 1:10 -sha1 > > Have you tried some other format? slot_XX:id_XX ? (even though it should be > the same). Having OpenSC log with the relevant C_OpenSession() and C_Login > lines is useful as well. Yup. All formats. Same result: slot 0 = no PIN, every other slot asks 'who knows' PIN. >> I obviously tried all the PINs (included SOPIN). The strange thing is >> that NO PIN is locked after all the tries I did... > Is any PIN locked or counter decreasing? What is the output of pkcs11-tool > --module /path/to/pkcs11.so -L ? $ pkcs11-tool -L Available slots: Slot 0 (0x): Virtual hotplug slot (empty) Slot 1 (0x1): SCM SCR 335 [CCID Interface] (504012DD) 00 00 token label: MyEID (Card Auth) token manuf: Aventra Ltd. token model: PKCS#15 token flags: rng, login required, PIN initialized, token initialized serial num : 7340050446913028 Slot 2 (0x2): SCM SCR 335 [CCID Interface] (504012DD) 00 00 token label: MyEID (User Auth) token manuf: Aventra Ltd. token model: PKCS#15 token flags: rng, login required, PIN initialized, token initialized serial num : 7340050446913028 Slot 3 (0x3): SCM SCR 335 [CCID Interface] (504012DD) 00 00 token label: MyEID (Root CA) token manuf: Aventra Ltd. token model: PKCS#15 token flags: rng, login required, PIN initialized, token initialized serial num : 7340050446913028 Slot 4 (0x4): SCM SCR 335 [CCID Interface] (504012DD) 00 00 token label: MyEID token manuf: Aventra Ltd. token model: PKCS#15 token flags: rng, token initialized serial num : 7340050446913028 Slot 5 (0x5): SCM SCR 335 [CCID Interface] (504012DD) 00 00 (empty) [other slots all empty] $ pkcs15-tool --list-pins Using reader with a card: SCM SCR 335 [CCID Interface] (504012DD) 00 00 PIN [Security Officer PIN] Object Flags : [0x3], private, modifiable ID : ff Flags : [0xB0], initialized, needs-padding, soPin Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 3 Type : ascii-numeric Path : PIN [Card Auth] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x30], initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 1 Type : ascii-numeric Path : PIN [User Auth] Object Flags : [0x3], private, modifiable ID : 02 Flags : [0x30], initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 2 Type : ascii-numeric Path : PIN [Root CA] Object Flags : [0x3], private, modifiable ID : 03 Flags : [0x30], initialized, needs-padding Length : min_len:4, max_len:8, stored_len:8 Pad char : 0xFF Reference : 4 Type : ascii-numeric Path : Says nowhere that a PIN is locked... Using opensc-explorer, I could see that now I have a locked PIN (the #2). But "pkcs15-tool -u" gives me a strange prompt: Enter PUK [Security Officer PIN]: Enter new PIN [Security Officer PIN]: Enter new PIN again [Security Officer PIN]: So does it need PUK for CHV2, SOPIN or what else? Luckily this card is just a "test" one, but I'd like *not* having to reformat it... 4 tries left... BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CA key on card: how?
On 17/02/2011 22:55, Andreas Jellinghaus wrote: > no, that wiki page is correct and works for me - done it a hundred times. > it uses the key on the card, and the card does the signature (you cannot > read the private key, a smart card won't ever give it to you). Yup. That's why keys are generated on card :) > so maybe "10" is the wrong key id or something like that? I generated it with $ pkcs15-init -G rsa/2048 -a 3 --id 10 -l "Root CA" and "pkcs15-tool -k" shows, amongt others: Private RSA Key [Root CA] Object Flags : [0x3], private, modifiable Usage : [0x4], sign Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref: 8 Native : yes Path : 3f0050154b08 Auth ID: 03 ID : 10 So it seems correct. *But* if I specify a slot too, it asks me for a PIN. Too bad *none* of the PINs I created works: $ openssl req -days 3650 -new -out rootca.csshl.org.csr -config openssl.conf -engine pkcs11 -keyform engine -key 1:10 -sha1 engine "pkcs11" set. PKCS#11 token PIN: Login failed PKCS11_get_private_key returned NULL cannot load Private Key from engine 3074688648:error:800050A4:Vendor defined:PKCS11_login:PIN locked:p11_slot.c:157: 3074688648:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:126: unable to load Private Key I obviously tried all the PINs (included SOPIN). The strange thing is that NO PIN is locked after all the tries I did... Any hint about where to bang my head? Tks! BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] CA key on card: how?
Hi all. I'm now looking at another issue. Having stored "enough" certs on card, I'm now trying to push it to the limit. Seems that openssh can't be told which key to use, but that's not OpenSC related (unless someone here knows how to do it). So falling back to pam_pkcs11 and CA handling. I've found a lot of tutorials to use openssl to generate self-signed certs (OK for my root CA), but couldn't find one where the signature is done by the card. Even on http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart seems openssl requires read access to the secret key, actually "banning" keys generated on-card: $ openssl req -config openssl.conf -engine pkcs11 -new -key 10 -keyform engine -out req.pem -text -x509 -subj "/CN=csshl.org Root CA" engine "pkcs11" set. Invalid slot number: 0 PKCS11_get_private_key returned NULL cannot load Private Key from engine 3075466888:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:126: unable to load Private Key Any hint on how to instruct openssl to use the card to sign? And on a related issue (step 2), can the public key be removed after loading the cert? Tks! BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Multiple certs on a MyEID card?
On 16/02/2011 21:59, Martin Paljak wrote: >>> I would not date to suggest turning<1024 key support off (which is the >>> recommendation by several organizations) but giving a nice fat warning to >>> the user when creating keys (not importing!) below 1024 (or 1024 keys when >>> the card claims support for 2048) bits. >> That could be done for every key size less than the maximum handled by >> the card. This way the user is encouraged to use the maximum available >> security, and fall back to less secure keys only if he needs to. > :) > > Nice one! Can you please file it as a wish list ticket with a link to this > thread as well, so that it won't slip through the cracks? (added a note about > list thread links to ReportingBugs [1] page as well) Ticket 331 created. > Thanks for your input, if all of the things won't get fixed for the next > release (0.12.1) then surely in one of the succeeding builds. Which could > eventually happen as often as on biweekly basis. Marked for "someday". > If you can, please post about your experiments with MyEID profile tweaks as > well, so that the default profile could be improved. Already did that on my site (but only in Italian, for now... I was waiting for something "definitive" before translating. You can see it at: http://www.csshl.net/content/smartcard-conservare-certificati-e-chiavi-ssh (on a single line). The setting I'm now using is the one in the third comment. BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
