Re: [opensc-devel] Secure Messaging and concurrent access to card
But why don't you store the needed SM-data in the card's private data? This way each card handle has it's own SM context and could access the card with different SM parameters (if supported). Sorry I can't: AFAIK DNIe is read only, at least at user level Ideally, virtual channels should be used, but not enought documentation on card to make sure that DNIe supports them. Need to test... So cannot store sm context in card When talking of virtual channels, do you mean the logical channels defined by ISO 7816-4? You could have a look at the ATR's historical bytes or EF.ATR to see if those are supported. If so, you only need to count the connections to the card and set the appropriate bits when sending APDUs. Such a counter could be stored in the driver's private data. If you only access the card through OpenSC, you do not need something like a daemon, which makes this kind of stuff. I'm thinking on a sort of SM daemon to take care on apdu encoding/decoding Please have a look at victor's repository http://www.opensc-project.org/svn/opensc/branches/vtarasov/opensc-sm.trunk/ He uses relaying to a distant entity to encode/decode SM APDUs. This sounds pretty much like what you have in mind. I'll take a look. Actually I know about 4 different approaches - Use virtual channels. But need to test for feature availability on DNIe card As I am understanding it, the user's consent would be required for each channel. And that's a good thing: You want to authorize different operations with your cards independently. So the conclusion is: Either you access your card only through OpenSC, then you could use the private-data-approach or you access your card through different applications with different use cases, which reasonably requires multiple confirmations. Greets, Frank. pgp9mqZc72sa8.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging and concurrent access to card
On Monday, February 14 at 12:22PM, jons...@terra.es wrote: In the testing process of OpenDNIe I've found a problem related with concurrent access to opensc-pkcs11 library. In short: as DNIe can only handle one SM at a time (no virtual channel support), there is no (known) way to get concurrent pkcs11 access This feature makes unusable most of signing applets commonly used in many official sites Afaik opensc-pkcs11 is thread/process aware, and non-sm based cards can successfully handle n processes without any problem noticed. but for DNIe, I need some way to centralize all SM task in a single process/thread I am not very familiar with PKCS/11 and even less with OpenSC's implementation. But why don't you store the needed SM-data in the card's private data? This way each card handle has it's own SM context and could access the card with different SM parameters (if supported). If you think about sharing an SM context between different card handles, I think this is not a good idea. This would require you to establish an other mechanism to verify if access is allowed other than using the smart card. Such relaying is in general not a good idea. If you need to do it anyway, you could simply copy the SM context (the card's private data) to an other card handle. I'm thinking on a sort of SM daemon to take care on apdu encoding/decoding Please have a look at victor's repository http://www.opensc-project.org/svn/opensc/branches/vtarasov/opensc-sm.trunk/ He uses relaying to a distant entity to encode/decode SM APDUs. This sounds pretty much like what you have in mind. Greets, Frank. pgpx6rQRJbw2l.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging and concurrent access to card
El jue, 17-02-2011 a las 16:50 +0100, Frank Morgner escribió: On Monday, February 14 at 12:22PM, jons...@terra.es wrote: In the testing process of OpenDNIe I've found a problem related with concurrent access to opensc-pkcs11 library. (from a previous mail from Douglas) Does the card impose some CKA_ALWAYS_AUTHENTICATE restriction, such as the PIN must be presented before each crypto operation for some private key, with no intervening operations? Yes: DNIe enforces user authentication before any access to any object stored in card) In short: as DNIe can only handle one SM at a time (no virtual channel support), there is no (known) way to get concurrent pkcs11 access This feature makes unusable most of signing applets commonly used in many official sites Afaik opensc-pkcs11 is thread/process aware, and non-sm based cards can successfully handle n processes without any problem noticed. but for DNIe, I need some way to centralize all SM task in a single process/thread I am not very familiar with PKCS/11 and even less with OpenSC's implementation. But why don't you store the needed SM-data in the card's private data? This way each card handle has it's own SM context and could access the card with different SM parameters (if supported). Sorry I can't: AFAIK DNIe is read only, at least at user level Ideally, virtual channels should be used, but not enought documentation on card to make sure that DNIe supports them. Need to test... So cannot store sm context in card If you think about sharing an SM context between different card handles, I think this is not a good idea. This would require you to establish an other mechanism to verify if access is allowed other than using the smart card. Such relaying is in general not a good idea. If you need to do it anyway, you could simply copy the SM context (the card's private data) to an other card handle. I know. I was thinking on a SM daemon connected to opensc by mean of Unix Domain sockets (that can handle user permissions byself) to assure that only one user can access to encoding daemon. But this solution is not portable to Windows I'm thinking on a sort of SM daemon to take care on apdu encoding/decoding Please have a look at victor's repository http://www.opensc-project.org/svn/opensc/branches/vtarasov/opensc-sm.trunk/ He uses relaying to a distant entity to encode/decode SM APDUs. This sounds pretty much like what you have in mind. I'll take a look. Actually I know about 4 different approaches - Use virtual channels. But need to test for feature availability on DNIe card - Handle SM channel at pcsc -or ccid- level. (too complicated for me) - Find a way to share sm context to all applications that concurrently try to access the card - Convince every one to stop using signing applets, and just work with Firefox's crypto.signText() funcion :-). But this does still makes collide firefox with other apps (ie: openoffice) ¿Ideas? BTW. Martin told me about trying to find a portable, simple, no external libraries dependent way to ask user for PIN or Signature Confirmation as a previous task for DNIe integration into OpenSC Mainstream. Anyone working on this? Volunteers? :-) Juan Antonio smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Secure Messaging and concurrent access to card
In the testing process of OpenDNIe I've found a problem related with concurrent access to opensc-pkcs11 library. In short: as DNIe can only handle one SM at a time (no virtual channel support), there is no (known) way to get concurrent pkcs11 access This feature makes unusable most of signing applets commonly used in many official sites Afaik opensc-pkcs11 is thread/process aware, and non-sm based cards can successfully handle n processes without any problem noticed. but for DNIe, I need some way to centralize all SM task in a single process/thread I'm thinking on a sort of SM daemon to take care on apdu encoding/decoding What do you feel on this approach? btw, most of cryptoapplet jarfiles I know can handle access to card by mean of CSP, PKCS#11 and NSS interfaces. Can you confirm me that selecting NSS as interface instead pkcs#11 would solve this problem ? Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging and concurrent access to card
On 2/14/2011 5:22 AM, jons...@terra.es wrote: In the testing process of OpenDNIe I've found a problem related with concurrent access to opensc-pkcs11 library. In short: as DNIe can only handle one SM at a time (no virtual channel support), there is no (known) way to get concurrent pkcs11 access The next question would be, how long does the PKC#11 libraries have to keep the SM connected to the card? If the PKCS#11 opened a SM connection to the card, did some processing, like caching certificates, then drop the SM connection, some other application could then do the same. (I am not familiar with the DNIe cards.) So is this a problem with the OpenSC implementation of a SM to these cards? This feature makes unusable most of signing applets commonly used in many official sites Does the card impose some CKA_ALWAYS_AUTHENTICATE restriction, such as the PIN must be presented before each crypto operation for some private key, with no intervening operations? Afaik opensc-pkcs11 is thread/process aware, and non-sm based cards can successfully handle n processes without any problem noticed. but for DNIe, I need some way to centralize all SM task in a single process/thread I'm thinking on a sort of SM daemon to take care on apdu encoding/decoding What do you feel on this approach? What are the security implications in the daemon approach? Did the card developers define the SM to avoid separate processes from accessing a card? How would you protect access to the card on a multi-user system? btw, most of cryptoapplet jarfiles I know can handle access to card by mean of CSP, PKCS#11 and NSS interfaces. Can you confirm me that selecting NSS as interface instead pkcs#11 would solve this problem ? I don't thing NSS would help. AFAIK it is a set of libraries used by an application. Applications can share the databases, but the security devices are PKCS#11 modules, so the problem till goes back to PKCS#11. You can use pkcs11-spy as security device, to see what is going on. Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Secure Messaging IPR Situation
According to several sources Secure Messaging in smart cards is a veritable mine-field of patents. /a ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging IPR Situation
Hi Anders, Please give links to a) patents b) previous troubles in EU. On 10/04/2010, Anders Rundgren anders.rundg...@telia.com wrote: According to several sources Secure Messaging in smart cards is a veritable mine-field of patents. /a ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Sent from my mobile device Martin Paljak http://martin.paljak.pri.ee GSM:+3725156495 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging IPR Situation
Martin Paljak wrote: Hi Anders, Please give links to a) patents b) previous troubles in EU. Would love to but the people who brought the message represent companies with IP interests in this so they wanted to scare me from continuing to work on my take of Secure Messaging. Anyway, IPR should be specified in the ETSI/IEC standard which I don't have since I find it appalling *paying* for an open standard. Anders On 10/04/2010, Anders Rundgren anders.rundg...@telia.com wrote: According to several sources Secure Messaging in smart cards is a veritable mine-field of patents. /a ___ 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] Secure Messaging - How?
Andreas Jellinghaus wrote: Am Dienstag 06 April 2010 10:04:00 schrieb Anders Rundgren: OpenSC will get Secure Messaging some day it seems based on the Wiki. What I don't understand is how you are supposed to use Secure Messaging since it works on the APDU-level which is invisible from PKCS #11. I'm no expert, but I guess you need a card driver and profile that is designed to work with secure messaging from ground up. No idea how well PKCS#15 helps here. With some other cards you only read a chip serial number or number given to the card (e.g. issuer serial number), and then start secure messaging based on a key issued to the card. not sure if PKCS#15 has any way to implement something like that. I'm still curious about the applications that OpenSC target with SM. One application seem to be limiting access to ACL-controlled data on the card (biometrics, health records, etc) which IMO is fairly uninteresting since ISO/EIC has defined a new middleware framework for that purpose which I think is the foundation for the German e-card as well. A more generally applicable use of SM is for provisioning cards because currently you can't actually see the difference of keys generated outside of a card or inside of it. Although you are supposed to trust the middleware for doing the right thing, I believe this model is broken (you should trust middleware but not *blindly*), and some kind of SM is probably going to be standard some day. At least that is what the GlobalPlatform people say. GlobalPlatform is currently in a transition phase from using shared secrets to using PKI for on-card pre-provisioned keys. SCP10 is the ETSI name of the PKI-version of SM. Anders ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging - How?
Anders Rundgren wrote: OpenSC will get Secure Messaging some day it seems based on the Wiki. What I don't understand is how you are supposed to use Secure Messaging since it works on the APDU-level which is invisible from PKCS #11. It'll be implemented at the libopensc level. In ideal case, the PKCS#11 level is not conscious of the secure transport layer (STL) presence. (For a while, in my 'concept proof' implementation, I use a few PKCS#11 API extensions.) STL is used when it's imposed to use by operation's ACL. For a while I consider the ACLs that require the SM, External Authentication, PINs and its combinations . (Another possible, more simple implementation, is to secure the all APDUs at the 'send_apdu' level, just before reader-transmit. ) When ACL demands STL, the appropriate callbacks from the dynamically loadable SM module is used to initialize and execute secure transaction. This deviation from the normal processing takes place at the libopensc level . There two types of this SM loadable module: 'local' -- has direct access to the keysets, mostly used for the tests; 'distant' -- communicates with some distant entity that is capable to securize an APDU or to generate secured one. Anders Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov viktor.tara...@opentrust.com ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging - How?
Am Dienstag 06 April 2010 10:04:00 schrieb Anders Rundgren: OpenSC will get Secure Messaging some day it seems based on the Wiki. What I don't understand is how you are supposed to use Secure Messaging since it works on the APDU-level which is invisible from PKCS #11. I'm no expert, but I guess you need a card driver and profile that is designed to work with secure messaging from ground up. No idea how well PKCS#15 helps here. With some other cards you only read a chip serial number or number given to the card (e.g. issuer serial number), and then start secure messaging based on a key issued to the card. not sure if PKCS#15 has any way to implement something like that. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging
Hello Markus, Markus Schatzl schrieb: Hello, I'd be interested if somebody here has practical experience with Secure Messaging modes in general and would be so kind to answer a few questions: Yes, we have. See [1] / IsoSecureChannel class for how that works. In authentic as well as in combined mode, the use of symmetric ciphers seems to be the standard approach. To migitate simple MITM techniques, at least one keypair must be already integrated into ROM/EEPROM at the production/personalization stage and kept secret. I assume you mean protection of integrity and confidentiality. As a result, SM can only be used with designated terminals from a single emitting instance (or partner organizations) that have knowledge about this secret key. This defeats interoperability as a whole and reminds me to the infamous security by obscurity solutions popular in former decades. Are there any practical attempts to negotiate keys for SM by use of public keys? Yes, there is. Google for the e-SignK / CWA 14890 draft CEN standard. This describes secure messaging based on a shared secret key or using a hybrid scheme with card verifiable certificates (CVCs) (all based on ISO 7816-4). That is the procedure used by several smart card applications (eGK, ECC). What is the impact in terms of computation time for encrypted transfer at the moment, compared to a plain transmission? (Last info: x4) Depends on the card, but x4 seems realistic. Plain signature functionality is neither time-critical and generally uses basic facilities available on nearly every token. As digital signatures slowly gain acceptance outside specialized applications, are there any ambitions to secure the card-to-terminal communication by default? This is what is called trusted-channel and can be found in CWA 14890 for electronic signature applications in an untrusted environment. Isn't it urgently necessary to use ad-hoc interoperable security routines in the light of the legal status of digital signatures within the EU? That is what standards are for ;-) Andreas [1] www.openscdp.org/scsh3/index.html -- -CardContact Software System Consulting |.## ##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'## ##'| Phone +49 171 8334920 -http://www.cardcontact.de ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Secure Messaging
On Thu, Apr 05, 2007 at 10:03:51PM +0200, Roberto Resoli wrote: Are there any practical attempts to negotiate keys for SM by use of public keys? As someone noted in another reply, there is another very interesting CWA: in 14890-1 (Chapter 8, Device authentication), different schemes are proposed for SM, using symmetric key and using asymmetric one. With the asymmetric scheme, no prior knowledge of a secret key is necessary. The Swedish way with NIDEL is to allow personalization only through qualified partners who can match a card against an identity. A PIN#3 is used for a special key pair used to authenticate the card to the partner, over the internet or in person. //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] secure messaging with OpenSC
Andreas Jellinghaus a écrit : I like the idea of adding secure messagin! but in general: I think it would be nice to be able to encrypt all communication. think of contactless smart cards, I don't want data like the certificate go over the air unencrypted for privacy reasons. Hello, Updated SM patch to OpenSC, submitted into the svn/files/trunk/contrib, now includes the possibility to encrypt all communication. When encrypting all communication the SM initialized in sc_connect(). SM transform procedure is called at the APDU transmit level. It receives APDU in clear and returns it in securized form. In attachement there is the part of this patch that concerns the OpenSC common files. Kind wishes, Viktor. opensc-0.11.1.trunk.20061204-sm-common.patch.tgz Description: GNU Unix tar archive ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] secure messaging with OpenSC
Andreas Jellinghaus a écrit : Hi Viktor, I like the idea of adding secure messagin! but in general: I think it would be nice to be able to encrypt all communication. think of contactless smart cards, I don't want data like the certificate go over the air unencrypted for privacy reasons. Ok, it can be done at APDU transmit level, as Nils suggested. I'll think about it. Key-set can be placed locally: into opensc.conf or into the loadable module. Rather, I supposed, that SC midlleware do not know the card's key-set. SM_server (or entity that know key-set) is an integral part of the Smart Card Manager, that in its turn is coupled with PKI. The cards key-sets are stored (or generated with some master key stored ) somewhere in secure place (cryptobox, other smartcard, ...). So, the intention was to reduce the requests to SM_server and encrypt only the sensible exchanges. about the code: why add it as loadable module? if you have cards where the secure messaging details are under NDA that is ok. still it might be easier for all of us if you had a private opensc version with that patched in, rather than us loading modules. For me it seemed more flexible: in one case you place the key-set localy, in other case the key-set is on a distant server. The OpenSC library is the same, the difference is in a relatively small module. Also, with the loadable module there not so much changes to the OpenSC common part. also the patch adds a sm subdirectory, but does not include any files in that dir. so we can't compile/test it. personally I would prefer to keep all files in one directory (the libopensc/ libpkcs15init split for example is something we now regret, didn't get us much except complexity). It can be moved to tools or to the contribution. For me essential is that OpenSC API gives the possibility to implement at least on the card driver level. - secured APDUs are generated by some external SM_server (in my case it's HTTPS server). OpenSC access SM_server via the SM_module. SM_module to be used is defined in opensc.conf and is loaded during the sc_context initialization. why that? if you want a server to send commands to the card, that could be done much easier without using opensc on the client at all - a simple openct or pcsc app could do that. The to use SM inside the normal pkcs15 or pkcs11 sessions, and to hide (as far as possible) the SM specifities from these levels. it is ok for you to do that, but I wonder if other people will want that as well - whether it makes sence to have this in the generic code we ship? That's why I posted it. I would like to get know if there is an interest to SM, and how the people are currently use it. IMHO, implementation of loadable module has little impact to the common OpenSC part. Then each card driver decides for its own if it will use SM . Current trunk version of libopensc/card-oberthur.c contains (in comments) the SM specific procedures. Full patch (too voluminous for this mail) contains SM_server tool to generate secured APDUs, and SM_module implementations. I guess for the general use it might be nicer to have everything build into opensc, without external modules and external server. still if we find a scenario where other people will want that too, we can think of adding it. but normal users will not want to install a webserver to initialized a oberthur card with secure messaging ... I do not propose to include external server. I propose extention to API, that makes possible using of SM via the loadable module. If there will be an interest, part of SM procedures, currently included in card-oberthur.c, can be generalized into the separate file in libopensc. In the full patch there are examples of the loadable modules, library that contains the procedures of the GlobalPlatform SM processing and command line tool that helps generate secured APDUs. we could merge a generic secure messaging into opensc, and offer the webserver / rpc / ... code as patch in the contrib directory and see if people want to use it? sure, would be extra work to maintain, but I would prefer not to merge it till we get feedback (adds a lot of complexity most people won't need). can you put up a full diff somewhere? either post it to the list, attach it to a new bug, or commit it to https://www.opensc-project.org/svn/files/trunk/contrib ? contrib/opensc-0.11.1.trunk.20061204-sm.patch.tgz It's the full patch for opensc-0.11.1/trunk of 2006.12.04 . Thanks, Andreas p.s. sorry for answering this late. currently I have next to no time for opensc. Thank you, kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] secure messaging with OpenSC
Hi Viktor, I like the idea of adding secure messagin! but in general: I think it would be nice to be able to encrypt all communication. think of contactless smart cards, I don't want data like the certificate go over the air unencrypted for privacy reasons. about the code: why add it as loadable module? if you have cards where the secure messaging details are under NDA that is ok. still it might be easier for all of us if you had a private opensc version with that patched in, rather than us loading modules. also the patch adds a sm subdirectory, but does not include any files in that dir. so we can't compile/test it. personally I would prefer to keep all files in one directory (the libopensc/ libpkcs15init split for example is something we now regret, didn't get us much except complexity). - secured APDUs are generated by some external SM_server (in my case it's HTTPS server). OpenSC access SM_server via the SM_module. SM_module to be used is defined in opensc.conf and is loaded during the sc_context initialization. why that? if you want a server to send commands to the card, that could be done much easier without using opensc on the client at all - a simple openct or pcsc app could do that. it is ok for you to do that, but I wonder if other people will want that as well - whether it makes sence to have this in the generic code we ship? Current trunk version of libopensc/card-oberthur.c contains (in comments) the SM specific procedures. Full patch (too voluminous for this mail) contains SM_server tool to generate secured APDUs, and SM_module implementations. I guess for the general use it might be nicer to have everything build into opensc, without external modules and external server. still if we find a scenario where other people will want that too, we can think of adding it. but normal users will not want to install a webserver to initialized a oberthur card with secure messaging ... we could merge a generic secure messaging into opensc, and offer the webserver / rpc / ... code as patch in the contrib directory and see if people want to use it? sure, would be extra work to maintain, but I would prefer not to merge it till we get feedback (adds a lot of complexity most people won't need). can you put up a full diff somewhere? either post it to the list, attach it to a new bug, or commit it to https://www.opensc-project.org/svn/files/trunk/contrib ? Thanks, Andreas p.s. sorry for answering this late. currently I have next to no time for opensc. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] secure messaging with OpenSC
Hello, I would like to discuss an extension for the libopensc API, that implements secure messaging. In the attachment there is the patch to the common OpenSC part. The full patch was tested with Oberthur card. (Java card, secure messaging is conform to GlobalPlatform .) The main headlines are: - secure messaging (SM) is used only for APDUs that really need it: secure channel initialized just before, and closed immeadiatly after. - secured APDUs are generated by some external SM_server (in my case it's HTTPS server). OpenSC access SM_server via the SM_module. SM_module to be used is defined in opensc.conf and is loaded during the sc_context initialization. - SM_module exports three functions: initialize(), get_apdus() and finalize(): first one is to get the host challenge; second is to get the secured APDUs; last one is to return the confirmation. - libopensc card driver use cache of the curent EF's and DF's FCIs and detects the moment when SM has to be used. - APDUs processing is deviated to the SM procedures at the level of libopensc commands (not at the APDU transmission level) -- key_generation, key_import, pin_unblock, binary_write. Current trunk version of libopensc/card-oberthur.c contains (in comments) the SM specific procedures. Full patch (too voluminous for this mail) contains SM_server tool to generate secured APDUs, and SM_module implementations. It would be nice to hear your opinions, kind wishes, Viktor. opensc-0.11.1.trunk.20061204-sm-common.patch.tgz Description: GNU Unix tar archive ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
