Re: [opensc-devel] OpenSC changes to support non RSA public keys in Certificates, public and private keys
As outlined below, in a note from 10/6, changes were committed (r4805) today, with slight modifications. o sc_pkcs15_pubkey_from_cert was moved from pkcs15-pubkey.c to pkcs15-cert.c, and now calls parse_x509_cert. It no longer depends on OpenSSL, I can now easily work with more then RSA keys. The OpenSSL version was only written to work with RSA. o sc_pkcs15_cert now has a pointer to a sc_pkcs15_pubkey, rather then having the structure contained with in it. This allows the sc_pkcs15_pubkey to be easily extracted from the sc_pkcs15_cert and used on its own. o sc_pkcs15_pubkey now has a pointer to an sc_algorthim_id. This then allows for any algorithm parameters to bew passed along. o parse_x509_cert will now save the algorithm and any parameters in the sc_algorithm_id, and save this in the sc_pkcs15_pubkey. o sc_pkcs15_pubkey_from_cert and one location in pkcs15-framework.c can now extract the sc_pkcs15_pubkey from a certificate by coping the pointer and setting the pointer in the sc_pkcs15_cert to NULL. o Various free routines for the sc_algorithm_id, sc_pkcs15_pubkey and sc_pkcs15_cert now take care of the cleanup of these structures. On 10/6/2010 11:10 AM, Douglas E. Engert wrote: > One of the operations I need for the PIV card is to get the public > key from the certificate, as pubkey needs to be emulated for thes cards. > OpenSC has more then one way to do this, but only RSA keys are currently > supported. > > ./pkcs15-pubkey.c has sc_pkcs15_pubkey_from_cert, but this relies on > OpenSSL, and even then only supports RSA. > > pkcs15-cert.c has the parse_x509_cert which does not need OpenSSL, > but only works with RSA, and embeds the pubkey in the cert structure. > > (There is also the sc_pkcs15_pubkey_from_prvkey that supports RSA > and DSA and looks incomplete for GOSTR3410.) > > I need RSA, ECDSA and ECDH for PIV. > > The main problem with the pubkey from cert routines is that > they skip any algorithm parameters. RFC 3279 and RFC 5787 define > what these should look like for RSA, DSA, DH, KEA, ECDSA and ECDH. > > RSA has no parameters and is an ASN.1 NULL > > ECDSA and ECDH have a choice of ecParameters (a sequence of > a lot of stuff) or namedCurve object identifier or an ANS.1 NULL. > > DSA has either no parameter or a sequence of three integers p, q, and g. > > You can read about the others in the RFCs. (I am not sure what gostr3410 > is doing, but it looks like it is a sequence of stuff.) > > The sc_asn1_decode_algorithm_id does know how to get the algorithm ID, > and to call selected routines to decode any aditional parameters, and > to save the information in the sc_algorithm_id params pointer and to free > the params. > > PKCS#11 has for public keys: > >RSA: CKA_MODULUS, CKA_MODULUS_BITS, CKA_PUBLIC_EXPONENT. >DSA: CKA_PRIME, CKA_SUBPRIME, CKA_VASE AND CKA_VALUE. >ECDSA: CKA_ECDSA_PARAMS (DER encoded), CKA_EC_POINT(DER encoded). > > (PKCS#11 2.30 has definitions for GOSTR) > > PROPOSAL: > > I would like to do the following to cleanup some of the duplication: > > Replace with non OpenSSL code, that would > use the sc_asn1_decode_algorithm_id, and other code from parse_x509_cert > to get the algorithm, its parameter, and the pubkey. > > parse_x509_cert would call sc_pkcs15_pubkey_from_cert. > > The sc_pubkey would contain an sc_algorithm_id (or a pointer to one.) > > The sc_pkcs15_pubkey_rsa would not change, but the > sc_pkcs15_pubkey_dsa would change, as the DSA parameters are now > in the sc_algorithm_id parameters. > > The processing of the goostr3410 looks like it not completed, > as the algorithm parameters where never copied to the > sc_pkcs15_pubkey_gostr3410. So very little would need to change. > as the parameters would be in the sc_algrithm_id that is part > of the sc_pubkey. > > The sc_pkcs15_cert rather then having a sc_pkcs15_pubkey, would > have a pointer to one. > > > Using pointers rather then embedding the algorithm and pubkey in > other structure would allow one to parts a certificate, and copy > the pubkey pointer then free the certificate. > > IMPLEMENTATION: > > These changes could be made in stages, with the structure/pointer > changes made first and continue to work with RSA. Then the EC, DSA, > and additional GOSTR changes could be made later. > > SIDE NOTES: > The NIST 800-78 specs say the PIV only has to support two named curves, > one at 256, and one at 384, so I could just look at the size of the key, > and skip much of this stuff, but in the long run other cards might start > to support EC using other curves, so eventually this will be needed. > > Thoughts? > -- Douglas E. Engert 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
Re: [opensc-devel] OpenSC with or???without?OpenSSL?-???What???is?the?direction?
Frank Morgner wrote: > Hi! > > On Tuesday, October 12 at 10:33AM, Viktor TARASOV wrote: > > 1. There is no kind of abstraction in the current SM code. At the > moment every card driver implements its own version of secure > messaging. > >> SM is not implemented by card driver, but the separate SM procedures. >> These procedures implement two kind of SM and are linked into the >> external loadable module. >> Actually the 'local' version of SM module is commited -- this module >> have an access to the keysets or KMC (defined in opensc.conf). >> This 'local' version have an interest for testing and, probably, for >> contactless cards and the using of the 'virtual reader' that allows >> 'remote card control'. >> > > This aproach sounds indeed more flexible than I thought it was. Does it > mean that you can choose between multiple keys for encryption/decryption > or can you also choose between multiple algorithms for > encryption/decryption/authentication/keyagreement? > Multiple keysets concern rather the card IAS/ECC, where, for example, 'unblock PIN, 'create Sign key', 'update internal PKCS#15 structure', can be protected by the different keysets. > This leads to duplicated code. For example, what I saw > at the first glance is that every card driver implements bitpadding. > > >> Can you illustrate your thesis by the references to the source lines, >> please? >> Once more, there is two kind of SM, each represented by one card. >> > > Bitpadding is done here: sm-global-platform.c:222,250 sm-iasecc.c:450,92 > > Also ASN.1 encoding looks similar. But if there are two different > standards, where one of them does not include the other, this might be > OK. > OK, thanks. > In my implementation I am trying to separate encoding of a SM > message (which is for the nPA defined by ISO 7816-4 section 6) and > the actual cryptography. I described the process here for my SM > wrapper, sm_transmit_apdu, > https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace/sm.h > Adopting my aproach on the other hand would mean a rewrite of all > other card drivers with SM. > > >> Your approach (or similar) is declared in the future intentions of OpenSC. >> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/apdu.c#L383 >> This approach means securization of the APDUs at the 'apdu-transmit' level >> and, sure, one day it will be implemented in OpenSC. >> > > >> (By the way, for the card that you are using, does all of the ISO >> commands can be protected by SM? >> In your source I do not found the filtering for such a commands.) >> > > Yes, once the SM channel is established, everything else is encrypted. > That's why I need to do it at the transmit-level. (For the key agreement > see EstablishPACEChannel in > https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace.c) > Not all cards allow using of SM for all the commands. Example 'SELECT FILE', 'GET CHALLENGE' for Oberthur's AuthentIC. That's why, I think that general implementation 'sm-apdu-transmit' should use somewhere the card specific filter. >> What is actually implemented is the securization at the 'libopensc' level. >> Here, in a difference to the previous mode, SM is activated only when >> it's needed (according to the ACLs of the operation that is going to be >> executed). >> This approach allows the card objects to be protected by multiple keysets. >> It also allows to reduce the charge of the 'external SM securisation >> entity', that have an access to the keysets and can perform securisation >> of APDUs. >> > > Correct me if I am wrong, but isn't the apdu-transmit-aproach the more > flexible one. Meaning that you can do local and on demand SM with it. > There is no 'demand SM'. OpenSC can be configurated to use SM in a transparent for the application manner. Then everything depends on the where your keysets are. If they are local -- OpenSC is configurated to load 'local' SM module. If your keysets are distant -- OpenSC uses 'distant' module, that communicates with the distans entity to get secured APDUs, Also entire of card middleware and application (OpenSC, OpenSSL&engineOpenSC, ...) can be replaced to the distant entity to be closer to your keysets and to the confidential data (keys, unblock codes, ...) . In this case 'virtual reader' is used. > And in addition you can pass every command from the user through a SM > channel. This brings me to a more general question: Why developing in a > separate branch? > Because some experience is needed to be accumulated, to settle down the approach and concepts, with your help and the help of the other interested persons. SM implementation is rather heavy intervention into the common part of OpenSC. There are a lot of different cards that needs to be tested for non-regression. Also in this bra
Re: [opensc-devel] OpenSC with or???without?OpenSSL?-???What???is?the?direction?
Hi! On Tuesday, October 12 at 10:33AM, Viktor TARASOV wrote: > >>> 1. There is no kind of abstraction in the current SM code. At the > >>> moment every card driver implements its own version of secure > >>> messaging. > > SM is not implemented by card driver, but the separate SM procedures. > These procedures implement two kind of SM and are linked into the > external loadable module. > Actually the 'local' version of SM module is commited -- this module > have an access to the keysets or KMC (defined in opensc.conf). > This 'local' version have an interest for testing and, probably, for > contactless cards and the using of the 'virtual reader' that allows > 'remote card control'. This aproach sounds indeed more flexible than I thought it was. Does it mean that you can choose between multiple keys for encryption/decryption or can you also choose between multiple algorithms for encryption/decryption/authentication/keyagreement? > >>> This leads to duplicated code. For example, what I saw > >>> at the first glance is that every card driver implements bitpadding. > >>> > Can you illustrate your thesis by the references to the source lines, > please? > Once more, there is two kind of SM, each represented by one card. Bitpadding is done here: sm-global-platform.c:222,250 sm-iasecc.c:450,92 Also ASN.1 encoding looks similar. But if there are two different standards, where one of them does not include the other, this might be OK. > >>> In my implementation I am trying to separate encoding of a SM > >>> message (which is for the nPA defined by ISO 7816-4 section 6) and > >>> the actual cryptography. I described the process here for my SM > >>> wrapper, sm_transmit_apdu, > >>> https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace/sm.h > >>> Adopting my aproach on the other hand would mean a rewrite of all > >>> other card drivers with SM. > >>> > > Your approach (or similar) is declared in the future intentions of OpenSC. > http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/apdu.c#L383 > This approach means securization of the APDUs at the 'apdu-transmit' level > and, sure, one day it will be implemented in OpenSC. > (By the way, for the card that you are using, does all of the ISO > commands can be protected by SM? > In your source I do not found the filtering for such a commands.) Yes, once the SM channel is established, everything else is encrypted. That's why I need to do it at the transmit-level. (For the key agreement see EstablishPACEChannel in https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace.c) > What is actually implemented is the securization at the 'libopensc' level. > Here, in a difference to the previous mode, SM is activated only when > it's needed (according to the ACLs of the operation that is going to be > executed). > This approach allows the card objects to be protected by multiple keysets. > It also allows to reduce the charge of the 'external SM securisation > entity', that have an access to the keysets and can perform securisation > of APDUs. Correct me if I am wrong, but isn't the apdu-transmit-aproach the more flexible one. Meaning that you can do local and on demand SM with it. And in addition you can pass every command from the user through a SM channel. This brings me to a more general question: Why developing in a separate branch? Greets, Frank. pgpKkrUwazWDi.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] OpenSC with or without OpenSSL -???What???is?the?direction?
Hello, Frank Morgner wrote: What are the limitations in OpenSC? >>> 1. There is no kind of abstraction in the current SM code. At the >>> moment every card driver implements its own version of secure >>> messaging. SM is not implemented by card driver, but the separate SM procedures. These procedures implement two kind of SM and are linked into the external loadable module. Actually the 'local' version of SM module is commited -- this module have an access to the keysets or KMC (defined in opensc.conf). This 'local' version have an interest for testing and, probably, for contactless cards and the using of the 'virtual reader' that allows 'remote card control'. >>> This leads to duplicated code. For example, what I saw >>> at the first glance is that every card driver implements bitpadding. >>> Can you illustrate your thesis by the references to the source lines, please? Once more, there is two kind of SM, each represented by one card. >>> In my implementation I am trying to separate encoding of a SM >>> message (which is for the nPA defined by ISO 7816-4 section 6) and >>> the actual cryptography. I described the process here for my SM >>> wrapper, sm_transmit_apdu, >>> https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace/sm.h >>> Adopting my aproach on the other hand would mean a rewrite of all >>> other card drivers with SM. >>> Your approach (or similar) is declared in the future intentions of OpenSC. http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/apdu.c#L383 This approach means securization of the APDUs at the 'apdu-transmit' level and, sure, one day it will be implemented in OpenSC. (By the way, for the card that you are using, does all of the ISO commands can be protected by SM? In your source I do not found the filtering for such a commands.) What is actually implemented is the securization at the 'libopensc' level. Here, in a difference to the previous mode, SM is activated only when it's needed (according to the ACLs of the operation that is going to be executed). This approach allows the card objects to be protected by multiple keysets. It also allows to reduce the charge of the 'external SM securisation entity', that have an access to the keysets and can perform securisation of APDUs. >> There are not many card drivers with SM support (yet) and generally SM >> support is a somewhat moving target. Do you have practical suggestions >> for improvement? >> > > From what I have seen, message padding, the construction of the > authentication data and encoding of the SM APDU data is conform to > ISO-7916 for all SM cards, which opensc already supports. Actually are supported SM defined in Global Platform SCP01 and SM defined in ISO-7816 in it's IAS/ECC version. The first one is represented by Oberthur's AuthentIC v3 card, and second by IAS/ECC cards. > What I am > suggesting (and implemented in my SM implementation, see above) is that > these operations could be done by an abstraction layer that sits between > user input and the card specific configuration and implementations for > ciphers and authentication. So the card initializes some flags for which > parts should be included in the authentication data or the SM APDU data > and sets call back functions for the actual encrypting/decrypting or > authentication of buffers. > > >>> 2. I suggested a change for handling SCardControl (ticket 235), >>> because there are readers with special capabilities for the nPA. But >>> even this simple suggestion (and simple patch) was not accepted. >>> >> IMHO #236 does not make much sense, whereas #237 does. The patch in >> #237 makes perfect sense and will be included soon as it gets used by >> some piece of code in OpenSC, like one of the three tools. Until >> somebody finds the time to re-write those places to make use of it, it >> is not good to add a feature and then forget it and end up having dead >> code around. There's plenty of that already. >> >> Feel free to change some of those tools to make use of the new >> function to speed up the inclusion of your patch. >> >> >> >>> Currently the discussion is stuck at the argument that OpenSC is for >>> PKCS#15, which the nPA doesn't support. >>> >> The thing with standards is that you can call anything a standard, but >> nobody cares unless it is actually used by more than a few vendors >> (remember the XML thing by Microsoft?). PKCS#15 has been the best >> option this far (and has been around for quite some time), but >> nevertheless, it is not perfect and certainly not the only one. But it >> helps to try to "think like PKCS#15" when working with OpenSC. >> >> OpenSC aims for two targets: to provide tools for personalizing smart >> cards, and to provide tools and interfaces to use either those cards >> personalized by OpenSC or cards that get emulated to a PKCS#15-ish >> structure. OpenSC has settled on PKCS#15 for cards that it wr
