Re: [opensc-devel] How to compile opensc in windows?
On Wed, Dec 12, 2012 at 4:53 PM, Rns Course rns_cou...@yahoo.com wrote: Hello I need to compile opensc-0.11.3. On this page: http://www.opensc-project.org/opensc/wiki/WindowsInstaller The command x86: SetEnv.cmd /x86 /Release and nmake /f win32\Makefile.msc LOC=-DASMV -DASMINF OBJA=inffas32.obj match686.obj zlib.lib is written, while there's not Makefile.msc file in the package. There is a Makefile.mak in it. Just tested: 1.2.7 *does* include Makefile.msc Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Food for thought on C coding style
Hello, https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SmartCard-HSM Tool with key wrap / unwrap
Hello Andreas, Is the applet available for download or cards with pre-loaded applet on sale somewhere? Martin On Fri, Nov 9, 2012 at 7:33 PM, Andreas Schwier andreas.schw...@cardcontact.de wrote: Good evening, we've created a pull request towards OpenSC/staging for adding the SmartCard-HSM tool (sc-hsm-tool). Using version 0.17 or higher, the SmartCard-HSM provides for a key wrap / unwrap mechanism that allows to securely export and import card generated keys. Key values are encrypted under a 256-bit AES Device Key Encryption Key (DKEK) and saved to file with key description and optional certificate. From such a file, the key can be recreated in a SmartCard-HSM that has been set-up with the same DKEK. Using this mechanism, one can securely backup keys or migrate keys between different SmartCard-HSMs. This increases the capacity of the device, as infrequently used keys can be exported and archived externally. It also provides for redundancy and load balancing if keys are replicated in a cluster of SmartCard-HSMs. The DKEK can be recreated from a defined number of key shares. Such key shares are created with sc-hsm-tool and saved to file using password based encryption. Kind regards, 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Need help building Mac OS X packages
On Sun, Oct 14, 2012 at 3:27 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: I would suggest to drop the OpenSC tokend, unless someone volunteer to maintain it. I think my current mbp running 10.7 will be the last piece of Applet hardware/software combo I'll run, so the future is uncertain, but current situation is solid. I have not rebuild this tokend since a long time so it may be as easy (or hard) to rebuild as the tokend from OpenSC. The final version of OSX that supports *building* Tokend is 10.7. 10.8 also removes OpenSSL and that brings a stack of other problems for the future. But as of now, Tokend works as expected (but needs to be in sync with libopensc, of course). Will look into it. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... Interenet as an ideal is one thing, business as usual must still live on, unfortunately. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Hello On Wed, Nov 14, 2012 at 7:37 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: But Martin is now missing. :) I've not fallen off the edge of the earth, but I've been only digesting e-mails that have been addressed to me directly and thus ended up in main inbox (which not many have, at least according to gmail filtering) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Hello, On Wed, Nov 21, 2012 at 6:59 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Maybe some people are on the list but no more interested by OpenSC. Maybe they just redirect the emails into the spam/trash folder. There's a fairly constant flow of people to and off the list according to subscription notices, so I believe the folder people either track it passively or actually do know when then unsubscribe or re-subscribe. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
On Sat, Nov 17, 2012 at 11:57 PM, Peter Stuge pe...@stuge.se wrote: Ludovic Rousseau wrote: The idea of git is to _not_ have to give access. Just send pull requests and I (or another admin) will pull your code. No, the purpose of git must not be limiting access :) Yes and no. Multiple people writing to a central repo works perfectly fine also with git. Yes. The Original Goal(tm) was that instead of bureaucratic rubber-stamping commits and dividing the whoever extra pair of eyes and brains and access would actually look, read, digest *and if necessary, reject* a pull request and mentor it with reasonable comments. Be it coherent design, sloppy naming and whitespace, comments in chinese or something else. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
On Wed, Nov 21, 2012 at 7:25 PM, Martin Paljak mar...@martinpaljak.net wrote: Yes and no. Multiple people writing to a central repo works perfectly fine also with git. Yes. The Original Goal(tm) was that instead of bureaucratic rubber-stamping commits and dividing the whoever extra pair of eyes and brains and access would actually look, read, digest *and if necessary, reject* a pull request and mentor it with reasonable comments. Be it coherent design, sloppy naming and whitespace, comments in chinese or something else. And the fact that feedback before merging is better than when somebody goes on to janitoring some code (OK for generic cleanup but usually causes psychological stress if it includes something more) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] state of the project?
Bonjour, On Wed, Nov 14, 2012 at 7:37 PM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Andreas, the host available at opensc-project.org will disapear at the end of the year 2012 [2]. There will be a semi-managed (meaning managed backup and other monitoring) Debian box available for the foreseeable future. I'll shift the current authorized_keys file over and send a private e-mail with details to the ones in the ssh list. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New SE (Security Element) Company Formed
On Wed, Nov 21, 2012 at 8:55 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: 2012/11/21 Martin Paljak mar...@martinpaljak.net: On Thu, Nov 15, 2012 at 7:12 PM, Anders Rundgren anders.rundg...@telia.com wrote: Another hurdle is that the GP security model is incompatible with the Internet: GP presumes mutual authentication AFAIK. This is how the Google Wallet currently works (Google holds the master keys to the SE) but that's not really cutting it. I don't believe that the industry players would want to give up their current position easily. Appstores (authority over what can be installed without hurdles), keys to the empire (GP-style approach) or monetary gatekeepers (who can charge a certain % for what is happening in their gardens) make money. Telcos would prefer to kill data based instant messaging providers without hesitation, if they could - SMS makes golden eggs... are you sure that is still the case? SMS flat is down to 5€/month over here. and I use google talk all the time instead of SMS, unless it is someone who doesn't have an android phone. Even public sources estimate a nice business And text messaging is still a big business, accounting for an estimated $21 billion in U.S. revenue for telecom companies last year and an estimated $23 billion this year, according to the Consumer Federation of America. Source: http://articles.latimes.com/2011/aug/21/business/la-fi-texting-20110822 The ROI on SMS is not comparable to the investments and increasing traffic for data services (where messaging is accounts only for a 1% of traffic, I believe) Interenet as an ideal is one thing, business as usual must still live on, unfortunately. thats a bit harsh I think - its not like the mobile carriers e.g. aren't trying to sell payment systems on top of their infrastructure or similar, but at the end it doesn't gain wide acceptance it seems. maybe too expensive? Sure, as long as they can get a % of the business happening in their walled garden. Then again, financial services and payments are important parts of the overall who controls the money routes, controls the business play, so I don't expect any of the carriers or handset platform providers to open up a loophole that would allow for some 3rd party to easily take their market, without paying. There's just no commercial interest. So yes, harsh, but I believe realistic. I cannot comment on many things discussed here, but as someone living in an SSO world, where I have one place to authenticate, and every app I use gets the authentication from that central place via OAuth: that is real nice. Thus my personal goal would be no longer to be able to get many credentials from many places, but only to handle one credentials with one service on the other side, and handle that very, very well. every other place can use OAuth with that central place. (remember how I opposed using openid in the past? seeing how nice it is to have such infrastructure changed my view on that) Sure. But that should be an *option* rather than requirement. Eventually you still would want to separate your bank account from your google account, for example. Maybe in 10 years this sounds like a stupid idea for the younger generation, but this moment in time I still would prefer the option to choose my credentials and identities (but would love to re-use them as *I* want, not how some vendor wants it (what makes OpenID better than peered implementations like saml or facebook connect or..) Sorry to hear about the OpenID thing though ;) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Muscle] pcscd / firefox / ubuntu on android
On Thu, Oct 18, 2012 at 9:48 PM, Douglas E. Engert deeng...@anl.gov wrote: So until FF and TB get the fixes, OpenSC-0.13.0 adds a new option to the opensc.conf file to cache the pin to accommodate older applications. pin_cache_ignore_user_consent = true; Just a suggestion-question: OpenSC behavior in not caching the user consent PIN is logically correct, so why not disregard the user consent bit instead on the PKCS#15 object level? IMHO it feels a bit weird, that there is the PIN caching (to be turned on or off, on by default), then this mechanism that first disables PIN caching (user consent), then there is a mechanism that enables it again. This would of course unfortunately mean crippling the semantics of the module (reporting a normal key when in fact it has CKA_ALWAYS_AUTHENTICATE implemented in the hardware). The real problem is the difficulty in exposing the different PKCS#11 hacks and tweaks to different applications in an easily managed way, with concurrent applications... Just a thought. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new server hoster and adminstrator for opensc-project.org required
Hello, On Wed, Sep 12, 2012 at 11:03 PM, Andreas Jellinghaus andr...@ionisiert.de wrote: Hi, opensc-project.org needs a new home: someone with a (real or virtual) server and the interest in setting it up from scratch and keeping it running and maintaining that server, installation and service for the project. someone who is able to win the trust of the community as new server administrator. The current installation is terribly old. It is based on ubuntu hardy and I think that is nearing the end of its supported livetime or even is unsupported now, thus it is urgently required to rebuild the server. Over the years we had several approaches and various people offered to take over running the server, but so far none of those worked out in the end, noone followed up after the initial discussion. To give this new efford more motivation here is some presure: running a server without maintenance and security updates is not a good idea. Thus I will shut down the current installation at the last end of this year. Any motivated linux administrator can setup a simple server with apache and a few copies of trac, plus postfix and a few mailing lists in a few hours or a day, with maybe a bit more time for fine tuning and migration of the content. This shouldn't be a big deal, thus there should be enough time to find someone interested in doing so and migrating opensc and related projects of the outdated installation. I've had a barebones machine sitting in idle (except for being a ssh gateway for irc...) for almost a year, but for (past) reasons not worth mentioning, I've failed to focus sufficiently on non-real-life matters like OpenSC for a while. This might be a good chance to a) scope the services required for opensc-project.org and b) implement it on a clean machine with some systematic sysadmin approach. But for sustainable results, the scope should be seriously minimal and limited... Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
On Wed, Sep 5, 2012 at 12:57 PM, helpcrypto helpcrypto helpcry...@gmail.com wrote: Also, considering how governments are involved in technology, probably many countries will adopt them, like eID, DNIe, and so in the next years. In 1024bit mode, of course. Huh, I'd guess (hope) nobody would be deploying *RSA* below 2048 bits (smart cards doing 3k and 4k are also slowly emerging) and elliptic curves are already becoming a viable option (in commodity software) as well.. There's also a bunch of applications and use cases where the new age vision of wave your phone around is not a good idea (for example I'd better avoid taking my smartphone out unless I want/have to, and using crowded public transport is not one of the places I'd like to do it...) And IMHO device-attached containers (TPM, Intel etc) are totally different from transportable key-containers (like smart cards or USB tokens) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
On Wed, Sep 5, 2012 at 2:29 PM, helpcrypto helpcrypto helpcry...@gmail.com wrote: And IMHO device-attached containers (TPM, Intel etc) are totally different from transportable key-containers (like smart cards or USB tokens) So, IYHO, whats the better option? Do you want my Humble or Honest opinion ? :) It shall depend on the use case. I doubt that there will ever be a single, universal keychain, but many. VPN authentication with device based (TMP etc) keys which get auto-provisioned and a movable identity in the form of an eID smart card for digital signatures or cross-domain authentication have different requirements. Key containers for encryption is yet another story. And embedded keystores (phones, vpn devices, whatnot) that need a provisioning scheme is also quite obvious, with the smartphone scene creating the firsthand need for it. Martin As always, there's no golden bullet solution. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Supporting card Handelsbanken (SHB) BankID
Hello, On Tue, Aug 21, 2012 at 2:03 PM, Peter Åstrand astr...@cendio.se wrote: Hi! It would be nice if OpenSC could support cards from the Swedish bank Handelsbanken (SHB). This is a BankID type of cards. I've tried multiple versions of OpenSC and they all fail to communicate with the card, with one exception: We are using OpenSC 0.12.1 in our ThinLinc Client, loading the opensc-pkcs15 module. If you start the client first, then inserts the cards, the certificates are listed! However, this does require that the proprietary BankID application is installed on the machine (install.bankid.com). If you insert the card first, then start the ThinLinc Client, no certs are found. It seems to me that the BankID application somehow unlocks the card when it reads it, and during this window of time, our client with OpenSC can read the card as well. I've done a few logs with OPENSC_DEBUG=9. In the case when the certs are found, we get: card.c:322:sc_unlock: called iso7816.c:103:iso7816_check_sw: File not found iso7816.c:471:iso7816_select_file: returning with: -1201 (File not found) When no certs are found, we get: card.c:322:sc_unlock: called iso7816.c:103:iso7816_check_sw: Instruction code not supported or invalid iso7816.c:471:iso7816_select_file: returning with: -1204 (Unsupported INS byte in APDU) Any chance of having proper support for this card in OpenSC in the future? The error is not really useful by itself, please follow the ReportingBugs [1] page from the wiki to send useful logs (which driver, which card, which reader etc) What I suspect is that the application is not the default one on the card and the bankid software selects the right applet, after what OpenSC gets further than without the bank application installed. This is just a wild guess though... Martin [1] https://www.opensc-project.org/opensc/wiki/ReportingBugs ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SafeNet/Aladdin new eToken PRO (Java) - driver
Hello On Tue, Sep 4, 2012 at 3:19 PM, Martin Čmelík martin.cme...@gmail.com wrote: Hi Peter, oh, really? I was playing with that 5 hours. Seems that I maybe somehow ruined official SafeNet libraries (but auth client works fine...). One more note: I'm using it on Mac OS Can you send me please your openssl and opensc settings? Something like described here in Testing with OpenSSL - http://www.opensc-project.org/opensc/wiki/QuickStart I read everywhere that Java cards are unusable with OpenSC. Did you initialize eToken with SafeNet Auth Client or pkcs15-init? OpenSC does NOT support the Aladdin PKI applet. What you *can* do is sniff the APDU-s used with the Aladdin middleware with pcsc-spy for example and reverse-engineer a driver. I'd *hope* it would be something close to standards (whichever standards) thus you could re-use existing code and existing documentation. What are the chances of this being the case I don't have a clue. You could as well as SafeNet for card reference manual... Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Windows minidriver and Secure PIN Entry
On Thu, Sep 6, 2012 at 12:32 AM, Taylor, Tim ttay...@mitre.org wrote: Is the opensc minidriver not able to detect and use the pinpad? At the moment, no. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Credential Cloning. Was: Intel's Virtual Smart Card
On Sun, Aug 19, 2012 at 8:15 PM, Anders Rundgren anders.rundg...@telia.com wrote: Who would buy a $100 solution if they can get one for free? I don't think even the SIM will survive. IIRC it was apple who wants to make a phone self-register. Meaning there are no parts to add or remove from the phone and you pair it to your operator online. The question IMHO is how much do telcos want to give up the freedom of controlling access to their networks... But in the long run you are probably right. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] T-Buffer Question
Hello, On Thu, Jun 7, 2012 at 3:46 PM, Jon jonmark...@gmail.com wrote: The T-buffer is the Tag Buffer. I think the card conforms to Government Smart Card Interoperability Specification. (GSC-IS) as defined in NIST 6887. In particular the card is a military Alt-Token. Without knowing much about the US related standards, shouldn't PIV be the current game ? Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] questions on {ERASE, WRITE, UPDATE} BINARY commands
Hello, On Thu, Jun 7, 2012 at 10:24 PM, Peter Marschall pe...@adpm.de wrote: Here they are: * What's the exact difference between WRITE BINARY UPDATE BINARY? My understanding of the spec is that WRITE BINARY can extend a file's size, while UPDATE BINARY can only update data elements that are already within the file (i.e. in the range [0 .. file_size-1]). Is my understanding correct or did I misunderstand the specscompletely? AFAIU either can change file size (which can be done though 7816-9). UPDATE will *set* the bits as given in the command, whereas WRITE can allow some bit-fiddling. Why the question? If there would be a card that implements both, I think you would want to use UPDATE, at least in the context of OpenSC, unless it is *not* supported and WRITE is supported. What exactly is the context? * Is it to be considered an error if UPDATE BINARY a) uses an idx = existing_file_size ? Probably. '6B00' (offset outside the EF) b) wants to update 0 data elements (i.e. count = 0) ? IMHO should not, but implementations might vary, of course. c) idx + count = existing_file_size? Probably. '6B00' (offset outside the EF) * Similar for ERASE BINARY a) Can it set data elements to logical erased state beyond the file size? i.e. idx + count = existing_file_size b) Is it an error to erase 0 data alements i.e. count = 0 c) If idx + count = file_size, does the file get zapped (=shortened) to idx data elements? Ditto. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] questions on {ERASE, WRITE, UPDATE} BINARY commands
On Thu, Jun 7, 2012 at 10:35 PM, Martin Paljak mar...@martinpaljak.net wrote: Hello, On Thu, Jun 7, 2012 at 10:24 PM, Peter Marschall pe...@adpm.de wrote: Here they are: * What's the exact difference between WRITE BINARY UPDATE BINARY? My understanding of the spec is that WRITE BINARY can extend a file's size, while UPDATE BINARY can only update data elements that are already within the file (i.e. in the range [0 .. file_size-1]). Is my understanding correct or did I misunderstand the specscompletely? AFAIU either can change file size (which can be done though 7816-9). Correction, can NOT change file size. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] questions on {ERASE, WRITE, UPDATE} BINARY commands
On Thu, Jun 7, 2012 at 10:44 PM, Peter Marschall pe...@adpm.de wrote: Why the question? If there would be a card that implements both, I think you would want to use UPDATE, at least in the context of OpenSC, unless it is *not* supported and WRITE is supported. What exactly is the context? The wish to implement them correctly for the OpenPGP card. I don't see references to UPDATE/WRITE/ERASE BINARY in OpenPGP 2.0.1 spec, only PUT DATA? See also this e-mail: http://lists.gnupg.org/pipermail/gnupg-devel/2011-May/026079.html Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] EF(DIR) and sc_pkcs15_bind_internal
Hello, On Fri, Jun 1, 2012 at 9:45 PM, Douglas E. Engert deeng...@anl.gov wrote: An example might be a PIV card application has the ATR may contain the default application on the card. Thus it could be possible that a card has both a default application that is not PKCS#15 and the card could also be a PKCS#15 card. I don't now understand what you want to imply. Should the logic be tuned further? What I'm trying to do is to create a card application that would require minimal or even no changes at all to OpenSC to be recognized as a PKCS#15 card. But adhering to standards, I believe that the first check should be trying to select the PKCS#15 application by AID, if EF(DIR) is not present. As I've not found a reference to 5015 either (except that it has been used by other applications for PKCS#15 DF in the wild), this might also reply to the question of why the file ID-s are as they currently ar. The best description of the issue is of course a patch, which solves the problem as I see it. Will send it on Monday. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] EF(DIR) and sc_pkcs15_bind_internal
Hello, OpenSC currently tries to read EF(DIR) and if this fails, doesn't find the PKCS#15 application on the card. Yet PKCS#15 tells: a) 5.4.1: EF(DIR) is optional b) 5.7.1/5.7.2: PKCS #15 compliant IC cards should support direct application selection as defined in ISO/IEC 7816-4 Section 9 and ISO/IEC 7816-5, Section 6 (the full AID is to be used as parameter for a ‘SELECT FILE’ command). If direct application selection is not supported, or several PKCS #15 applications reside on the card, an EF(DIR) file with contents as specified in Section 5.4.1 must be used. and The AID is used as the filename for DF(PKCS15) in order to facilitate direct selection of the PKCS #15 application on multi-application cards with only one PKCS #15 application present. Thus I believe that the logic should go: 1. see if EF(DIR) is present and use it if present 2. try selection by PKCS#15 DF name 3. try selection by other hard-coded DF names, as listed in dir.c variable apps. 4. try finding EF(ODF) directly in MF (as the code currently does, but I don't know when/if this should be triggered currently at all) Anyone knows if there are amendments in ISO7816-15 or if this could be interpreted differently from PKCS#15 v1.1 as well? Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Docs/Specs on ACLs / security attributes?
Hello, On Mon, May 28, 2012 at 11:10 AM, Peter Marschall pe...@adpm.de wrote: I am trying to extend openpgp-tool to load data to the various writable DOs, and - if possible - I want it to determine automatically the permissions of the (emulated) files using standard interfaces, i.e. security attributes or preferably ACLs. As the file system on openPGP cards only is emulated using opensc, I need to emulate these data structures too. I don't quite get it. IMHO ACLs would matter, if you would have actual files, and the ACL-s would actually be communicated to/from the card by some means. I don't really understand how you would use ACL-s with the gender field, for example. From OpenPGP spec v201: 5 Security Architecture All commands and data of a smart card are under control of the security of the card oper ating system. ISO defines mechanisms, attributes (e.g. in FCP) and environments for security purposes. Because this features are quite complex and may differ from card to card (depending on mask developer), the OpenPGP application does not evaluate security related items of a card. So this chapter is informative for the card developer and defines the access conditions for all commands and data objects of the application in a common way. The described security features are mandatory for the card, but the coding or the way of implementation is up to the card developer, manufacturer or personaliser. Maybe I'm missing something... Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS15init profile to omit a part of path
Hello, On Fri, May 18, 2012 at 12:59 PM, Nguyễn Hồng Quân quanngu...@mbm.vn wrote: Hello all, I need a help to create pkcs15init profile structure so that I can change/rewrite the canonical path. In general, the path to a file AABB in PKCS15 is as: 3F005015AABB, in which 3F00 is the MF, 5015 is the PKCS15-AppDF's file-id. Now, because the virtual file system of my OpenPGP card (which is non-pkcs15) is constructed as: MF (3F00) | +-- File_1 (AABB) | +-- File_2 (AACC) | +--- Directory (DDCC) | +-- File_3 (CCEE) the real path to the file is 3F00AABB. How would I define the profile file to omit the PKCS15-AppDF, i.e. the 5015, in the path? In the long run, I don't think that it helps to emulate a filesystem on top of non-filesystem cards (like OpenPGP or Muscle). Or to try to make it fit into the filesystem-oriented stack of OpenSC. It is nice to be able to poke around with opensc-explorer, but the notion of a file and a path should mean that the file is actually selectable with ISO SELECT command. Which is not true (a plain APDU, outside of the libopensc emulation layer, would fail). In case of OpenPGP, where no files or PKCS#15 data structures are written to the card (the card already has a fixed profile, with fixed data slots), it makes no sense. The main utility of pkcs15-init is creating (and storing) PKCS#15 ASN.1 structures to the card, when such slots for keys or certificates are created as a side-product. If ASN. shall not be created, pcks15-init should IMHO not be used. The fact that pkcs15-init is the main interface for generating keys/storing certificates, is thus somewhat misleading. You can't create more keys than 3 on OpenPGP, nor can you write more certificates. You can't create additional arbitrary slots on the card. Maybe it would be better to have a single sticky pkcs15-ish mapping for a fixed profile card in a single location (like the pkcs15 emulation drivers) and allow pkcs15-tool (which does not try to create any PKCS#15 structures) to re-generate exposed key slots and replace exposed certificate slots. And extend that API as needed. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenPGP card / Cryptostick - current status???
Hello, On Tue, May 22, 2012 at 10:18 PM, Peter Marschall pe...@adpm.de wrote: Martin started the extension of pkcs15-openpgp.c to support OpenPGP v2 cards which I continued. (but again: without write support) What was basically removing some v1 related hard-coded constants (like 1024 bit keys) and adding some more parsing of on-card structures, created with gpg --card-edit. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] [Git] branch staging updated. ef835cb8a93087b0551c9786be655adaa2242a08
On Sun, Apr 1, 2012 at 11:09 PM, Git Master webmas...@opensc-project.org wrote: commit ef835cb8a93087b0551c9786be655adaa2242a08 Author: Robbert Müller spam...@grols.ch Date: Sun Jan 8 15:48:12 2012 +0100 Adding default accessflags to the do_store_private_key function in the same way do_generate_key has those accessflags This seems the right thing to do, when you look at the initial commit which added the flags in do_generate_key and the ticket http://www.opensc-project.org/opensc/ticket/198 Currently when storing a key, the accessflags are not set diff --git a/src/tools/pkcs15-init.c b/src/tools/pkcs15-init.c index 2bf3cd1..978fd66 100644 --- a/src/tools/pkcs15-init.c +++ b/src/tools/pkcs15-init.c @@ -886,6 +886,11 @@ do_store_private_key(struct sc_profile *profile) args.x509_usage = opt_x509_usage? opt_x509_usage : usage; } + args.access_flags |= + SC_PKCS15_PRKEY_ACCESS_SENSITIVE + | SC_PKCS15_PRKEY_ACCESS_ALWAYSSENSITIVE + | SC_PKCS15_PRKEY_ACCESS_NEVEREXTRACTABLE; + While all the flags in PKCS#15 and PKCS#11 are related and towards PKCS#11 (which defines its own model for things), I don't think that this is true, especially for an imported key (the thing has gone simpler with the extractable-magic gone) As OpenSC itself, nor most (all ?) cards it supports, don't allow reading the key out of the card (I hope), sensitive should hold true. As the key has been imported, alwaysSenstive does not hold, as the key is in plaintext when imported through pkcs15-init. In PKCS#11 terms, importing a key is like creating it through C_CreateObject, thus the same should hold for the flags: (from PKCS#11): If C_CreateObject is used to create a key object, the key object will have its CKA_LOCAL attribute set to CK_FALSE. If that key object is a secret or private key then the new key will have the CKA_ALWAYS_SENSITIVE attribute set to CK_FALSE, and the CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE. Also rememember, that the flags are mostly cosmetic. In the end the card enforces things, no matter what kind of flags you set in descriptors: (from PKCS#15): The semantics of the accessFlags field’s sensitive, extractable, alwaysSensitive, neverExtractable and local identifiers is the same as in PKCS #11. This field is not required to be present in cases where its value can be deduced by other means. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Hello, On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engert deeng...@anl.gov wrote: The SM branch has pulled in many other changes (including my C_Derive changes) that I would like to see in the next release. If the SM branch is not going to be the bases for the next release, then we need to look at what change in the SM branch can be pulled in to the release. Martin, I would like to hear your comments. Obviously Viktor and others have had way more time in their hands to work on OpenSC than me :) Also obvious is that the most active branch is supposed to be merged as the basis for next release, which was more or less the idea of Git in the first place. As the recovery option, the sync problem between Gerrit and github needs to be cleared. Too much integration is probably not a good idea, two-way syncing between github pull request and Gerrit has brought no obvious benefits... The most straightforward approach would probably be forcing the github tree into opensc-project.org and clearing Gerrit... Martin ___ 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
Hello, On Thu, May 24, 2012 at 4:21 PM, NdK ndk.cla...@gmail.com wrote: 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 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. Martin 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 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] BT reader
Hello, On Mon, May 21, 2012 at 2:46 PM, NdK ndk.cla...@gmail.com wrote: Il 21/05/2012 10:50, j.witvl...@mindef.nl ha scritto: Anyone around who had the chance to look at http://www.biometricassociates.com/products-baimobile/smart-card-reader-iphone-android.html I know that there exist for some time BT-readers, but those from RIM present themselves only as a `rim` device. Urgh... I wouldn't use a BT reader unless the card uses SM. It's trivial, if you sniff the pairing, to decode the whole BT traffic. And non-SM cards receive the pin as cleartext. There's also a list of potential candidates in OpenSC wiki: https://www.opensc-project.org/opensc/wiki/CardReaders#Bluetoothreaders Out of those I've only selected Apriva (have one), as it comes with and SDK for Android (last time I checked, it was pcsc-lite based, javax.smartcardio-ish). Unfortunately, the protocol on BT level is not available. Regarding PIN codes, communication is protected with AES, in addition to BT pairing. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] BT reader
On Tue, May 22, 2012 at 4:01 PM, NdK ndk.cla...@gmail.com wrote: 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. Actually I just installed the latest toolkit to my new android phone and it requires initial pairing through USB (but IIRC it was possible without it as well) Nevertheless, the NSA approved devices all require/suggest pairing in a secure location, with adequate pairing passwords etc. Which is anyway a generally useful suggestion. I'd guess those guys know as well what they are doing and what is wrong and what is right: http://www.nsa.gov/ia/_files/factsheets/I732-016R-07.pdf http://www.nsa.gov/ia/_files/wireless/BlueToothDoc.pdf Then again, considering using convenience solutions (like a bluetooth smart card reader at the moment mostly seems to be) vs being paranoid to the level of radio-sniffing-and-key-agreement-intercepting adversary is IMHO out of balance. I don't think that there are that many scenarios where a bluetooth reader is a must have showstopper. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Biometric integraiton?
Hello, On Wed, Apr 25, 2012 at 16:10, Marc Boorshtein mboorsht...@gmail.com wrote: So I now I have a PIV card that I know has a certificate on it because I can login to my windows terminal with it (XP). The card is using biometrics or a passphrase to unlock. We're using Precise Biometrics card reader. When I put the card into my OmniKey 3021 it didn't recognize it at all, said it was an invalid card type (I'll send over the logs). Here's my question, does OpenSC support any of the biometric readers? I don't know about the readers or their internals, but OpenSC for sure does not support any kind of biometric authentication. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Failed to connect to card: Card is invalid or cannot be handled
Hello, On Sun, Apr 8, 2012 at 21:56, Anton Svensson n00b1...@hotmail.com wrote: Hmm, what kind of info is needed? Dont have that much to be honest, Its a white card, got it after i went to a pki workshop (for 2k8), its from crescendo. And its also typed iclass eh on the bottom. Should i attatch any more logs to make this easier to solve? The card is not supported by OpenSC. It should be a JavaCard, but I don't know if it has some applets pre-loaded or if the keys for loading applets are available to you. You might try asking the body who gave you the card for global platform keys, which would allow you to load something (like MuscleApplet) to the card and use it with OpenSC, but the possibility for this is not guaranteed. And I learned that these cards are locked and the keys not normally available. Thus the card is only usable for Windows-centric operation with the provided HID software. Sorry, for OpenSC you need a different card. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Buffer size and defining constant
Hello, On Mon, Apr 23, 2012 at 11:05, Frank Morgner morg...@informatik.hu-berlin.de wrote: On Monday, April 23 at 02:11PM, Nguyễn Hồng Quân wrote: Hello all, I'm starting to code for OpenSC (with the focus on OpenPGP card). I found in opensc-explorer.c, the do_update_binary() and do_update_record() function use the buffer of 240bytes in size. I want to know if 240 is just convention or a limit of something? I want to replace the hardcode with a defined constant. Do you have a rule about defining constant: name, which file to place...? looks like these numbers could indeed be replaced with a define. The buffer size is limitation to the application and is only loosely bound to libopensc. Sometimes [1] SC_MAX_APDU_BUFFER_SIZE is chosen as upper limit, but sc_update_binary, for example, sends multiple APDUs if the buffer doesn't fit into a single command. So I would opt to go for a opensc-explorer specific define. opensc-explorer is a quite conservative application. For example, reading binary files with 128 byte chunks, not even 256 byte chunks, not to mention reading files like certificates in one go, which usually are around thousand-somehundred bytes or so, which would be a perfect fit for extended APDU-s. As opensc-explorer is supposed to be a failsafe debugging tool, relying on lowest common denominators is somewhat understandable (but far from a best solution). There is a hackish card-specific limitation available, max_recv/send_size which could be re-used. Based on detected card/reader capabilities extended APDU should also be possible through opensc-explorer. When not available/limited, using the standard defaults (255 for outgoing, 256 (0x00 for Le) for incoming) should be preferred. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and multi-arch support
Hello, On Sat, Apr 14, 2012 at 19:55, Alon Bar-Lev alon.bar...@gmail.com wrote: Anyway, now that mingw64 is maintained and I guess the old pcsc-lite may not be supported any more (the one that broke some interface), it should be safe to link at compile time, change should not be significant. Direct linking was also a necessity on Android for some people, for reasons I can't remind at the moment. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ubuntu 12.04 eidenv
Hello, On Thu, Apr 12, 2012 at 14:27, duportail po...@telenet.be wrote: Got a vasco reader working, eid-viewer works correct but got this error when eidenv: eidenv Using reader with a card: Vasco DP905 00 00 Failed to decode the ID file: Required ASN.1 object not found I have a test card with the same ATR and eidenv works fine. Could you post the actual file, by issuing the following commands to opensc-explorer: cd DF01 cat 4031 Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Failed to connect to card: Card is invalid or cannot be handled
On Sun, Apr 8, 2012 at 16:44, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: PS: to the OpenSC members, don't we have a description of what is needed when reporting a problem? I could not find it on the wiki. When trying to post a new ticket, there is a bold link to ReportingBugs, which includes a (maybe too verbose and broad) tutorial on how to send useful information: https://www.opensc-project.org/opensc/wiki/ReportingBugs Also, the mailing lists page has a link to the same tutorial: https://www.opensc-project.org/opensc/wiki/MailingLists Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Failed to connect to card: Card is invalid or cannot be handled
Hello, On Sun, Apr 8, 2012 at 21:56, Anton Svensson n00b1...@hotmail.com wrote: Hmm, what kind of info is needed? Dont have that much to be honest, Its a white card, got it after i went to a pki workshop (for 2k8), its from crescendo. And its also typed iclass eh on the bottom. Should i attatch any more logs to make this easier to solve? The card is not supported by OpenSC. It should be a JavaCard, but I don't know if it has some applets pre-loaded or if the keys for loading applets are available to you. You might try asking the body who gave you the card for global platform keys, which would allow you to load something (like MuscleApplet) to the card and use it with OpenSC, but the possibility for this is not guaranteed. Other than that, the default driver should give a more sensible error in such situations (meaning that even the default might not be the default..) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] removing libltdl?
Hello, On Sat, Mar 24, 2012 at 13:19, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Le 24 mars 2012 12:05, Magosányi, Árpád m4g...@gmail.com a écrit : I guess you might want to discuss the pros and cons of removing libltdl dependency. There is a heap of changesets about it in gerrit. I do not remember why libltdl was needed in the first place. Alon, do you know/remember why libltdl was added? It was added way-way ago in 2005, as there was one library (identically called scdl) which tried to be like libltdl (meaning wrapping dl and LoadLibrary). ltdl was supposed to give better portability (?) See 7d2ebb11c4a969583cadca8adb6e8153228a4866 Is it related to OpenSC on Mac OS X 10.5 for PowerPC? I found a reference in [1]. No. That is just a workaround for 10.5 Removing this is a good thing. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] wiki
Hello, On Sat, Mar 24, 2012 at 00:25, Magosányi, Árpád m4g...@gmail.com wrote: It have very few information and looks horrible. This is how far I could push it. Please help out with it. Will try. Pointing out actual things to take notice of would also be good to have. I think that it would be a good idea to put the GetInvolved page to the header between Roadmap and Browse Source, Good idea! Adding entries to menu bar in Trac requires a plugin and is not doable through the web. I added it as the first entry in the menu and also moved tags more to the front. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello, On Mon, Mar 19, 2012 at 13:08, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: OpenSC copyright belongs to the group of people who wrote OpenSC, which is all of us. It does not belong to any company and an individual granting rights to other individuals. In legal terms, *copyright* on OpenSC belongs to the authors who have contributed code, and/or marked it down in source code. The fact that other, unknown persons (not established in source code as copyright owners) have code in OpenSC source tree is also known, as there is no legal body (foundation, like Gnome or GNU or similar) that would govern licensing in OpenSC. This has also helped free some source code that has been grabbed by some companies and turned into their offerings, without giving source code. Thus everybody are free to use the source code on the same terms, which is mostly LGPL (there are exceptions, like the Tokend code wihich is not LGPL as it is derived from Apple source code etc etc) To be more precise: Peter, Ludovic and Martin do not have any legal right to establish rules over OpenSC project. Especially if these rules go in the direction of more bureaucracy. We have to accept collaboration whenever possible. The only legal right is what is written in LGPL or other licenses and I'm pretty sure that nobody wants to change that. But yes, you are right. Martin ___ 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
Hello, On Fri, Mar 23, 2012 at 15:17, Magosányi, Árpád m4g...@gmail.com wrote: And you simultaneously don't have enough time to review patches. Both are correct and understandable. And there is a way out of this situation. Require assurance of the stuff is working before even taking a look at it: unit tests and/or ack of an established developer, maybe even an end user report confirming the thing is working. Or formal verification with frama-c. Or whatever you read about in CC part 3 or the strike fighter air vehicle coding standards. But if the requirements are met, please take a quick look at it and commit it. And fast. Because if you raise the bar enough, you won't have much junk to sort out and you already have reasonable assurance. True. The trick is having a system that works and also helps to achieve the target of having more people *actually* looking at code and some testing (like automatic building) done before even considering ack-ing something. But lagging on processing any flow is of course not really acceptable. Given that resources are low, automation should help. Like Gerrit och Jenkins. Maybe a daily^H^H^H^H^Hweekly scrum in IRC would be a good idea. There is #opensc on freenode, but people on opensc-devel have most of the time to date been against such communication, either because of timezone differences or just because it is very difficult for a handful of otherwise busy people to find that time (I guess). But a bi-weekly recap would be good idea to have. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello, On Sun, Mar 18, 2012 at 00:30, Viktor Tarasov viktor.tara...@gmail.com wrote: - replication in gerrit do not working. Should we manually push the perfect commits from gerrit's repo to staging? (In the github's pull requests the commits are also perfects, almost perfect.) Fetching github Fetching gerrit Fetching master To g...@github.com:OpenSC/OpenSC.git ! [rejected]master/staging - staging (non-fast-forward) error: failed to push some refs to 'g...@github.com:OpenSC/OpenSC.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. To g...@github.com:OpenSC/OpenSC.git Github mirror was supposed to be a plain (one way) mirror, meaning that things that go through gerrit are published on github and github pull requests put to Gerrit, but merging both to gerrit and github causes expected different trees. Fixing this requires some effort. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Hello, On Tue, Feb 21, 2012 at 16:46, Douglas E. Engert deeng...@anl.gov wrote: It does not define a load key or any finalize commands which would be needed by a production card management system. I don't know about PIV internals, but maybe the finalize step is automatic or not needed at all (meaning that key re-generation is allowed, assuming you want to live without certificates or something similar) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
Hello Anders, On Tue, Feb 21, 2012 at 19:40, Anders Rundgren anders.rundg...@telia.com wrote: I have played with the idea of creating a secure stack-machine for performing arbitrary cryptographic operations on result-data but I couldn't figure out how this would work without introducing vulnerabilities. :-( This sounds really interesting. What kind of problems did you encounter? Do you have any reading material on this? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PINDAD fix
On Fri, Mar 23, 2012 at 10:44, Jean-Michel Pouré - GOOZE
jmpo...@gooze.eu wrote:
Here is outlined a PINPAD fix (read second comment):
http://sourceforge.net/tracker/?func=detailatid=2247688aid=3489002group_id=553887
I would like to know your opinion about the proposed solution.
The comment points out a possible problem with pintest test program,
which should not affect the overall functioning of the pinpad, for
example through PKCS#11.
From the comment:
The problem is that getpass will not return empty string if return
key is pressed on the computer keyboard.
From getpass(3) on Debian 6:
The function getpass() returns a pointer to a static buffer
containing (the first PASS_MAX bytes of) the password without the
trailing new‐line, terminated by a null byte ('\0').
So the input should be a null string with getpass on Debian. But the
man page also tells that This function is obsolete. Do not use it.
Martin
___
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 Fri, Mar 23, 2012 at 22:16, Douglas E. Engert deeng...@anl.gov wrote: ECDH/C_Derive - One needs a smart card that can do ECC key derivation. I have some test cards and some demo cards from NIST that can do this, The NIST people were using the mods for testing with thunderbird, so there are at least 2 of us. Working as in working in a test or working with my software X in environment Z. For example, I have a card that can do ECC derivation, but only a test script to test it against and it is not a PIV card... What this means is that you are not going to get many votes because in some cases only the author can test the code. A +1 from the author may be the most you will get! For non-obvious things, a did not break anything I use is as valuable as works for me as well. In between lies a healthy amount of don't know what it is but it looks weird kind of review, which can filter also many things. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Changed certificate on opensc-project.org
Hello, opensc-project.org SSL certificate expired (kind of suddenly, there should have been a reminder but that did not arrive for some reason), the checksums of the new one are: MD5: 68786c3e0cfe44e31d6c789e767605d5 SHA1: d7af30e8dfd9b6433353999f24e5dbb74132a988 Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MacOS 10.8 Mountain Lion and OpenSC
Hello, Taking a step at a time, I fixed building OpenSC.tokend cleanly (without errors and warnings) on 10.7 [1] [2] with clang and also documented better the fact that Tokend build makes use of binary components from Apple [3]. Regarding 10.8, I've heard rumors that OpenSC (or any other PC/SC based application) does not work with the latest developer preview - SCardEstablishContext fails and there's no pcscd binary on the system either. I don't have the preview nor would I be willing to debug it before the retail version is available, but this could be taken as a sign, that most probably 10.8 will be revolutionary and change everything we know about computing, at least when it comes to smart cards :) [1] https://github.com/martinpaljak/OpenSC.tokend/commits/10.6-0.12.2 [2] https://www.opensc-project.org/opensc/attachment/wiki/MacInstaller/tokend-build-10.7-fix.patch [3] https://www.opensc-project.org/opensc/wiki/MacInstaller#Binarydependencies On Sat, Feb 25, 2012 at 01:00, Martin Paljak mar...@martinpaljak.net wrote: Hello, On Fri, Feb 24, 2012 at 00:15, Douglas E. Engert deeng...@anl.gov wrote: Is anyone planing on looking at OpenSC and Mac OS 10.8? especially in light of: http://lists.apple.com/archives/fed-talk/2011/Jul/msg00099.html and http://www.macworld.com/article/165417/2012/02/apple_readies_mac_os_x_mountain_lion_update.html Regarding PKCS#11, I doubt there's much happening (I *heard* that the pcsc-lite version is still the same, but I'm not interested in trying out Apple betas). But regarding OpenSC.tokend, given previous experience with it and the lack of (public or NDA) documentation from Apple regarding the topic, definitely not before 10.8 has been demod on stage and actual *retail* copy is available. If anything, there might be a few things to keep in mind: - possible requirement to have signed binaries (and installer?) for OpenSC.tokend, if still supported - possible requirement to play together/through the appstore... - tokend/cdsa totally deprecated and a new replacement surfaces (which would render OpenSC.tokend useless on 10.8 anyway...) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Managing the queue line of a compilation farm
Hello, On Fri, Mar 16, 2012 at 11:14, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: GOOZE is working on a compilation farm to compile OpenSC and pcsc-lite/libccid for the following platforms: GNU/Linux: * Debian sid 368/amd64 * Debian wheezy 368/amd64 * Debian squeeze 368/amd64 * Ubuntu precise 368/amd64 * Ubuntu oneiric 368/amd64 * Ubuntu natty 368/amd64 * Ubuntu maverick 368/amd64 * Fedora 15 * Fedora 16 * Fedora 17 * Cent OS 6 * OpenSuse 12.1 * OpenSuse 11.4 Excellent! Providing different Linux packages outside of their native environments (official package trees) would be a nice thing, especially if not so common platforms can be used. At the same time, maintaining *installable* packages (repositories) and debugging them if things go wrong is a time consuming task. From usage statistics in .ee there are some distros on your list that have maybe a single user :) Compiling against different versions and different environments is good and the more varied the installation base is, the better different gotchas can be caught. But for optimal results, the outcomes should be tested as well (I guess the actual compilation-time differences are within minor versions of gcc/clang/pcsc-lite/openssl) Connecting a dedicated smart card reader + smart card and running some automated tests in addition to compilation on each and every platform, that would be a real cherry. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and gerrit
Hello, On Sat, Mar 17, 2012 at 23:01, Viktor Tarasov viktor.tara...@gmail.com wrote: Gerrit still has replication problem -- 'staging' of OpenSC/OpenSC.git do not updated by merges of Gerrit's repository. Certainly, gerrit is nice tool to play with, but, without replication it looses much of it's utility. This was due to the ruby github ssh issue [1], after what all pubkeys were suspended on Github and needed validation. So was the key that did the syncing disabled. As the repostiroy did not seem to be out of sync, I assumed that the keys are still OK and re-enabled them. That should also bring the sync back (will verify). [1] https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MacOS 10.8 Mountain Lion and OpenSC
Hello, On Fri, Feb 24, 2012 at 00:15, Douglas E. Engert deeng...@anl.gov wrote: Is anyone planing on looking at OpenSC and Mac OS 10.8? especially in light of: http://lists.apple.com/archives/fed-talk/2011/Jul/msg00099.html and http://www.macworld.com/article/165417/2012/02/apple_readies_mac_os_x_mountain_lion_update.html Regarding PKCS#11, I doubt there's much happening (I *heard* that the pcsc-lite version is still the same, but I'm not interested in trying out Apple betas). But regarding OpenSC.tokend, given previous experience with it and the lack of (public or NDA) documentation from Apple regarding the topic, definitely not before 10.8 has been demod on stage and actual *retail* copy is available. If anything, there might be a few things to keep in mind: - possible requirement to have signed binaries (and installer?) for OpenSC.tokend, if still supported - possible requirement to play together/through the appstore... - tokend/cdsa totally deprecated and a new replacement surfaces (which would render OpenSC.tokend useless on 10.8 anyway...) Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Moving master forward
On 12/14/11 5:42 , Alon Bar-Lev wrote: On Wed, Dec 14, 2011 at 5:13 PM, Alon Bar-Lev alon.bar...@gmail.com wrote: No, you can use these URLs: https://www.opensc-project.org/autobuild/ https://www.opensc-project.org/codereview/ To access Jenkins and Gerrit respectively. This is great I succeed in login to gerrit using google account. How do I login to jenkins? First experience for me in Gerrit... I cannot reach port 8881 nothing response there... And the http://www.opensc-project/codereview/p/OpenSC.git is also not working. Why such URL, have I made a mistake somewhere and you get this link from somewhere ? The URL for accessing Git through Gerrit over https would be: https://www.opensc-project.org/codereview/gitweb?p=OpenSC.git;a=summary If you have logged on in /codereview, it would also give the SSH remote addresses, for what you can get the password from https://www.opensc-project.org/codereview/#settings,http-password -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Moving master forward
On 12/14/11 5:13 , Alon Bar-Lev wrote: This is great I succeed in login to gerrit using google account. How do I login to jenkins? Actually there is no similar SSO readily available for Jenkins, nor should it be necessary. Jenkins should work semi-automatically by building the branches/trees/changes it has to, like pre-building Gerrit changes or any other trees. The setup is manual, any repository is polled every X minutes, and builds created and uploaded as needed. Jenkins must be publicly available to see the status (green/red button) and any output (Gerrit can nicely cross-reference builds and Jenkins build results) Given that I have remotely recovered access to an otherwise disconnected linux host running the Windows VM-s (SSH tunneling) through a custom job on the Windows guest I'd prefer to keep the configurations under close inspection. If you have Martin -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Moving master forward
On 12/14/11 4:40 , Douglas E. Engert wrote: So are you saying, I should get my network people to open ports 8881 and for me? (I can do that, but since others have the same problem, I was waiting to see if there was some other solution.) No. Everything should be doable over http(s) but having git port open would probably be useful every now and then nevertheless. Beware, that the actual IP of opensc-project.org shall change around Christmas/NewYear. Martin -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Moving master forward
On 15/12/11 01:43, Alon Bar-Lev wrote: Oh... I was so excited I missed some important issue. When submitting a patchset it should be tested for build as atomic unit. Currently the system tries to compile each changeset by it-self. Many times this will not work, as patchset is divided into logical sections suited for review not for build. I'd prefer the opposite, given your exact sample: It would be best if not a single commit would break the build, on any platform. It is probably a bit harder for some structural changes, but most probably possible. As said, I'm working on figuring out how to make the Gerrit changes autobuilds happen on all platforms (Windows included) as at the moment it is a simple Linux tarball build (the Gerrit configuration seems to be tied to master) Splitting patches would make sense if it really was a huge change per se, but it is not. Use git rebase --interactive to merge all these into a single commit with a descriptive commit message before publishing (melding in all those single line messages would also help) The goal is to separate development (small things patched together until it works) from releasing (meaningful changes with enough documentation) Fixing Windows build after a change that broke it is meaningful to me as a developer but useless for normal people. Removing libltdl dependency is understandable to a wider audience. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] sign error with CardOS on Mac OS X
Hello, On Tue, Dec 13, 2011 at 12:51, Johannes Becker johannes.bec...@hrz.uni-giessen.de wrote: using Firefox on Mac OS X with CardOS cards I get a connection error. Ludovic Rousseau kindly showed me how to track it down to the sign function of opensc 0.12.2: I believe this has already been on the list but I don't have the reference at hand. Outgoing APDU data [ 266 bytes] = ... 0x7fff70f32cc0 11:19:18.788 [pkcs15-crypt] reader-pcsc.c:202:pcsc_internal_transmit: 0x0037 00 00:SCardTransmit/Control failed: 0x80100016 You are trying to use extended APDU support (266 bytes) with a reader that does not support it (see the link below). You can try setting max_send_size in opensc.conf to a value that suits you (uncommentig it should work), get a reader that supports extended APDU or help to fix OpenSC so that it would work intelligently in such situations. http://pcsclite.alioth.debian.org/ccid_extended_apdu.html There is no problem on Linux and Windows. Do you use the CCID driver on Linux as well? It should behave the same way. Proprietary Windows driver might do some tricks to implement the extended APDU support. There is no problem on Mac OS X with TCOS cards. They have a different driver and probably don't use extended APDU-s, so this can't be compared directly. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Moving master forward.
Hello, Here is an overview of updates to opensc-project.org plumbing and Git. * Jenkins (build master) has been moved to opensc-project.org. opensc-project.org will move soonish (probably during the Christmas time) to a new bare metal home. This allows to run the builders close together on a decent machine. I'm thus consolidating all bits and pieces that are needed for running the site onto a single filesystem image for easy syncing before the IP address change. The new URL for Jenkins is: https://www.opensc-project.org:/ * Gerrit code review has been set up to manage the construction of the staging branch. All patches sent to Gerrit get automatically built and verified by Jenkins (currently on Linux only, unfortunately). Commits that don't build shall get Verified = - 1 automatically and should not be processed further. Gerrit uses OpenID for authentication (google.com has one, as do many other websites) thus no new passwords needed. Gerrit is accessible on: https://www.opensc-project.org:8881/ Go and log in/register, the existing list shall be included in the submitters group. * Github.com pull requests are automagically sent to Gerrit (polled every 5 minutes). This is a convenience method to get pull requests to a central location [1] [2], direct pushing to Gerrit's refs/for/staging should be preferred. * Because of Gerrit, the majority of Git plumbing is kept on opensc-project.org site. Github integration script makes sure that master and staging branches are available on github.com/OpenSC/OpenSC while picking up pull requests from Github. Github is thus acting more or less like off-site backup of source code. * Signing of OpenSC source releases I'm planning to sign the next release of OpenSC with GnuPG. OpenPGP v2.0 cards or the GPF CryptoStick token (supported by OpenSC to some extent) are currently the best RSA hardware readily available, supporting up to 4096bit keys. After some tweaking it is possible to use it with Thunderbird/PKCS#11 but co-operation (and initialization with OpenSC) requires some further work. * Removing password logins from opensc-project.org ? By relying on OpenID and SSH keys, opensc-project.org would be a much safer place as there are no secrets to guard on the site (except for internal passwords for databases etc) and it is also easier on users, as there are less things to remember. == Moving master forward, AKA how to create staging == Preparing the next master, please keep in mind: - the idea is to keep development separate from releasing, so to say. - to have meaningful changes with enough review and documentation go into the master release history. - git rebase --interactive can do miracles on development trees - commit messages are supposed to be meaningful. There is some ideas and links on DevelopmentPolicy wiki page. - have topic branches. Seriously. Many. I fed Viktor's secure-messaging branch in whole to Gerrit (and thus also Jenkins for building), and the reason why development must be separated from change proposals to master is obvious: https://www.opensc-project.org:/job/Gerrit_tarball_test/buildTimeTrend (or the unverified changes in Gerrit https://www.opensc-project.org:8881/#q,status:open,n,0019920500cf) Red parts of the graphic are commits that result in a stage where the tree does not build on Linux. Windows and OS X might probably be even more different (I'm working on getting Gerrit changes to be built and verified by default on Windows and OS X as well). While merging the tree in whole would result in a buildable state, it is not meaningful to have intermediate commits which are not meaningful enough or even put the tree in unstable state. git rebase --interactive / git commit --amend is the preferred method of fixing such issues. The NightlyBuilds machinery (meaning a tree per developer) is supposed to help by providing access to all released platforms to all developers in a convenient way in terms of building/packaging changes for testing. But the branch to be built is not even supposed to be be the main development branch. What I suggest: Have: master (master branch, from opensc-project.org, ff-only updates to this) staging (staging branch, from opensc-project.org, used to send patches to Gerrit and to rebase against staging on opensc-project.org. Used to build pre-releases) nightly (fed to Jenkins for building. reset/rebased/deleted as needed by a person. Constructed by merging topic branches as needed for distributing changes and testing building against the infrastructure) topic-a (to help separate a logical change and to help communicate it to others) topic-b (ditto) topic-c (ditto) More tomorrow. [1] http://zbowling.github.com/blog/2011/11/25/github/ [2] http://v3.sk/~lkundrak/blog/entries/github-ribbons.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] engine_pkcs11 enhancement
Hello, On 12/6/11 6:02 , Peter Ordonez wrote: engine_pkcs does not currently provide a way to get a certificate from a PKCS#11 hard token when accessed from OpenSSL. I'd like to enhance the engine to support the OpenSSL ENGINE_load_ssl_client_cert() function, which returns among other things a x509 certificate. Since the function provides no way that I can see to specify which certificate to load, I would do this by adding a method to the engine to set the certificate name before actually getting the certificate. The way the function would be used when interfacing with OpenSSL would be roughly as follows: Would it allow to return a list of certificates instead? If there were multiple certificates, the application would be the best to decide which one to use (the search should also be over all available slots...) I think that using a certificate should also indicate the private key to use, so that the only input from calling application would be the certificate and associated PIN code. Best, Martin -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Wiki MiniDriver diagram with wrong name
Hello, On Mon, Dec 5, 2011 at 19:08, Douglas E. Engert deeng...@anl.gov wrote: http://www.opensc-project.org/opensc/wiki/MiniDriver#no1 in the diagram from OpenSCCardMod.png shows cardmod.dll. I think it should opensc-minidriver.dll Can this be changed? The diagrams are made with OmniGraffle on OS X, because it is really easy to use and makes beautiful shapes. I'll see if I can find the source file or re-create the .graffle and attach it to the wiki as well. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with CardMan4040 and OpenSC
On Nov 26, 2011, at 3:01 , Niclas Hoyer wrote: Unfortunately, it seems that the tar file, that HID uploaded is not correct: $ tar xvf ifdok_cm4040_lnx_x64-2.0.0.tar.gz .gz requires z: tar xzvf ifdok_cm4040_lnx_x64-2.0.0.tar.gz -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Free PINPADs available
On 11/23/11 1:06 , Jean-Michel Pouré - GOOZE wrote: ACS ACR83U-A1 Is it different (and how) from the version that does not have U-A1 appended ? (which I have) Also, do you have documentation for the reader? That would be good to have, as there are obviously restrictions. ACS APG8201 This looks more like a childrens toy than a pinpad reader :) Is this the CCID version or the proprietary version? SCM SPR332 This is a good one (given a recent enough firmware), this talks CCID and is supported by the CCID driver. Best, Martin -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] execute PACE
Hello! On Tue, Nov 15, 2011 at 23:25, Frank Morgner morg...@informatik.hu-berlin.de wrote: I was about to add PACE on the PC/SC level, but there are some puzzeling changes in OpenSC from the last time when I read the source code. Back then all control commands were accessed by sc_transmit_apdu with apdu-control = 1 (including PIN verification). Now there is a method for perform_verify in sc_reader_operations, but still the `control`-flag present in `transmit` (and currently only used with the CTBCS commands). Both are contrary approaches: Either multiple functions for different purposes or create one function that does everything with the right input. Usually the first approach is preferred to make the code maintainable. The introduction of the control flag to sc_transmit is a purely legacy implementation, with the first attempts to add pinpad code to OpenSC. It was for CT-API and thus the poor mapping to SCardControl. We discussed that separating transmit and control in `sc_reader_operations` should be done cleanly. But now I am unsure if providing one function per special operation in `sc_reader_operations` is more what you want. If this is the case, then there should be one created for the CTBCS commands (and in my case for pace). I don't think that CT-API/CTBCS is used that much, nor that it is very relevant or the OpenSC implementation optimal. All the vendor specs that mention CT-API I've seen recently (and I don't know of any applications using CT-API except maybe some German e-health/e-banking things) implement CT-API on top of PC/SC anyway. So *hopefully* the same functionality should be available directly through PC/SC, if there are enough open standards and specifications for a topic (things like writing to LCD displays of pinpad readers etc) Ludovic, I hope you have some interesting news from the PC/SC workgroup meeting ? :) IIRC the original discussion had a few combined aspects: * splitting sc_transmit into an APDU version and byte array version (yes) * exporting the byte array version to libopensc (libopensc removal from exported interfaces was to discourage relentless linking against libopensc for smart card support a la linking against OpenSSL if you only need sha1.c) * removing the control piggybacking from sc_transmit (and exporting the outcome) Given the goal of OpenSC (to provide applications access to on-card cryptographic keys through standard interfaces) the implementation of tricks (like using SCardControl to start secure PIN entry) is supposed to happen inside OpenSC. Also, the focus should be on PC/SC (unless you have other requirements) I would prefer the one-function-each-operation-approach, meaning that I just add `execute_pace` to `sc_reader_operations`. What is your opinion? Internally, the API should facilitate re-use by OpenSC components and card drivers. Sorry, I have not had the time to learn about PACE more than the generic overviews, nor how it fits into the cards-and-readers-and-current-software-stack bigger picture. Given that what you want to do can be done above PC/SC, extending the reader callbacks structure with only a control function should be enough. The rest should either fit into a card driver (if it makes no sense as a generic function) or implemented/triggered by a layer different from the card driver (like current pinpad code, inside reader-pcsc.c or in some new file in src/libopensc) By the way, who knows where I can find information about CT-API extensions (not the CT-API itself) such as the CTBCS commands from OpenSC? No idea. I'd suspect the specs are in German anyway. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Opensc 0.12.2, CardOS, Mac OS X
Hello, On Wed, Nov 2, 2011 at 12:28, Johannes Becker johannes.bec...@hrz.uni-giessen.de wrote: A log file produced on Mac OS X 10.6.8 can be found on http://www.uni-giessen.de/~g013/opensc/opensc-OSX-CardOS-debug.log It seems there is a transaction failed error when sending 266 bytes, which seems to be an extended APDU issue. The problem is most probably in the driver for your reader, which can't do extended ADPU-s. One option might be (might nor work) to limit max_send_size in opensc.conf to something smaller. Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACS pinpad support
Hello, On 11/1/11 12:07 , Jean-Michel Pouré - GOOZE wrote: We bought some SPR532. They are old but good (in fact, the reference reader when I was working on pinpad support in pcsc-lite/ccid). Make sure that the firmware is the right version, they changed things back and forth several times. About ACS, did you try libacsccid? It is supposed to fill the gab. My opinion is that CCID is a loose standard. pcscd is modulal enough for vendors to provide their own CCID library. Event SCM does that, even it is not yet in Debian. Vendors are free to distribtue what they want. There are 193 readers in *the* CCID driver list of supported readers [1], including some from ACS. This shows, that hardware can be made in a compliant way and that ACS can do that as well. But a few readers from ACS don't. I try to stick to readers that are compliant and there are plenty to choose from. Compare: Claiming support for HTTP after requiring a proprietary handshake is as good as claiming just the proprietary support. It means that you can only use software already implementing the proprietary handshake. Or hint, that it should be relatively simple to tweak existing software that already talks HTTP to also do the proprietary handshake. But it is definitely not HTTP as the rest of the world knows it. Nevertheless, I might try out the driver as I really like the form factor of ACS ACR83. I had the reader before the hacked driver was available, so it has been sitting uselessly in a box ever since. [1] http://pcsclite.alioth.debian.org/ccid/section.html -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC @ FOSDEM 2012 resurrection of security-devroom list
Hello, 1. I filed for a security devroom again, I hope it will be accepted (hey, they even resurrected the mailing list). The theme of the devroom is (hardware) security / crypto 2. The scheme is the same as last year, except there should be a (different) room for two days, where the second day will be pure hands on hacking. I plan to bring a bunch of different hardware and I hope to see many people from different projects and hopefully we can even have a short hackathon there. 3. Please distribute at relevant lists/forums/groups links - to the mailing list at [1] - to the wiki [2] 4. If you have a talk proposal, please send a short description of it to the same list or add it to the currently empty wiki page [2] following basically the same CFP as last year [3]. Also, feel free to voice your interests either on the list or in the wiki. For example, I'm personally interested in hearing something about CESECORE [4] and Android(/smart cards, like [5]), hopefully this helps to send the word around that we actually could see people associated with such efforts. Best, Martin [1] https://lists.fosdem.org/mailman/listinfo/security-devroom [2] http://www.opensc-project.org/opensc/wiki/FOSDEM2012 [3] https://www.opensc-project.org/opensc/wiki/FOSDEM2011/CFP [4] https://www.cesecore.eu/ [5] http://code.google.com/p/seek-for-android/ -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ACS pinpad support
Hello, On Mon, Oct 31, 2011 at 10:37, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: It does not work in OpenSC. What kind of log should I sent OpenSC mailing list? I gave up bothering with APG8201 [1]. What kind of SCM pinpad readers do you have, if not SPR532? But the standard log of a failed transaction with for example PKCS#11 would be needed [2] [1] http://www.opensc-project.org/opensc/wiki/CardReaders#CCID [2] http://www.opensc-project.org/opensc/wiki/ReportingBugs ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Want to write suppot for iKey4000 USB toekn
Hello, On Tue, Oct 25, 2011 at 02:22, Andy Walls awa...@md.metrocast.net wrote: If the offer here still stands: http://www.opensc-project.org/pipermail/opensc-devel/2008-August/011252.html http://www.opensc-project.org/opensc/wiki/RainbowIkeyFour The best bet is to contact them again, maybe they have changed their mind. You might want to try in parallel to get in contact with their support interface (it is often a lengthy process and getting to technically minded people who can and want to comment on anything might take some time) I seem to have the iKey 4000 variant that is *not* USB CCID v1.10 compliant: That's a sad fact. Since there is an IFD for the iKey2032 in OpenCT, maybe that can be used as a starting point for an IFD for the iKey 4000. Probably. While at it, you can look at how to integrate OpenCT ifdhandler into pcsc-lite by default. For comparison, aside from the iKey 4000, all the ATRs listed in this file: As the iKey4000 comes in USB form factor and is not a smart card or standard CCID device and pcsc_scan is mostly used on Linux (even though it can be compiled on Windows as well, with small adjustments) it is reasonable to think, that the iKey4000 ATR has not yet reached the list :) You could also snoop the USB layer, maybe the card inside works with some existing driver with no or just a few modifications (or maybe just needs a custom profile) Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] card recommendations
Hello, On Tue, Oct 25, 2011 at 10:30, Hans Witvliet h...@a-domani.nl wrote: For tokens and full sized (ID-1) cards i suppose the ones from feitan should work nicely. But how about sim-sized (ID-000)? I'm sure there are several places in .nl where you can get your (non-contactless) cards cut. If not as a professional service (you could ask some mechanic to create the device for probably a (few) hundred euros and start offering the service yourself if you can't find one :) You could also ask your local telco or GSM shop for such services. http://www.gooze.eu/smartcard-mini-sim-cutting-instructions http://www.smartcardfocus.com/shop/ilp/id~82/p/index.shtml ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Truecrypt x64 and OpenSC x32/x64
On Sat, Oct 8, 2011 at 17:58, Jean-Michel Pouré - GOOZE jmpo...@gooze.eu wrote: TrueCrypt x64 is able to detect OpenSC x32 pkcs11 libraries, not OpenSC x64 libraries. TrueCrypt, like many other end user applications, is a *32* bit app. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Trusted PIN support in OpenSC
Hello, On Mon, Oct 10, 2011 at 12:27, Anders Rundgren anders.rundg...@telia.com wrote: Is there any support for trusted (OS-level) PIN input in OpenSC? Trusted path for me means guaranteed by tamper-proof mechanisms, which usually means separate hardware-guaranteed channel, which in turn would mean something like TPC, which generally does not play well in Linux world. Or is this supposed to be catered for by separate PIN-pads only? I think pinpads is the best we currently have. Having signatrue devices with dedicated display capabilities (like the SCM one with integrated Linux and ethernet) would be nice. I expect this feature will be standard in mobile devices. For serious stuff have a look at this trusted display: http://www.gdc4s.com/content/8F084607-EF60-4B0F-8E4A-BC796AB7BC26/images/edgeparts_red2010.jpg Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
Hello, On Tue, Oct 4, 2011 at 17:56, Frank Morgner morg...@informatik.hu-berlin.de wrote: Hi! You can add Reiner SCT's cyberJack RFID komfort and cyberJack RFID standard to this list (both also support SM, which is absolutely transparent to the application). I have been told that filtering VERIFY (or similar commands) is bound to a certain type of card. So the firewall is only active for certain cards but not all? I would like to add only exact and precise information in my lists. This kind of information is hard to get without the help of the manufacturer. Agreed. IMHO the biggest problem is that there might be variations of the same reader with and without this feature, depending on firmware version or worse, without changes in firmware version number. It is even worse if the reader enables this feature based on hardcoded card information or something similar - this way the user has no way of knowing if the feature applies to his usecase or not. The third problem I've seen is the inability to unanimously detect this feature by probing the card and getting a specific error code. The ones I've seen (INS not supported) can be interpreted differently. I have seen readers with this feature (need to specify exact USB ID and firmware version) that work with the CCID driver (more or less): Gemalto PinPad v2 Gemalto Ezio Shield PinPad ACS APG8201 I don't know yet any online shops or retail places selling those. Note that the two readers mentioned above do not use libccid. Does this mean that they are not CCID compatible? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Smart card no longer recognized with git master
On 10/4/11 7:40 , Stef Walter wrote: reader-pcsc.c:243:pcsc_transmit: reader 'Feitian SCR310 01 00' apdu.c:184:sc_apdu_log: Outgoing APDU data [5 bytes] = 00 B2 01 04 00 . == reader-pcsc.c:176:pcsc_internal_transmit: called apdu.c:184:sc_apdu_log: Incoming APDU data [2 bytes] = 69 81 i. If you compare the two logs (looking for the same command) do you see differences? -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
Hello, On 10/3/11 3:02 , Jean-Michel Pouré - GOOZE wrote: 1) What is OpenSC/libccid current PINPAD support? I have to admit last time I used PINPAD was more than a year ago. What exactly is your question? The support for pinpads has been there for several years for now. As noted in code, it often requires vendor specific hacks as many readers are bogus (they only support a subset of what is defined in CCID, for example restricted min/max PIN lengths or entry conditions). 2) What does it mean when a reader claims 'secure messaging'. Does it need to be supported on the smartcard side also? Is it a real standard in CCID? Is it well supported in OpenSC? I assume you refer to authenticated communication between terminal (firmware) and card? This would require support on card as well as in terminal. This would be quite closely coupled and does not really relate to OpenSC. 3) I still wonder why we should declare PINAD in OpenSC configuration file. Is there an alternative, when libccid would discover PINPAD and OpenSC would automatically using it. Could you tell more of the current way that OpenSC discovers the PINPAD. This is exactly how it is working. There is an option in opensc.conf to turn the pinpad *off* (as it is enabled by default) if there are problems with the device or some application. Note that pinpad support in applications and platform libraries (OS X, Windows) varies. -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Status of PINPAD support in OpenSC / libccid
Hello, On Mon, Oct 3, 2011 at 16:07, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: Some pinpad readers have what they call a firewall. The reader will not allow you to use a VERIFY command without using the pinpad feature i.e. it is not possible to send a PIN 'in the clear' to the card without using the pinpad feature. This should be quite limited list and is AFAIK not more than a few models at the moment. Maybe adding a note to the nice reader list would be useful, for readers which are publicly available and known to contain this feature? Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Using Finnish Goverment Identity card for smart card logging
Hello, On 9/19/11 11:25 , Hannu Kotipalo wrote: I succeeded in configuring pkcs11-pam module to use Identity card issued by Finnish goverment. Also, smart card with cacert certificates works ok (certificates ar stored on Aventra MyEID cards). Great! However, there seems to be some problem with revocation lists. 1) if any of the certificates on the chain does not have a crl distribution point, the check will fail. I would assume that if certificate has defined no crl distribution point, it should be ok withoiut the check? That would be very wrong. If key generation and distribution is one of the weakest links, then revocation and adequate checking is another great problems of PKI setups. Unless you want a simple possession of key authentication on a single (disconnected) computer you might omit revocation checking (and use pam_p11 instead), but for everything else that works with certificates, you really want to check them for validity. As CA certificates are not revoked very often (except Diginotar, of course ;)) and they anyway need to be hand-coded into software or configuration to be a trust anchor (at least roots(, you could omit revocation checking for CA-s (given a compromised CA, the CRL for it would be somewhat worthless). But checking end-entity certificates is a must. Or is it? Looks like one of the ca certificates on the Finnish ID card does not have the crl dist point. See debug below. Adding certificates would also help. I have two Finnish test cards, I can check the certs as well (given that they are not much different from actual certificates) 2) cacert has their crl list at secure https - address. pam-pkcs11 does not seem to support that. Would it be easy to add it? That might be automatic. pam_pkc11 can use cURL and cURL can handle https. Did you add support for cURL when compiling? Maybe you have not enabled SSL support in cURL? DEBUG:pkcs11_inspect.c:132: verifing the certificate #1 DEBUG:cert_vfy.c:256: downloading crl from http://proxy.fineid.fi/crl/vrkcqcc.crl DEBUG:cert_vfy.c:464: certificate has not been revoked DEBUG:pkcs11_inspect.c:146: Inspecting certificate #1 Printing data for mapper subject: /C=FI/serialNumber=T/GN=NAME/SN=SURNAME/CN=SURNAME NAME T http://proxy.fineid.fi/arl/vrkroota.crl /C=FI/ST=Finland/O=Vaestorekisterikeskus CA/OU=Valtion kansalaisvarmenteet/CN=VRK Gov. CA for Citizen Qualified Certificates check_for_revocation() failed: neither the user nor the ca certificate does contain a crl distribution point The error is misleading. Also, it seems that pkcs11_inspect tries to verify all certificates on the token the same way, as you'd not be authenticating with the CA certificate on the card but your personal certificate, this might need some adjustments in pkcs11_inspect code (only non-CA certificates should be processed). Have you tried to actually use pam_pkcs11 and it fails? pkcs11_inspect might not be most appropriate debugging solution in this case. Best, -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.12.3 master plan
Hello, On 9/21/11 6:52 , Douglas E. Engert wrote: Back to the master plan. Yes. I was off for 5 days in Brussels for BruCON (which was great!), so back to things and plans. Would it help to for a developer to rebase their changes as you add other changes? Yes. Viktor said on 8/11/2011: I guess that we should have some intermediate branch with a more or less common commit access, that can be fed by more then one person and that could be used as a fresh code base for the patch/merge proposals. This branch could be considered as 'almost sure' and normally could be merged into the individual experimental branches without apprehension. This branch should be the only one to be checked for the conflicts by proposals authors. I was thinking about something like 'proposal' branch of the OpenSC github. A developer could rebase their changes against this 'proposal' branch so making it easier to pull in the developers changes. Yes. I am willing to do a rebase for the ECDH code. Great! There is one area that still needs to be addressed. The ecdh/derive depends on much of the code that was introduced by the USE_PKCS15_INIT. But USE_PKCS15_INIT is only defined if ENABLE_OPENSSL is defined, and USE_PKCS_15_INIT ifdef's out much of the code that is needed by derive even though the derive code does not use OpenSSL. So I/we need a mode to change the #ifdefs for USE_PKCS15_INIT. This could be done against the 'proposed' branch, and then the ecdh code could be rebased on top of that. What do you suggest? This should be addressed. I've separated OpenSSL usage in src/libopensc to a softcrypto minimodule and am half way through with making sure that the interface would be sufficient by re-implementing used functionality with alternative libgcrypt backend as well. In src/pkcs11 the use of OpenSSL is even more interwoven, so fixing this is more complicated. As soon as I am be done with the code in src/libopensc I'll push it out for review and additional help to get this into src/pkcs11 as well. Decoupling ENABLE_OPENSSL and USE_PKCS15_INIT beforehand would nevertheless make it even more straightforward. IMHO the following assumptions should be applied: - USE_PKCS15_INIT should disappear altogether - building with a softcrypto library (OpenSSL or libgcrypt or CrytpoAPI or maybe even something entirely different) shall be assumed - building *without* a software crypto back-end should also be possible, but this should not be accomplished by huge code blocks being made inaccessible. In fact, there should be no #ifdef-s checking for OpenSSL or similar in common code, only in src/libopensc/softcrypto(-*.c|.h). sc_softcrypto_features() kind of machinery can be used to test for the presence of certain algorithms or ciphers if needed for advertising features. - building without a software crypto back-end shall possibly result in undefined behavior and probably several SC_ERROR_NOT_SUPPORTED errors, if hit. Just need to make sure that they get reported appropriately. Best,ƒ´ƒ Mar tin -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] MiniDriver in Mobile Phones
Hello, On Sep 18, 2011, at 12:17 , Anders Rundgren wrote: It seems that there are big hopes associated with Microsoft's MiniDriver. From where? I don't understand why because it is poorly documented, has zero standards status, and has AFAIK only been implemented in Windows. And will only be implemented on MS platforms. It is a vendor mechanism and will remain one, IMHO. Another issue is that I don't see how the MiniDriver provisioning model could be transferred to mobile phones since the concept of shared secrets for card management assumes that there is a relation between the card and the issuer which doesn't scale particularly well. Why is this even important you may wonder? Because Virtual Smart Cards using embedded security HW is already a feature in Windows 8: http://channel9.msdn.com/Events/BUILD/BUILD2011/HW-462T Interesting, will watch. But I'm still no believer for the TC/TPM field, in consumer products (like Windows, maybe for Apple ;)) -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs11-tool -O
Hello, The included patch [1] fixes the usage text and also the man page to reflect the fact that specifying the module is mandatory. Not the most elegant one (abuses app_name) but works. 0001-pkcs11-tool-update-help-and-man-page-to-reflect-the-.patch Description: Binary data [1] https://github.com/martinpaljak/OpenSC/commit/dca75429d69da7de956d3b2a74706d6956d59cfa Best, Martin On Sep 16, 2011, at 11:39 , Mike Tancsa wrote: For some reason, this does not work on 12.x ? It just comes up with a usage error. eg on 11.8 # pkcs11-tool -v -O [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found [opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found Certificate Object, type = X.509 cert label: Certificate ID: 45 Public Key Object; RSA 2048 bits label: Public Key ID: 45 Usage: none and on 12.x # pkcs11-tool -v -O Usage: pkcs11-tool [OPTIONS] Options: --module argSpecify the module to load (mandatory) --show-info, -I Show global token information --list-slots, -L List available slots --list-token-slots, -TList slots with tokens -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs11-tool -O
Hello, On Sep 16, 2011, at 11:39 , Mike Tancsa wrote: For some reason, this does not work on 12.x ? It just comes up with a usage error. # pkcs11-tool -v -O Usage: pkcs11-tool [OPTIONS] Options: --module argSpecify the module to load (mandatory) The Usage: line should be changed to: pkcs11-tool --module arg [OPTIONS] in next release… Best, -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] TaiwanEid
Hello, On 13/09/11 05:35, 周彥江 wrote: I have some TaiwanEid tokens and interesting in OpenSC. How should I make some contribution on the project? I am a C# / Java programmer. Great! Start by updating the wiki [1] with factual information to include relevant bits and pieces (card, ATR, known information/docs (preferably in English) OpenSC is mostly C, so sharpening your C skills might also be useful. For the starters you might follow the procedure on ReportingBugs [2] to get the basic information about your card. Best, Martin [1] http://www.opensc-project.org/opensc/wiki/TaiwanEid [2] http://www.opensc-project.org/opensc/wiki/ReportingBugs ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ECDSA cards
On Fri, Sep 9, 2011 at 01:56, Nikos Mavrogiannopoulos n...@gnutls.org wrote: On 09/06/2011 03:38 PM, Martin Paljak wrote: I'm trying to use the opensc 0.12.x ECDSA support, to allow ECDSA signing in gnutls via PKCS #11. However I have no such cards to test it. Do you have any suggestion on which card to use? (My only requirement is that it must be obtainable without placing a mass order) This is a difficult requirement. I'm not aware of any, except for a PIV card that might work but that's not available any more from smartcarfocus.com from where I got one. In fact, it seems that even decent java cards is a rarity these days... Pretty strange. I couldn't find any elliptic curve supporting smart card on the market. I'd expect them to be more widespread due to their smaller memory requirements than rsa. Maybe Certicom and licensing is the reason... ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC 0.12.3 master plan
Hello, Autumn has started (at least in northern hemisphere) so it is time to pull together next OpenSC release. Things to do that should be cleaned up into hopefully self-contained patches: - secret key object signature (Viktor and Douglas have different signatures) [1] - secure messaging, at least in the minimal scope of what belongs to apdu.c (card driver based wrap/unwrap?) [2] - new drivers, that depend on secure messaging: - DNIe [3] - epass2k3 [4] - ECDH support [5] - Coverity fixes - Minidriver updates [6] - Proper reader detachments (only really affects PKCS#11) [8] - Updates to installers - Windows: incorporate automatic minidriver configuration for all (at least select) cards - Mac OS X: generic updates and settled 10.7 support (until further information from Apple will be available) - Separation of OpenSSL into a softcrypto mini-api with an alternative backend (libgcrypt as it is LGPL for Debian) [7] - Updates to the Git workflow that would make it more easy to understand for brains, with a continuous staging branch (revertable). But non-trivial changes should still go through separate branches... Anything I missed? I'll put this to a wiki page as well with probably more notes. [1] https://github.com/dengert/OpenSC/commit/9f72469d7281ccc660cec4cc7cc96559ceb9f032#commitcomment-525973 [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging [3] http://www.opensc-project.org/opensc/wiki/DNIe [4] https://github.com/OpenSC/OpenSC/pull/1 [5] https://github.com/dengert/OpenSC/commits/ecdh [6] https://github.com/viktorTarasov/OpenSC/tree/minidriver-write-mode [7] http://www.opensc-project.org/pipermail/opensc-devel/2011-August/017116.html [8] https://github.com/viktorTarasov/OpenSC/tree/detach-reader ___ 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 Fri, Sep 9, 2011 at 10:39, Viktor Tarasov viktor.tara...@gmail.com wrote: Le 09/09/2011 09:23, Martin Paljak a écrit : If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. Then the solution is IMHO simple. AFAIK only one proprietary (which does not work with 0.12 IIRC, the troubled DNIe binary module) exists in the wild at the moment and I don't think we should bolster piggybacking on OpenSC for this purpose. Best, Martin ___ 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/11 11:32, Viktor Tarasov wrote: Le 09/09/2011 10:09, Martin Paljak a écrit : On Fri, Sep 9, 2011 at 10:39, Viktor Tarasovviktor.tara...@gmail.com wrote: Le 09/09/2011 09:23, Martin Paljak a écrit : If we omit loadable modules, we could also take that ATR tables are indeed static and do not need to be released? Is this correct? Exact. Only loadable module prevents the static ATR tables. Then the solution is IMHO simple. AFAIK only one proprietary (which does not work with 0.12 IIRC, the troubled DNIe binary module) exists in the wild at the moment and I don't think we should bolster piggybacking on OpenSC for this purpose. Fine, and to continue this movement, could we envisage the abandon of support of the obsolete cards ? As you are also the original code author, you should be the best to judge what is relevant and what not. Example, 'oberthur' driver supports the old v.2.xx of the 'AuthentIC' PKI applet with the proprietary file system. This card is not more produced. The new 3.2 version of this applet, compatible with PKCS#15, is actually supported by 'authentic' card driver. If there are cards out there and there is not much needed to maintain the current driver as a working entity, I would not rush to remove it ASAP. Maybe a forward notice would do good and the code can rotten there with the intent of being removed in X months ? Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] serialnumber
Hello, On Thu, Sep 8, 2011 at 13:27, j.witvl...@mindef.nl wrote: According to the openvpn-docu, (at the server-side) one of their environment variables, tls_id_0 should contain the hexadecimal value of the certificate. In reality in contains completely other fields, like CN=, OU=, O= and C=. I guess the tls_id_0 should contain exactly this, the subject of the certificate? Is there any tool to lookup the serialnumber of a certificate stored on a smartcard directly? I know I can export the certificate manually and use openssl to analyse it, but can it be done with one of the pkcs* open opensc* tools? pkcs15-tool --read-certificate num | openssl x509 -text ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Aladdin 64K 4.2B tokens and OpenSC 0.12.2 Aladdin tokens no longer working?
Hello, On Wed, Sep 7, 2011 at 09:10, Dan Peterson drpeter...@es.net wrote: Could be. I don't think the problem is same by nature. I have or can create debug logs if anyone is interested. I an looking into if this happens on the MAC code base as well, I think it does but I am not sure I think it will behave the same. Please provide the logs for success (0.11) and failure(0.12) as well if possible. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ECCN number
Hello, On 06/09/11 09:47, HOURY William wrote: I have been asked the Export Control Classification Number (ECCN) number for OpenSC. Never heard. Does anyone know it ? Should it be 5D002 ? Could be 5D992 as well. If you ever find out from authoritative source please enlighten others as well. This belongs to the wiki, together with licensing information I guess. Best, ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Minidriver in 'write' mode
Hello, On Aug 29, 2011, at 7:53 , Viktor Tarasov wrote: I committed the initial version of the minidriver in 'write' mode. https://github.com/viktorTarasov/OpenSC/commits/minidriver-write-mode There are some changes that concerns both 'write' and 'read-only' modes: -- the content of 'cardcf' is created with the first successfull method in the following order: --- the on-card pkcs#15 DATA object (application:'CSP',label:'cardcf'); --- 'lastUpdate' attribute of tokenInfo. As a 'freshness' value the CRC-32 calculated on 'lastUpdate' is used; --- random value. -- 'cmapfile' (containers) is emulated from existing privateKey pkcs#15 objects. If the on-card pkcs#15 DATA object (application:'CSP',label:'cmapfile') is accessible, then it's content used to update the non-pkcs#15 attributes of emulated containers. In 'write' mode: - 'write' mode is activated by setting to 'false' the 'md_read_only' option in the 'card_atr' section of OpenSC configuration file; -- every 'WriteFile' on 'cardcf' updates the on-card pkcs#15 DATA object 'CSP':'cardcf'. -- the 'WriteFile' on the 'cmapfile' is stored in memory and is encoded and written into the on-card pkcs#15 DATA object (application:'CSP',label:'cmapfile') when 'Deauthenticate' procedure is called by BaseCSP. Tested with 'AMOS IAS/ECC' card in IE on Windows XP platform. Test consisted in the decentralized card enrollment, followed by the authentication to access the protected Web page. For the unknown (for me) reasons, when generating key in IE, BaseCSP tries firstly to import the 'soft' key, instead of generating one on-card. If minidriver refuse this attempt, BaseCSP generates key on-card. This 'feature' gave the possibility to test key generation and key import . (For a while I do not managed to import P#12 with the 'CSP' attribute pointing to BaseCSP using IE or certmgr.msc). No other application where used for tests. Still needs to be tested on the other windows versions. Interesting. I'll give Windows 7/64 a try. -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Brucon anyone?
Hello, I'll most probably be visiting Brucon [1] next month. Anyone else planning to visit it or will be around 17..21 September to have a chitchat on smart cards etc over some fine Belgian beer? Martin [1] http://2011.brucon.org/index.php/Main_Page -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Failed transactions with a card in some readers with INS in 9X/6X range
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, I observed something interesting when scanning the command space (CLA+INS) of a card with a few different readers (CardMan1021 and Gemalto EzioShieldPinPad among others) Certain INS codes fail with transaction failed on CardMan1021 whereas succeed on Gemalto reader with the same card. I also tried SPR532 (another TPDU reader) and got somewhat similar results (count, INS code in hex for failed transactions with the same card in different readers) $ grep -i fail ok1021_cmd_scan.txt | cut -d' ' -f 2 | sort | uniq -c 127 68 127 69 1 6A 1 6B 1 6C 1 6D 126 6E 126 6F 126 90 126 91 1 92 1 93 1 94 1 95 127 96 127 97 $ grep -i fail spr532_cmd_scan.txt | cut -d' ' -f 2 | sort | uniq -c 127 68 1 6A 1 6D 126 6E 126 91 1 92 1 95 127 97 The file itself contains lines like the following: F0 96 00 00 = 68 84 F0 97 00 00 = Failed to transmit with protocol T0. Transaction failed. F0 98 00 00 = 68 84 The actual pcsc-lite error code is 0x80100016 (SCARD_E_NOT_TRANSACTED). Also tried with CardMan3821 (APDU reader) and got failures as well (the count of failures of INS codes does not seem consistent) I suspect it has something to do with the following in ISO 7816-4 (5.1.2): INS indicates the command to process. Due to specifications in ISO/IEC 7816-3, the values '6X' and '9X' are invalid. Is there some explanation to this (I probably can't comprehend 7816-3 in meaningful time)? The trick here is that the same command works with other cards in the same reader and with the same card in some other readers (always with T=0) I'll publish the python scripts after some formatting, this might be generally useful if you have cards you don't know much about and can afford to brick and want to scan for interesting things. Trying the same on Windows will be the next step. But maybe there's a documented explanation to this. Best, Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJOVjJbAAoJEHSCZV4wfjRSXCcP/A0yhdCQtkiozY7YlH2V874Z mrTKFmKzTfzzvllktDwYFaFs9/4KQAaGUKmlGRiEhavy9T7sJWsoF7iM9Ip0HHpT t7IPCu+vb9/sIR6KQhXj0SWmucdEZNweOF6RbiwixpotFJBigpvaZzOU198qQ7x5 pH+Qh6geko/fEvldmHTgGsEIJl5ir7wuCu//8Ojczpdib4JsJ5CZ61WuOLg0Cj0p lPoltDuxyDXiru4PkoWJcfz/7g/UM/J4dbMsXteB3/ygNmL6hhXLctzrliGeP3nq bz6FkvJFHhaa4bNPHwuWPvSfrejhs9Q5lfHFNRjQdjglSaLbEIlqPq80cDW82fvL PmZRA4EwJr5T4JgGj8nJc0cJ4vZbsgwUgGkmk9ZnZflfk4eof4/s43AlMxlE1mbj QLDmwzzhv76aroe+Y9SmU7O2CjSqd6/n0QADiEOBo4chbxd2OiSI4+uCJzQMsQ1j xSiOxrKKZsCPF+a/F5KR0jKOdFka3FbZAc/4Yz9alfz0YpCDyeZMchwMOaMsfX5U BA290mpHQTbv24ueAPmU36tuiaZz5IsqoNLroET5+OAL4cX7eKyxG2wnXsYtXin8 yTif1NylEvl0mzl+RX242KbEqupzqimUFAOD8Txkx+zXCJZZHshAsxpIE6ZqU1xO /iEmqVBRriQw674Q/7sj =XWyE -END PGP SIGNATURE- ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [Muscle] Failed transactions with a card in some readers with INS in 9X/6X range
Hello, On Thu, Aug 25, 2011 at 14:47, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: The realy strange situation is that you can have a working T=0 card+reader with these invalid INS bytes. In your INS exploration program just skip 6X and 9X INS values. Thanks for the explanation! For the fun of it I think I'll do the opposite instead: - make the protocol dependant probing more explicit (for several stupid reasons I'm using T=0 only currently, as this is the only supported algorithm for Estonian eID cards) - DO probe the forbidden ranges (not by default though) - see what happens with different card+reader combos :) Would it make sense to debug on USB level what is happening at different situations, to maybe make the CCID driver more robust (== predictable outcome with different readers)? I currently understand that this is up to the reader firmware currently, which also explains the different outcome from different readers. I'll see if there are more readers in my collection that can use those INS codes.. Best, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
On 8/23/11 8:44 , Peter Marschall wrote:
On Sunday, 21. August 2011, you wrote:
On 08/21/2011 12:36 PM, Peter Marschall wrote:
* renable zlib readline support
i don't think these are compatible with the DFSG, alas.
GNU readline (at least) is GPL-licensed, and opensc links
against OpenSSL. So building a package that links to both of
them creates a non-redistributable work :(
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
The linked page on OpenSSL and GPL also gives some additional hints:
1. Usual disclaimers apply, I've no legal background whatsoever,
don't trust a word I say ... I'm quite probably completely wrong.
2. One recommended way around this GPL incompatibility is to add an
OpenSSL exemption when you license your code under the GPL.
3. Remember that OpenSC is LGPL, not GPL (even though it is legal to
upgrade LGPL to GPL as has been proven by Spanish government)
4. iAnal as well. Consulting FSFE (for a second opinion on what can
and what can not be done) would be beneficial.
5. I consider Debian's position as a die-hard free software
precaution, I don't know that the OpenSSL vs (L)GPL issue has ever
been tested in courts, nor that it would actually represent the
interests of any involved party (be it OpenSC code contributors or
OpenSSL developers).
It is just something that is advised by lawyers as a precaution.
6. Creating unofficial, more complete but maybe more reckless packages
would still be beneficial, given that the distributor takes the
associated risks (I personally still believe that common sense and
good intents beats the lawyer-centric world we live in)
7. IMHO OpenSSL is something that comes with the operating system in
Debian (and other Linux distros)
Is there any way to have OpenSC build against some crypto
libraries other than OpenSSL (preferably licensed in
GPL-compatible ways) so we could link it to readline without
violating one license or the other?
Two options:
- decide to move to some other soft-crypto implementation and reap
out OpenSSL (would be lovely)
- create a small softcrypto mega-interface and allow to plug in
different softcrypto implementations (something like cURL did)
gradually. This would allow to build without OpenSSL in Debian and such
and provide a way to still make use of drivers which might not have a
developer or somebody to test any changes.
OK, let's leave out libreadline (simple changes in
debian/{rules,control}).
My interest is less in libreadline - although it makes
opensc-explorer a lot more comfortable - but in an update to opensc
in Debian.
What about that? PS: if zlib has similar issues, then maybe leave
it away too.
I don't know of such limitations.
- --
@MartinPaljak
+3725156495
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (Darwin)
iQIcBAEBCAAGBQJOU0bXAAoJEHSCZV4wfjRSfroP/1IeDmFPOPWO2ZosXglsYFmM
kYYzvah8l6G8F5KyHbo93vc3BeOe4zQN1ir3zMTpkBsSNDWdPtjd9g3j1uAF72/W
yNXvVgqihoAZ9HquRFqV1LMqR+4KpW/Wjm0eZm6y8TsgF7rPSVKSSZqwCdvye0up
uFZSBWQ4XOjQpFCdlrXJvCidzQ4a2f/RTdkqr0T0W5ntAGgks2WlbUn+bDSQnQVf
EmpU8SK0SOMzDxicXkVUjUmaVusxkLE1KFW3VPH0jEp1zjvtSidbFw6iNk2Vs98a
8KViwk/09BmHJ7vRv57KwFnOa9mCmVyX2gJyHSwbB7kflA7a2fxep8BdOdWQ9S7q
jKP0KJZmMuabFDJIvAlL0h1xIozikHCldhB46f/7lgZNssfy+AkaI1taA75uBJuy
AD5w+6YfkFTAriihbg0L+xshFiQSxKbSMzq0128/8vS59LZsq/O9JZ/xgaHiM2Lh
bot9M2Tj5efii4mdM0SWQx32O8jm8mmSrQLwIrdNqe4YavvpE0bPcI4Vz3ZGYnyz
2h6J7xm/I5KddIUb+jwVoB1OBudZ2KboUvwkQZaC8HYcf/Mzsk6wkGplyuTv0gjg
1Fc+bpG4kIRHsI4HKDB2FYcP+uYo4lMj0rCA0JcITckMpiVtgw9+E4Ucu7thPYFF
CED/e/n3jp8nUfugnYLg
=U75N
-END PGP SIGNATURE-
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Fork of Debian's openSC repo at Github with ideas for 0.12.2 DEB
On 8/23/11 11:46 , Ludovic Rousseau wrote: 2011/8/23 Martin Paljak mar...@martinpaljak.net: Is there any way to have OpenSC build against some crypto libraries other than OpenSSL (preferably licensed in GPL-compatible ways) so we could link it to readline without violating one license or the other? Two options: - decide to move to some other soft-crypto implementation and reap out OpenSSL (would be lovely) - create a small softcrypto mega-interface and allow to plug in different softcrypto implementations (something like cURL did) gradually. This would allow to build without OpenSSL in Debian and such and provide a way to still make use of drivers which might not have a developer or somebody to test any changes. Apple has deprecated OpenSSL in Lion. OpenSSL is still available but will be removed in a later version. See http://ludovicrousseau.blogspot.com/2011/08/mac-os-x-lion-and-openssl.html I think the correct option for OpenSC (if we stay with OpenSSL) is to statically link with OpenSSL (as I imagine is also done on Windows). From what I learned from the WWDC slides [1] (need to be signed in to ADC before opening the link) the reason for deprecating OpenSSL as an API from platform was troubles with guaranteeing ABI-compatibility (kitchen-sink API?) and the need to have an up to date FIPS compatible platform (OpenSSL is undergoing a new FIPS validation at the moment, AFAIK, but still only for x86). OpenSSL is in that matter a defacto industry standard, but far from being perfect for many use cases. But this only affects OpenSC on Mac OS X (which, in theory, should have the same problem with OpenSSL and license incompatibility as on Linux). Static linking is not the problem nor the solution on Linux (package dependencies should remove the ABI problem) For OS X, the main question is not what/how to use instead of OpenSSL, but what needs to be implemented instead of Tokend/CDSA to provide support for native applications. FYI: Safari 5.1 on 10.6 crashes with OpenSC.tokend. Or any tokend in that matter. Studying alternatives for OpenSSL would be a good idea nevertheless, creating a 15th API [2] for software crypto would also be sweet, why not having gateways to CommonCrypto/Transform on Mac (or whatever else they figure out next) and/or CNG/CryptoAPI on Windows in addition to a new chosen LGPL-compatible default platform as well as existing OpenSSL. Learning from cURL experience [3] would be useful as well. Best, Martin [1] http://adcdownload.apple.com/wwdc_2011/adc_on_itunes__wwdc11_sessions__pdf/212_nextgeneration_cryptographic_services.pdf [2] http://xkcd.com/927/ [3] http://curl.haxx.se/docs/ssl-compared.html -- @MartinPaljak +3725156495 signature.asc Description: OpenPGP digital signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] banks
Hello, On Aug 18, 2011, at 12:11 , Hans Witvliet wrote: Hi all, Perhaps a ludicreous question, but i post it anyway... Some creditcard companies or banks supply their customer with cards plus pin-code in order to identify themselfs during financial transactions. From my focus i presume these look like ordinary smartcards. Can these cards also be used for anything else? Did anybody ever looked at them this way? It is not that i would try to temper with them, but if these are safe enough to be trusted by a bank, why could i not use them for instance, for setting up a vpn? You might want to study EMV DDA http://www.openscdp.org/scripts/tutorial/emv/dda.html -- @MartinPaljak.net +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] transferr of private key to ikey3000 using opensc-0.11.11
Hello, On 8/18/11 10:57 , sibu xolo wrote: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt error:0906A065:PEM routines:PEM_do_header:bad decrypt error: Unable to read private key from mykey.pem ... I have two passphrases I used whan I gnerated the key; the passhrase for the certificate mycert.pem and the passphrase for the CA when I signed it. I tried either of these passphrases without success. Try to generate the key (assuming you are using OpenSSL) with -nodes, meaning without a password. -- @MartinPaljak +3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with Gemplus GemXpresso Pro R3 E32 PK
Hello,
On Wed, Aug 17, 2011 at 23:39, Douglas E. Engert deeng...@anl.gov wrote:
--- a/src/libopensc/card-gemsafeV1.c
+++ b/src/libopensc/card-gemsafeV1.c
@@ -172,6 +172,7 @@ static int gemsafe_init(struct sc_card *card)
/* SELECT applet */
r = gp_select_applet(card, exdata-aid, exdata-aid_len);
if (r 0) {
+ card-lock_count--;
free(exdata);
sc_debug(card-ctx, SC_LOG_DEBUG_NORMAL, applet selection
failed\n);
return SC_ERROR_INTERNAL;
sc_lock/sc_unlock should be used instead of direct modification.
Best,
Martin
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Problem with Gemplus GemXpresso Pro R3 E32 PK
On 18/08/11 17:34, Douglas E. Engert wrote: The patch was in the spirit of the current code, that already does card-lock_count++; before this, and card-lock_count--; after this. Ah, a good thing to grep for :) Thanks, Martin ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
