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 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 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 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 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 keycert 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 certkey 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 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 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 keycert 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=productprod_sections=0id=CRYPTOMATE64 See my message dated 2012/05/23. Doesn't cost too much (less than 50€, and a lot is due to shipment). I'm even thinking about using a Raspberry PI to handle it and export functions via Ethernet. Another possible (and maybe WAY cheaper, in medium volumes) alternative would be to use a cut down Android phone (take one the cheapest one, remove or don't install radios, write a custom firmware and bootloader, and you'll have a cheap token that can handle RSA16384, EC, OTP even when disconnected from a PC, and pretty much everything you can think of). Non-stripped old smartphones are already quite cheap, way cheaper than any other comparable solution. And if you ask a supplier for a lot w/o radios they should come at bargain price... The SIM slot could easily host a crypto smartcard to unlock credentials stored in the device (on a microSD, maybe). BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 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] 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] 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] 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] CRYPTOMATE64
Il 25/05/2012 10:59, Martin Paljak ha scritto: Hello, On Wed, May 23, 2012 at 2:57 PM, NdK ndk.cla...@gmail.com 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
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
[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] 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
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 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
[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=productprod_sections=0id=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] 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
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] 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] 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] 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] 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
[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] 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
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
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] 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] 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
Il 03/08/2011 09:32, helpcrypto helpcrypto ha scritto: Do yo code on assembly for you web pages? PCSC should be used only if your smartcard doesnt have a higher level of abstraction possible (like opensc) I'd even prefer higher APIs, since doing security really well is hard. I usually do C, but this time I need a java applet for: 1) a web-based password manager I have to write for the office If you explain more, i can tell you my opinion about what you could need/do I need to implement a multiuser web password manager that allows users to group-share passwords (so Linux sysadmins don't have access to Windows passwords -- yes, I know AD, it's just an example). Server NEVER knows plaintext passwords, so even if it gets hacked no sensitive information is disclosed. Passwords must not be displayed, just gets copied to the clipboard (so I can access firewall password even if I'm in a lab with a dozen users behind my shoulders). 2) safely and strongly authenticate users to a plain HTTP page (very shared-hosting friendly!) -- I already can authenticate users w/ a smartcard (on https), but it needs Firefox to load its PKCS11 that locks the card and no other process can use it. must be a problem with your code. Actually, our card is used by firefox+thunder+ie+local apps at the same time. Known bug in FF, IIUC. When you insert the card (or load opensc-pkcs11) it C_Login to every slot even if you're not accessing certs. So: 1) it asks for EVERY pin (even signature ones) 2) while opensc-pkcs11 is loaded in FF, thunderbird (nor any other PKCS11 'client') doesn't see the card Anyway, auth using 'internal' method is possible only on https sites (unavailable on shared-hosting plans, and it's now giving me headaches since I need to use SNI, that's not supported by IE on XP). You can observe what others do: Always useful. Spanish tax ministry dont use Applets (use native componentes), which doesnt require the user to have java. But, IIUC, that restricts use to only supported browser/platform -- I have labs w/ Linux machines, workstations w/ Windows XP (some w/ only IE, some w/ FF), quite a lot of Macs... The minimum common denominator can be Java w/ a minimum of must-have native libs (like pcsc-lite and ccid), even if it could be even better if those aren't needed. https://www.agenciatributaria.gob.es/AEAT.sede/Inicio/Inicio.shtml Spanish ecofirma (also from gov) uses an applet that downloads a jnlp that install everything needed on your computer http://oficinavirtual.mityc.es/javawebstart/soc_info/ecofirma/index.html This assumes that the user: - can install sw - usually uses only one machine In our company, we use smartcard for client/user authentication using certificates, and also mail signing and document signing. For web applications we use a signed applet. This applet is done using Oracle/Sun JCE (java 1.6). Seems that SUN = 1.6 jre its the only one which had cryptography some time ago. Maybe this has changed and now openjdk include it. You should ask on java lists (and update me with the news, PLEASE!). I'm using Sun JVM too, since professor's digital signing applet needs it, too. The applet side is made by another person, but im the developer of the pkcs11 library that runs on osx, win and linux. Its not made using opensc due its a legacy code that have been re-coded just a few months ago, and 'cause our card its not pkcs#15, either really criptographic. (at least its PCSC!) Well, I'm using Aventra cards, so they're both PKCS15 and cryptographic :) I thougt you can't have legally strong signature unless you're using a crypto card (at least here in Italy). Anyhow, on a recent discussion on mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=654939), i was sadly surprised to read things like: If Java is trying to load Firefox's NSS libraries, it deserves to not work. Having external apps digging through the Mozilla cert store is not recommended or supported in any case. This is not something that we intend to support or fix. No, writing enterprise apps which poke into the Firefox certificate store is not a desired use-case, especially while the app is running. I know that JSS is used for server applications written in Java. I was not even aware that it's possible to use JSS inside browser applets. ... (and many more) Sometimes I can't understand'em... Like for the support of DNS extensions (commonly used by voip, jabber, Active Directory...) to tell on which port is https listening... IIRC it's about 10 years that a patch is available but never got adopted! So, in other words...altough Java has examples, doc and code to explain how to use JSS (Java to NSS) and its working perfectly, this seems to be a bad thing for mozilla's people. I still have to discuss at https://lists.mozilla.org/listinfo/dev-platform On IE, you should code a CSP/CNG to access the smartcard and on Safari, you could use opensc or a tokend. Chrome depends on the system. That's
Re: [opensc-devel] Java and pkcs11
Il 03/08/2011 11:08, helpcrypto helpcrypto ha scritto: As i understand, you want to develop like a wallte, where password stored on server (crypted) are copied to clipboard (altough a simply CTRL+V will display it), to let the user authenticate in toher services. Right? Yup. Right. Ctrl-V is the smallest problem (a bigger one is KDE's cache in system tray) and should be solved politically (even KDE's cache can be cleared inserting enough random strings. But that's really OT here. You need applets cause the access to this wallet is using smartcard? certificate? The wallet must allow for use of a smart card or a simple password (obviously highly sensitive passwords will have to be restricted to stronger method). Not really different at the programmatic level, since I can store anything in the encryptedPrivateKey field: an actual key or a reference to a token. Known bug in FF, IIUC. When you insert the card (or load opensc-pkcs11) it C_Login to every slot even if you're not accessing certs. So: 1) it asks for EVERY pin (even signature ones) Whats IIUC means? If I Understand Correctly. With our company card+spanish ID (dnie) on different readers, while doing client auth, it ask for 2 pins (one for each slot), to retrieve ALL the certs from all the slots/tokens. That's exactly what I noticed. Seems the key is the friendly flag that's (IMVHO) badly thought (since I can access both friendly and unfriendly tokens w/ the same lib). And (more general question) why a slot identifies a pin? What about insecure keys and their certs? See below. That, let FF to show a windows to select all possible certs. Is this the scenario you are pointing? Can you give me the bugzilla number? (From my experience, NSS or the part responsible from retrieving the certs its not very efficient...for example, it request like 150 times for vendor objects on my token, altough the first time i say i have no one) Well, just searching smart card in bugzilla pops up quite a lot of issues. 460985 e 378476 (always selects the first cert from a card), 453025 (security devices only loaded on application start) and many more... I think we should exchange experiences :P Mine is just: too buggy to be actually used w/ smartcards, useful only in the simplest scenarios. 2) while opensc-pkcs11 is loaded in FF, thunderbird (nor any other PKCS11 'client') doesn't see the card Thats a opensc desired/undesired behaviour. If OpenSC did that for any reason, you could ask here (or martin). But i can tell you, its not FF the one who locks, cause my smartcard can be used and viewed by many at the same time. (Thanks god PCSC's BeginTransaction and EndTransaction methods) I can't retrieve now the bug #, but IIRC it keeps the session to the token open. Maybe your card allows for more than one channel. Anyway, auth using 'internal' method is possible only on https sites (unavailable on shared-hosting plans, and it's now giving me headaches since I need to use SNI, that's not supported by IE on XP). No idea of what internal means, SNI, or what are you taliking about. Internal is when the https server asks for a client cert. SNI is an extension to TLS that allows more than one https virtual host on an IP/port by giving the requested server name at the start of the handshake. We have that 3 systems, and support for 3 major browser on each Firefox/Chrome/IE/Safari. I thinks thats neough for end users...come on, dont make me support lynx please. No, but writing 9 different apps is not the solution, IMVHO. BTW, dont expect a friendly environment using Java on OSX, this guys hate them. I'll have to fight whith it, then :) This assumes that the user: - can install sw Copying files its not always needed, but access to the system its. Signed applets will let you access the system, and you could whatever you want. Nope. You can install sw only if the policy allows you to do it. And often (think about a kiosk) it's forbidden. A signed applet can AT MOST have the same rights of the user, IIRC (I don't remember a poliy to give an applet more rights than the ones assigned to the user running it...). - usually uses only one machine Not true...it just extract and run, even better that installing a client software. Uh, right... jnlp headaches... :) Still needs JVM, pcsc, etc... And it's anyway better if the downloaded app is signed... So I don't see real dvantages here. If only SunPKCS11 would be more versatile... Maybe the simplest thing is to get its source and hack it, so that it: - supports plain on-card keypairs - only asks PIN when needed AFAIK, both can be done. Not w/ standard SunPKCS11. See below. - handles multiple slots What you mean with this? That's something I still couldn't understand well... Reading PKCS11-v2.30b specs, it seems a slot is just a physical object where a card can be placed. So a reader should present more than one slot only if it accepts more than one token: Cryptoki provides an interface to
Re: [opensc-devel] Java and pkcs11
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
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
On 03/08/2011 19:40, helpcrypto helpcrypto wrote:
Well... The user should be responsible for selecting the best slot.
That IMHO shouldn't be a slot in the first place, but just a
certificate. The browser should only filter certs so that only
acceptable ones are proposed to the user.
Thats what actually is done, isnt it? At least, after the pin request,
a window with certs is shown to select one...
Yes. But in my head it should work the other way around: ask for the PIN
only if no suitable object is found. If user wants to use a private
object, he must authenticate first.
If an object isn't accessible ('cause it's marked private), it should
user's responsibility to login w/ the correct credentials first.
The NSS should detect the flag, and if needed, call C_Login or do the
operations needed. Sometimes the object is not extractable from the
smartcard, so it depends.
Usually just private (or secret) keys are unextractable.
Maybe the PIN should be cached cause sometimes card can be reset
between calls, and that loose the security access.
Unless the object is marked for user consent.
Thats the reason why spanish ID its requesting the PIN all the time(?)
Probably 'cause it's for signature, so it's marked user-consent
(uncacheable).
BYtE,
Diego.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
On 03/08/2011 21:25, Martin Paljak wrote: And what about smartphones? Standard Java is more likely to be adapted than proprietary interfaces. I don't believe that current smartphone platform vendors will embrace PKCS#11 as we know it on the desktop. At least I hope they will not. It would IMHO be a stupid choice. Java is a platform itself, so JCE/JCA could be the key, if anything. It might not be perfect or even most suitable. I agree with Anders that enrollment with mobile devices (with built-in security tokens) should eventually become as important as using keys. Take Android - it does not make use of standard Java API-s (Swing), yet it is very successful. Being able to run the code does not mean having sensible support for a platform with minimal or no code changes. Well, I hope that those portability issues are handled by someone else :) since I'm too lazy to code the same thing w/ small differences for the various platform (or I wouldn't use Java in the first place...). When developing a portable application (in Java..) I would not bet much on PKCS#11 or similar. For optimal results assume that PKCS#11 is not available. I'm planning other possible auth methods, but I'll have to experiment what happens if I try to load my applet on a platform where there's no SunPKCS11 available. My personal suggestion is to omit the proprietary excuse. Whenever running *anything* on Windows (or OS X), you are using a proprietary platform. Either refuse to run on it or try to live with it and make the most out of it by using the services provided by the platform is possible and providing users with as good experience as possible. I simply don't want to adapt my code too much. I don't mind if the platform is proprietary as long as my app works as expected. If I could do that with C, I'd do it. BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Java and pkcs11
Hi all! Maybe it's nearly OT, but I think it could be useful for other readers. I've found that a quite recurring problem in accessing tokens from java is the PKCS11 not found exception. Disabling hot plug support, as suggested in the past to another user, didn't work in my case. The -Djava.security.debug=sunpkcs11 'workaround' is quite unsatisfactory (really slows down startup), but I've found that using SunPKCS11 and a config file containing: -8-- name = smartcard library = /usr/lib/opensc-pkcs11.so slotListIndex=1 -8-- (so, specifying the slotListIndex) I can actually avoid that exception. But every user should determine his own slotListIndex (and, IIUC, it changes if there are certs under different PINs). What I still miss: - why can't I read certs out of the card even if they're publicly readable? - once I can read a cert, how could I determine which slot I should authenticate against to use the corresponding private key? - should I avoid SunPKCS11 and base my program on simple PC/SC? Tks, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Java and pkcs11
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
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] --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 ID of authentication object .
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] 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] --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] 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
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
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 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] 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] 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
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=($PINCHVn)|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
[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
[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
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
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] 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
[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] 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
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] 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] 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] 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] 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?
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 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
[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] 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
Re: [opensc-devel] Multiple certs on a MyEID card?
On 16/02/2011 21:13, Martin Paljak wrote: The same can be done for 768bit key, and, I suppose, for all key sizes from 512 to 2048 with the 64 bit step. The only questions is: are you sure you want to do this? Small RSA keys are often used in low profile hardware, where the smaller calculation is easier to complete, these days EC would be a better option for resource-constrained environments... I would not date to suggest turning1024 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. Just my .02 ... 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 turning1024 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
Re: [opensc-devel] Multiple certs on a MyEID card?
Il 15/02/2011 11:17, Toni Sjoblom - Aventra ha scritto: Hi, Woa. *That's* customer support! Current MyEID cards are 80K, but some of this space is used by the MyEID applet itself. Ok. I'm starting to understand. The file size you see in the 3F00 file is the remaining free space, but due to a limitation of java cards in general, as Martin mentioned, 32k is the largest number for signed short. So I misunderstood. I thought a DF had to be big enough to contain all its sub-DFs and EFs. Good to know I was wrong (I was already thinking about adding another java app for using the remaining space). This only shows that you have at least this amount o space left. To get to know how much space you actually have left, you could create a file that is 32k, and the see how much space is left. Then if you still get the maximum (32k), then create another 32k file and then see the results. By adding these values together you get the actual space. Perfect. Too bad I haven't my cards handy atm, but I'll try ASAP. But I'm still missing some useful details (like typical keysize, how much space does a key need in index files so on)... Looking at that index file might help? Also, every applet will take some memory for internal bookkeeping, so it is not simply 1:1. A single key (private or public) needs typically 70-90 bytes in the dir file (index file). The actual amount depends on the label length. One 1024bit RSA key pair takes 512bytes and one 2048bit key pair takes 960bytes. Ok. So, 'limiting' to 32 keys (due to said limit in pkcs15-tool), I could have: cdf_size = 8640 # 3 * 32 * 90 (an average of 3 keys in every cert) prkdf_size = 2880 # 32 * 90 pukdf_size = 2880 # idem... but why is default smaller than prkdf_size? Storing only 2048-bit keys for 32 different certificates from different CAs (so w/ a different intermediate CA in every cert, that gives me the '3 keys' for cdf_size line) I should end up using about 45k + the certs ... This way I won't be able to add keys or certs only when I reach limits of pkcs15-tool or capacity, right? If so, could those values be included as defaults (maybe for a 'max' profile) in myeid.profile ? PS: seems MyEID can't generate 1024bit keypairs... Is it right? From specs I understood it could work from 512 to 2048... 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 15/02/2011 16:47, Viktor TARASOV wrote: Ok. So, 'limiting' to 32 keys (due to said limit in pkcs15-tool), I could have: cdf_size = 8640 # 3 * 32 * 90 (an average of 3 keys in every cert) You mean 3 certs for each key? I think that it's difficult to generalize this relation, the contexts of the card usage are so different. I think a typical usage is that in every cert there's a root cert (whose key is kept offline) that authenticates an intermediate CA cert key (often kept online), that authenticates user key. So 3 certs for every user key. Obviously there could be CAs that sign user keys directly w/ their master key, and others that have more than one intermediate CA. And really often a user only relies on a single CA for all his/her certs, so needing only one root CA cert and 2-3 intermediate certs (so reducing of 60 certs the storage needs). Of cause the last word is for Toni, but, imho, the actual default value of 'cdf-size' is really too low. I always listen to more experienced people, then err on my own :) As for me it should be around one-two times larger then prkdf-size. I do not have justification for this relation, only very vague considerations: 2-3 certs per key, Ok. So my value was right: 3 times prkdf-size :) prkdf_size = 2880 # 32 * 90 pukdf_size = 2880 # idem... but why is default smaller than prkdf_size? Generally there is no PubKey object corresponding to the imported keys. Imported private key is immediately accompanied with the corresponding certificate or have sufficiently explicit attributes (ID) that allows to link it with the future certificate. Ah, Ok. I thought a pubkey was stored anyway. PS: seems MyEID can't generate1024bit keypairs... Is it right? From specs I understood it could work from 512 to 2048... It can generate 1024bit keys. Yup. But I understood that it could generate keys down to 512. Probably misunderstood the docs. BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Using pkcs15-init to set profile options prkdf-size and pukdf-size
On 15/02/2011 17:26, Viktor TARASOV wrote:
As for me, more appropriate solution is to define in your card profile some
section like 'option my_macros { macros { ... }}',
after (or instead of) the section 'option onepin' (to overwrite the existing
macro value),
and then to use something like:
# pkcs15-init --create-pkcs15 --profile pkcs15+onepin+my_macros
'Normally' it should work.
But that requires root access. Could it be possible to add scanning to a
directory behind user's home (~/.opensc/profiles/ could be a good
candidate) and if a .profile is found, parse it instead of the system
wide one? Just like many other toold so (openssh pops up in my mind :)).
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 15/02/2011 19:47, Viktor TARASOV wrote: Sorry, this card can generate key 512bit . For that the corresponding algorithm should be added to the list of the card's algorithms. --- src/libopensc/card-myeid.c (révision 5194) +++ src/libopensc/card-myeid.c (copie de travail) @@ -100,6 +100,7 @@ flags = SC_ALGORITHM_RSA_RAW | SC_ALGORITHM_RSA_PAD_PKCS1 | SC_ALGORITHM_ONBOARD_KEY_GEN; flags |= SC_ALGORITHM_RSA_HASH_NONE | SC_ALGORITHM_RSA_HASH_SHA1 | SC_ALGORITHM_ONBOARD_KEY_GEN; + _sc_card_add_rsa_alg(card, 512, flags, 0); _sc_card_add_rsa_alg(card, 1024, flags, 0); _sc_card_add_rsa_alg(card, 2048, flags, 0); If the card could handle it (don't know, and not confident enough to recompile opensc), often 768 bits are used for med-low security apps. 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?
Il 14/02/2011 07:15, Martin Paljak ha scritto: $ pkcs15-init -S startssl.p12 -f PKCS12 -i 45 -a 2 -l StartSSL auth Using reader with a card: Gemalto GemPC Twin 00 00 error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure Is this error normal? Does it happen with OpenSSL command line tools or other software? I always get it for PKCS12 certs where the private key is protected by a password. Also with openssl pkcs12 -info for example? I'm now on another machine, but it seems for openssl it's OK: $ openssl pkcs12 -info -in startssl.p12 Enter Import Password: MAC Iteration 1 MAC verified OK PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1 Bag Attributes friendlyName: ID di StartCom Free Certificate Member a StartCom Ltd. localKeyID: 25 83 B6 44 D1 E4 9C D8 5F 97 AE 86 3F CA E0 C4 1D 5D 1A 65 Key Attributes: No Attributes Enter PEM pass phrase: Verifying - Enter PEM pass phrase: [PEM data follows] Might be something related to iterations? ID-s should only be used to bind objects together and have no meaning. So I understood it correctly the first time. But it was worth a try... I found your source as well: pkcs15-init man page, which apparently needs updating... Yup. Sometimes it's better *no* docs than *wrong* ones... pkcs15-init -E BTW, even if I add to this line --so-pin $SOPIN, it gets asked interactively. Another bug? OK, we have a bug. Feel free to file it to Trac as well. Ok. With these values I could iterate 58(!!!) times pkcs15-init -G rsa/1024 ... before EF 4404 (??? why? I'm not storing certs yet!) fills up. Good question, would nee to try it out. But now pkcs15 -D shows me only private and public keys up to the 32nd (limit in the tool?). You're seriously pushing the limits here :) Yes, 32 is a hardcoded limit in pkcs15-tool. I use Linux *exactly* for that: push the HW to its limits... :) 640kb ought to be enough for anybody. This needs to be fixed before the Linux of smart cards will take over and OpenSC becomes the minisoft :) With always bigger cards, limits shouldn't be too tight. Better if there are no hardcoded limits other than the mandatory ones (dictated by a spec: you can't have more than 14 PINs = limit to 14. If I delete a public key, then I can see the 33rd and so on (one more key for every one I delete). *Can't* delete private keys (always says it can't find that key ID): $ pkcs15-init -D privkey --id 6b1414bf460fe3a6711fee7e61c286331f490d1a Using reader with a card: Gemalto GemPC Twin 00 00 NOTE: couldn't find privkey 6b1414bf460fe3a6711fee7e61c286331f490d1a to delete Deleted 0 objects -8-- Maybe this is a bug? If you try to delete both at once (private and public key) will that work? Nope. It only finds the public one. I usually do: $ pkcs15-init -D pubkey,privkey -i $ID I need to check with a MyEID card before further comments but I think you can easily file the issues you found as bugs. If not technical bug it is a usability bug nevertheless Ok. Created #327, #328, #329 . Another thing: seems PIN use is quite fixed by profile. Maybe making it more flexible could help. Now it asks CHV1 every time I add a key, even if I'll need CHV2 to access it. Having a simpler way to override the system-wide profile might improve greatly user experience... 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 14/02/2011 17:52, Andreas Jellinghaus wrote: I have no clue about myeid, but some other cards are only 32k for example. reserving 8192 would be 25% and that is only one directory file... Well, javacards have a limit of 32k of data, IIUC, so it's more or less the maximum for single-app javacards. MyEID have a 3F00 file of 32k, so I think that's the real available size for the primary app (please correct me if I'm wrong). But I'm still missing some useful details (like typical keysize, how much space does a key need in index files so on)... and a fine tuning for each different card and driver: I don't think anyone has the time and manpower for that. Since I have the card and some time, I volunteer to fine tune it so that a card contains the maximum of useful data :) 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 13/02/2011 11:07, Tomas Gustavsson wrote: Did you try to specify the -i parameter when importing certificates? pkcs15-init --store-certificate cert.pem -v -i 45 where i is the key_id? I didn't try with multiple certs actually, but that's how I imported certificates assigning them to a key. See http://blog.ejbca.org/2010/03/using-pure-opensc-formatted-smart-cards.html No way. When importing the second it still says file too small: -8-- $ pkcs15-init -S startssl.p12 -f PKCS12 -i 45 -a 2 -l StartSSL auth Using reader with a card: Gemalto GemPC Twin 00 00 error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure Please enter passphrase to unlock secret key: Importing 3 certificates: 0: /description=319470-SNVg5Hb3589q8dqm/O=Persona Not Validated/CN=StartCom Free Certificate Member/emailAddress=*@* 1: /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2: /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Client CA User PIN [Card Auth] required. Please enter User PIN [Card Auth]: $ pkcs15-init -S ndk2.p12 -f PKCS12 -i 45 -a 2 -l ndk 2 Using reader with a card: Gemalto GemPC Twin 00 00 error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure Please enter passphrase to unlock secret key: Importing 3 certificates: 0: /description=122698-9FVmbs813O0ow3bM/O=Persona Not Validated/CN=StartCom Free Certificate Member/emailAddress=ndk@ 1: /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2: /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Client CA User PIN [Card Auth] required. Please enter User PIN [Card Auth]: Failed to store private key: File too small -8-- IIUC -i can only be 45 (normal) or 46 (non repudiation)... But to be sure I tried w/ different IDs, too, but got the same result. And as you can see, I get asked CHV1 even if I chose -a 2 ... Really strange thing is that it seems both private keys get stored on card and protected by the correct PIN: -8-- $ pkcs15-tool --dump Using reader with a card: Gemalto GemPC Twin 00 00 PKCS#15 Card [MyEID]: Version: 0 Serial number : 7340050446913028 Manufacturer ID: Aventra Ltd. Last update: 20110213120742Z Flags : EID compliant 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 : Private RSA Key [StartSSL auth] Object Flags : [0x3], private, modifiable Usage : [0x2E], decrypt, sign, signRecover, unwrap Access Flags : [0x0] ModLength : 2048 Key ref: 1 Native : yes Path : 3f0050154b01 Auth ID: 02 ID : 45 Private RSA Key [ndk@] Object Flags : [0x3], private, modifiable Usage : [0x2E], decrypt, sign, signRecover, unwrap Access Flags : [0x0] ModLength : 2048 Key ref: 2 Native : yes Path : 3f0050154b02 Auth ID: 02 ID : 45 X.509 Certificate [/description=319470-SNVg5Hb3589q8dqm/O=Persona Not Validated/CN=StartCom Free Certificate Member/emailAddress=***] Object Flags : [0x2], modifiable Authority : no Path : 3f0050154301 ID : 45 Encoded serial : 02 03 01F7C8 X.509 Certificate [/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority] Object Flags : [0x2], modifiable Authority : yes Path : 3f0050154302 ID : 509b7413aa02db7808cf0c378e61a7ecc4f29745 Encoded serial : 02 01 01 X.509 Certificate [/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom
Re: [opensc-devel] Multiple certs on a MyEID card?
On 13/02/2011 14:38, Andreas Jellinghaus wrote: yes, smart cards are quite old technology, files can't grow on demand :( I knew that. sorry, I know ono way to calculate such file sizes. all you can do is try and error. Yup. Hard to predict correct size, since certs can be of different size. the debug log file should show you what file is toosmall, so you can find out what file needs to be initialized bigger. Using 3 times '-v' made me find that file 4404 is the one too small. Not knowing exact meaning of options in /usr/share/opensc/myeid.profile, section 'option default / macros', I tried setting cdf-size = 4096, and now I could reinit the card and store my 4 certs on it! What's the downside of setting it to bigger size? Maybe even 8192 or so? Can I override default profiles on a per-user basis in a simple way? I already tried copying myeid.profile and using -p, but I had to use ../../../../path/to/current/dir/myeid (.. to go to root, then full path of my modified profile, w/o .profile extension). 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 13/02/2011 21:18, Martin Paljak wrote: $ pkcs15-init -S startssl.p12 -f PKCS12 -i 45 -a 2 -l StartSSL auth Using reader with a card: Gemalto GemPC Twin 00 00 error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure Is this error normal? Does it happen with OpenSSL command line tools or other software? I always get it for PKCS12 certs where the private key is protected by a password. IIUC -i can only be 45 (normal) or 46 (non repudiation)... But to be sure I tried w/ different IDs, too, but got the same result. The ID has no real meaning AFAIK, I don't know from where the 45 and 46 come from. What is your source? I read it somewhere while researching, noted it in my mind and forgot source :( Private RSA Key [StartSSL auth] ID : 45 Private RSA Key [ndk@] ID : 45 The software should not allow you to create two private keys with the same ID. How exactly did you end up with this card, do you have the commands, starting from initialization? Yup. I init it from a script: pkcs15-init -E 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 -F pkcs15-init -S startssl.p12 -f PKCS12 -i 45 -a 2 -l StartSSL auth pkcs15-init -S ndk2.p12 -f PKCS12 -i 45 -a 2 -l ndk 2 Probably it's not checked. Seems I'm approaching a solution for the original capacity troubles, but more troubles emerge. I modified /usr/share/opensc/myeid.profile so that it now contains these lines: # Comments based on http://www.usenix.org/events/smartcard99/full_papers/nystrom/nystrom.pdf unusedspace-size = 512; odf-size= 256; # Object Directory File: pointers to other files aodf-size = 384; # Authentication Object Directory File: points to PINs file cdf-size= 4096; # Certificate Directory File prkdf-size = 4950; # Private Keys Directory file pukdf-size = 4000; # Public keys Directory file dodf-size = 256; # Data Object Directory file With these values I could iterate 58(!!!) times pkcs15-init -G rsa/1024 ... before EF 4404 (??? why? I'm not storing certs yet!) fills up. But now pkcs15 -D shows me only private and public keys up to the 32nd (limit in the tool?). If I delete a public key, then I can see the 33rd and so on (one more key for every one I delete). *Can't* delete private keys (always says it can't find that key ID): -8-- $ pkcs15-tool -k Using reader with a card: Gemalto GemPC Twin 00 00 [...] Private RSA Key [Id_32] Object Flags : [0x3], private, modifiable Usage : [0x4], sign Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 1024 Key ref: 32 Native : yes Path : 3f0050154b20 ID : 6b1414bf460fe3a6711fee7e61c286331f490d1a $ pkcs15-init -D privkey --id 6b1414bf460fe3a6711fee7e61c286331f490d1a Using reader with a card: Gemalto GemPC Twin 00 00 NOTE: couldn't find privkey 6b1414bf460fe3a6711fee7e61c286331f490d1a to delete Deleted 0 objects -8-- Maybe this is a bug? BYtE! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Multiple certs on a MyEID card?
Hi all. I'm using a MyEID card (got a pack of 5 to test) on a GemPlus USB-SW reader. OpenSC is 0.12, from Mandriva Cooker (2011alpha) packages. If I init the card and load a single certificate (actually the one I use to authenticate on StartSSL.com) it's OK. I can even generate a 2048 bit key pair for SSH, and it works OK (but I have to specify -u decrypt,sign to meke it work). Problems start when I tryto load another cert (I have 3 more, for different mail addresses; all certs are from StartSSL): it says Failed to store private key: File too small I thought there was not enough space in some file and tried to modify files sizes in profile (failing everytime... maybe 'cause I don't know the meaning of those parameters). Then I tried generating some more keys: no problem w/ 4x2048bit+2x1024bit... So I think there's enough space... Then I tried converting certs to PEM format and load'em w/ pkcs15-init -a 2 -S $CERTNAME.pem --cert-label $CERTNAME pkcs15-init -X $CERTNAME.pem -l $CERTNAME (tried in reverse order too, and w/ --cert-label when using -X) and all certs gets loaded. But seems private keys aren't associated to the cert. And Firefox and Thunderbird can't see 'em... Another strangeness is that when adding keypairs or certificates I'm asked to enter CHV1, not SOPIN or the PIN I'm asking to use. For example pkcs15-init -G rsa/2048 -a 2 -u decrypt,sign -l SSH asks for CHV1, *not* CHV2 os SOPIN! Another doubt: what are slots? Seems for pkcs11-tool -L they're the PINs, but for text in opensc.conf it seems they're related to the max number of storable keys... Tks! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
