Re: [opensc-devel] Domain Parameter for ECC Keys
Hi Douglas, see below. Andreas Am 20.09.2012 17:12, schrieb Douglas E. Engert: On 9/19/2012 6:11 PM, Andreas Schwier (ML) wrote: Dear all, we've come across a strange behaviour of the pkcs15-lib in OpenSC when we generate an EC key pair: After generating an fresh EC key pair, our code returns a sc_pkcs15_pubkey containing the EC public key and DER encoded domain parameter. The public key is then encoded in sc_pkcs15init_generate_key and added to the DF in the framework when it's immediately decoded again. During this encode / decode step the domain parameter are lost. Looked at PKCS#15 v1.1 section 6.4.3 The value is a EC_PubKeyChoice, that can be a raw ECPoint or a spki SubjectPublicKeyInfo. It looks like the sc_pkcs15_encode_pubkey_ec is just returning the ECPoint. sc_pkcs15_decode_pubkey_ec is also assuming the ECPoint. It looks like that code has never been fully tested, and the above code should be modified to use the spki SubjectPublicKeyInfo if there are domain parameters. With the EC work I have done in OpenSC including writing the above two routines, I have not looked at the pkcs15init code at all, as the PIV card is not a PKCS#15 card but rather the PKCS#15 is emulated, and the emulation layer is base on the decoded entries. The PIV does not use the pkcs15init code at all, but rather a special pivtool can be used for test cards to generate a key. It also turns out that the PIV card does not store a pubkey object at all, but derives the pubkey from the certificate. I'm wondering why this encode / decode step is done ? No one has a PKCS#15 cards that support EC to test this part of the code. We do have a card that supports EC ;-) If it is required for some reason, then I would rather encode the public key in SubjectPublicKey structure that would also preserve the domain parameter in AlgorithmIdentifier. Can you come up with a patch? Yes, we can certainly do that. I just wanted to make sure that I understand the rational behind the current implementation. Andreas -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ 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] new release?
On Wed, Sep 19, 2012 at 11:54 PM, Douglas E. Engert deeng...@anl.govwrote: I have been testing 0.13.0-pre1 from tarball listed below. Builds on Solaris. works with MIT Kerberos PKINIT and pam_krb5 to login to AD as the KDC. Can sign Email using thunderbird 13.0.1. The pkcs11-tool -derive using ECDH works using a PIV test card from NIST and a card I created. (i.e. using the key frome a card and the cert from the other card, will produce the same secret key.) Ok, thanks for the testing. In 0.13.0-pre1 there is the bug that concerns the using of non-initialized OID data. My non-regression tests were done with the current (*d525ca97e3*) 'master' version: For the OpenSC installed on Linux from tarball the following tests of the where done using the pkcs15 and pkcs11 tools, with the cards 'CardOS v4.3B', 'SetCOS 4.4.1 B', 'Athena', 'Aventra' and 'Feitian': - erase card (pkcs15-init -E); - initialize (ex. pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin 99 --puk 88); - generate RSA 1024/2048 (depending on card); - import PKCS#12 with user and CA certificates; - get public key from imported or generated key; - sign data using pkcs15-crypt and pkcs11-tool and verify it with openssl; - decrypt the data encypted by openssl; Using Firefox 12.0 and Thunderbird 15.0.1, on Vista, with IAS/ECC card and OpenSC installed from MSI: - generate key and sign certificate request; - import certificate; - authenticate to access protected web page. - import PKCS#12; - sign mail; - decrypt mail. As for me, still to test are minidriver (IE and outlook), smartcard logon (windows) and SM (for the cards that support it). Do you have other suggestions for the non-regression tests? Kind regards, Viktor. On 9/17/2012 3:00 PM, Viktor Tarasov wrote: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ 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
2012/9/23 Anders Rundgren anders.rundg...@telia.com On 2012-09-23 12:04, Andreas Jellinghaus wrote: 2012/9/22 Anders Rundgren anders.rundg...@telia.com mailto: anders.rundg...@telia.com On 2012-09-22 17:27, NdK wrote: 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... 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). 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. 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. To get the proportions right, consumer security solutions should IMO be compared with the Gold Standard for Internet-payments where authorization is performed by a UserID (Card Number) and Password (CCV) printed in clear on plastic cards, which is all the Financial Industry have manged to roll out during the 15Y+ we have had with the Internet! actually I think the system was doing fine - if you can review transactions later and refute any bogus transaction and the money can be traced to the recipient, and the system provider has a huge interest to keep the money traceable and recall'able, that is a good system design, and protects everyone much better than technical adventures. I guess you refer to the Google Wallet or SKS as technical adventures? I don't see any conflicts between judicious logging and systems that [rightly or wrongly] are claimed to be more secure than passwords printed in clear on plastic cards. no, I was refering to all the magic solutions that make things secure suddenly. 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. switching from magstripe to EMV transactions (chip+pin) seams to be a good idea though, as magstripe is totaly unsecure. but the real foundation of the credit card business is the middle man that vouches against both user and shop for any loss, and runs a fraud prevention programm to minimize risk and cost. this idea is great, technical solutions are perfectly fine, if they keep this basic system. I complain that they try to do not. 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. I wonder how many years we need until people are willing to build an online only system. that won't work offline, but could be soo much easier than the offline system. many banks have already moved e.g. their PINs from the card to the online system, as unblocking a PIN in a card was often not working well, and having a central manged IT is much easier. So banks are already willing to restrict at least certain functions like debit (cash from ATM) to online only. The downside from my perspective is rather that visa and master card are shifting the liability to the end user. if the only one in the system who can enforce security standards is no longer liable to carry the burdon of not having a good enough security, then the system is going bad. verified by VISA and the similar master card initiative require the end user to verify each transaction with an additional password. If it is a password, it can be sniffed by a trojan as easily. if it is a TAN send over a SMS to your mobile phone, then loosing you mobile phone means an empty bank account. 3D Secure IMO combines the worst possible user-interface with questionable security. However, the concept is actually brilliant but it will rather be Google and Apple that will make it useful, not MasterCard and VISA. well, no nfc in iphone5, thus no idea what plans Apple has, and I can't comment on
Re: [opensc-devel] new release?
On 9/24/2012 12:52 PM, Viktor Tarasov wrote: On Wed, Sep 19, 2012 at 11:54 PM, Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov wrote: I have been testing 0.13.0-pre1 from tarball listed below. Builds on Solaris. works with MIT Kerberos PKINIT and pam_krb5 to login to AD as the KDC. Can sign Email using thunderbird 13.0.1. The pkcs11-tool -derive using ECDH works using a PIV test card from NIST and a card I created. (i.e. using the key frome a card and the cert from the other card, will produce the same secret key.) Ok, thanks for the testing. In 0.13.0-pre1 there is the bug that concerns the using of non-initialized OID data. My non-regression tests were done with the current (*d525ca97e3*) 'master' version: For the OpenSC installed on Linux from tarball the following tests of the where done using the pkcs15 and pkcs11 tools, with the cards 'CardOS v4.3B', 'SetCOS 4.4.1 B', 'Athena', 'Aventra' and 'Feitian': - erase card (pkcs15-init -E); - initialize (ex. pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin 99 --puk 88); - generate RSA 1024/2048 (depending on card); - import PKCS#12 with user and CA certificates; - get public key from imported or generated key; - sign data using pkcs15-crypt and pkcs11-tool and verify it with openssl; - decrypt the data encypted by openssl; Using Firefox 12.0 and Thunderbird 15.0.1, on Vista, with IAS/ECC card and OpenSC installed from MSI: - generate key and sign certificate request; - import certificate; - authenticate to access protected web page. - import PKCS#12; - sign mail; - decrypt mail. As for me, still to test are minidriver (IE and outlook), smartcard logon (windows) and SM (for the cards that support it). Do you have other suggestions for the non-regression tests? If you have a Windows build, I could test PKCS#11 on Windows 7 with Firefox and Thinderbird. Kind regards, Viktor. On 9/17/2012 3:00 PM, Viktor Tarasov wrote: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org http://opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be connected. It would be nice if you could look/test the tarball or packages of the release 0.13.0pre1. Your remarks, proposals, contributions are heartily welcome. Kind regards, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto:opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 tel:%28630%29%20252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org mailto:opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National
Re: [opensc-devel] Technical Description - Android Embedded SE
2012/9/24 NdK ndk.cla...@gmail.com 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 :) well, that is lots of software in the smart phone that can be hacked. not a secure entry device from my point of view. 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, not so sure about that. but even if that is true, the software is easier to hack anyway, and requires only installing the wrong app try this game, thus has a much easier attack vector. 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... well, in the end your programm is pretty simple I guess, and the complex operations like crypto are in a library in the chip and not java bytecode. 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. well, we saw so many insecurities in smart cards in the last few years - e.g. the hacks on mifare and legic, or the flaws found by ross anderson and his team on EMV cards - I doubt things are really secure, if they are very complex. 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... well. who is the card manager. if I buy a phone without contract, is it the vendor? if I buy a phone with a contract, is it the mobile network operator? will we have conflicts of interest? we already have locked phones and preventing some functionality (voice over ip, tethering, ...), and I guess phone companies want you to pay with your phone - as long as it ends up on the phone bill and they get a share of each transaction? thus who controls the SE has power, and it can't be you the end user, as the bank won't trust you to do a secure deployment. 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. no one needs to recover keys. simply create a new one and create a new cert. 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. HSM have all keys stored on the normal windows disk - but encrypted. the encryption is with AES or 3DES, and that is a master key that can be loaded into several HSM. often it is an XOR of N master key parts, and 4*N different persons have a copy of one part (two sites, two person each site). Thus worst case any copy of the key database plus parts 1..N can be used to setup a fresh HSM with the same master key and keep using those keys. standard practice for IBM HSMs at least I believe. 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. :) no. if you run a CA creating new certificates costs you nothing, so the best thing you can do for security is short lived certificates with fast automated secure refresh cycles. the reason why people have long lived certificates, is because it is such a hassle to create new ones and manage
Re: [opensc-devel] new release?
Duh, I see you have 32 and 64 bit msi files. Since I was using 32 bit firefox and Thunderbird, I installed the 32 bit version on W7 64. It install the clients in \Program Files (x86)\... but not the Windows\system32\opensc-pkcs11.dll If I then install the 64 bit msi, it installs the \Program Files\OpenSC\... and installs Windows\system32\opensc-pkcs11.dll. Is the intent that the 64 bit msi install 64 bit tools, and opensc.dll and the 32 bit opensc-pkcs11.dll? Is there a 64 bit opensc-pkcs11.dll? Firefox 8.0.1 works to a web site. Thunderbird 13.0.1 complains about the signing certificate usage, but appears to read the certificates, and TB says the certificate chain is valid and all the CA certs are listed as trusted for signing e-mail. This sounds like a Thunderbird bug. Will have to look some more. but it looks like OpenSC is working. I was able to sign using TB 13.0.1 on Solaris using a test account. On 9/24/2012 2:43 PM, Douglas E. Engert wrote: On 9/24/2012 12:52 PM, Viktor Tarasov wrote: On Wed, Sep 19, 2012 at 11:54 PM, Douglas E. Engert deeng...@anl.gov mailto:deeng...@anl.gov wrote: I have been testing 0.13.0-pre1 from tarball listed below. Builds on Solaris. works with MIT Kerberos PKINIT and pam_krb5 to login to AD as the KDC. Can sign Email using thunderbird 13.0.1. The pkcs11-tool -derive using ECDH works using a PIV test card from NIST and a card I created. (i.e. using the key frome a card and the cert from the other card, will produce the same secret key.) Ok, thanks for the testing. In 0.13.0-pre1 there is the bug that concerns the using of non-initialized OID data. My non-regression tests were done with the current (*d525ca97e3*) 'master' version: For the OpenSC installed on Linux from tarball the following tests of the where done using the pkcs15 and pkcs11 tools, with the cards 'CardOS v4.3B', 'SetCOS 4.4.1 B', 'Athena', 'Aventra' and 'Feitian': - erase card (pkcs15-init -E); - initialize (ex. pkcs15-init -C --label IDX-SCM -P --auth-id 53434D --so-pin 12345678 --so-puk 123456 --pin 99 --puk 88); - generate RSA 1024/2048 (depending on card); - import PKCS#12 with user and CA certificates; - get public key from imported or generated key; - sign data using pkcs15-crypt and pkcs11-tool and verify it with openssl; - decrypt the data encypted by openssl; Using Firefox 12.0 and Thunderbird 15.0.1, on Vista, with IAS/ECC card and OpenSC installed from MSI: - generate key and sign certificate request; - import certificate; - authenticate to access protected web page. - import PKCS#12; - sign mail; - decrypt mail. As for me, still to test are minidriver (IE and outlook), smartcard logon (windows) and SM (for the cards that support it). Do you have other suggestions for the non-regression tests? If you have a Windows build, I could test PKCS#11 on Windows 7 with Firefox and Thinderbird. Kind regards, Viktor. On 9/17/2012 3:00 PM, Viktor Tarasov wrote: Hello, Le 15/09/2012 16:52, Kalev Lember a écrit : On 09/06/2012 08:06 PM, Viktor Tarasov wrote: Hello, current github 'staging' is tagged as v0.13.0-pre1. If no objections, I will merge this branch into github 'master' -- it will be base version to test and to prepare the coming release candidate. Very good idea. I think it makes a lot of sense to have just one 'master' branch for development; this is what people coming over from other projects tend to expect. 'Master' and 'staging' are actually synchronized and for the new pull requests I propose to create them relative to the 'master' branch. Until the end of this release the pull requests to 'staging' are also accepted. The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still cannot understand which common set of characters could be used for the release-version/tag-name to satisfy 'git', 'obs', 'dpkg-build', ... Commits to 'master' and new tags trigger the jenkins jobs of build, packaging and some rudimentary test of package and unit tests (for Suse). https://opensc.fr/jenkins/view/Open https://opensc.fr/jenkins/view/OpenSC-release/SC-release/ https://opensc.fr/jenkins/view/OpenSC-release/ The resulting packages are transfered to 'download' part of the opensc-project.org http://opensc-project.org file server: - commits to http://www.opensc-project.org/downloads/projects/opensc/nightly/ - releases to http://www.opensc-project.org/downloads/projects/opensc/releases/ For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 for opensSuSE 12.1 . Hope that rapidly the building of releases packages for some debian/ubuntu distributions will be
Re: [opensc-devel] new release?
Thunderbird 13.0.1 complains about the signing certificate usage, ePass2003 users also reported an issue about signing certificates: www.gooze.eu/forums/support/epass2003-as-ca-with-openssl Kind regards, -- Jean-Michel Pouré - Gooze - http://www.gooze.eu smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 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
2012/9/25 NdK ndk.cla...@gmail.com 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? No, I think it is well intended - try to be compatible with every old thing and have all the features everyone wants in there. Except the result of such a process is not good. 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. Most vending machines still use modems and dial up for every transaction and hang up again later. Thats why card transactions are so slow. Once the standard is to have a permanent internet connection, the cost of doing an online transaction is lower (less delay) and the profile could be changed to do everything online. But since the card doesn't know where it is, it can only have a world wide setting, and people expect the card to work in the remote places with the worst infrastructure. Maybe some day banks want to give people two credit cards with different settings? Andreas BYtE, Diego. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
