Re: [opensc-devel] OpenSC with or without OpenSSL - What is the direction?
Hello Martin,
On Tue, 2010-10-05 at 18:04 +0300, Martin Paljak wrote:
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engert deeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
Interesting. RSA-PKCS-KEY-PAIR-GEN should have nothing to do with
OpenSSL.
look at [1], there you can find the reason. To fix this, one could mess
around with:
SC_ALGORITHM_ONBOARD_KEY_GEN
SC_CARD_FLAG_ONBOARD_KEY_GEN
SC_CARDCTL_XXX_GENERATE_KEY
Some examples:
muscle: card-flags |= SC_CARD_FLAG_ONBOARD_KEY_GEN;
setcos: card-caps |= SC_CARD_FLAG_ONBOARD_KEY_GEN;
lots:flags |= SC_ALGORITHM_ONBOARD_KEY_GEN;
_sc_card_add_rsa_alg(card, 512, flags, 0);
_sc_card_add_rsa_alg(card, 1024, flags, 0);
Additionally it seems, that there is no way to generate keys in hardware
form within pkcs11. Only pkcs15init/pkcs15-*.c can do so.
Regards
Andre
[1]
http://www.opensc-project.org/opensc/browser/trunk/src/pkcs11/framework-pkcs15.c#L3142
___
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 writes (but there's some code by Viktor that allows PKCS#15 initialization emulation-virtualization as well, don't know that so well yet),
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, On Oct 10, 2010, at 10:07 PM, Frank Morgner 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. This leads to duplicated code. For example, what I saw at the first glance is that every card driver implements bitpadding. 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. 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. 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. Isn't it what Viktor is doing? With the addition of adding remote encryptors?. Currently the discussion is stuck at the argument that OpenSC is for PKCS#15, which the nPA doesn't support. If the internal PKCS#15 layer is not sufficient to represent the (crypto) objects on your card, please point out the deficiencies so that it could be improved. The process for the new German identity card is complicated and doesn't involve PKCS#15 at all: First EAC, then the terminal is authenticated, and then the chip authenticates to the terminal. If this all was successful, the data is send encrypted to the terminal. But the data itself is not signed by a CA or simalar, the correctness of the data is solely based on the 3 step protocol. I am not too familiar with OpenSC PKCS#15 layer, but maybe I can have a further look, when/if there is more support for the nPA. So nPA is a travel document style electronic password with no crypto capabilities itself? OpenSC is focusing on cryptographic smart cards. If there are no keys to be used via PKCS#11 or Tokend or something similar, it can't be integrated with the rest of OpenSC like a casual driver. be If there's only data to be read from the card, it would make sense to add it as a tool that brings in some from libopensc and some from a very fresh / patched version of OpenSSL (I see from OpenSSL list that this depends on Brainpool curves support in OpenSSL) to read out the data. Maybe improving eidenv tool to make the data available to applications. Big patches are always harder to integrate, there is more discussion about it and so on. That's why it's more unlikely to be accepted. For example, supporting the nPA would not only require to change OpenSC, but it would also mean that you would have to use a patched version of OpenSSL. The whole code we (at the Humboldt University, Berlin) have written to support the nPA contains something like 8k (5k in OpenSSL, 3k for the card itself) lines of code. So what I meant is that this is unrealistic to be integrated, I did not mean that you don't appreciate the work and participation of others. I would not be that pessimistic :) You have not shown a possible patch that would be needed for nPA in OpenSC so it is hard to say. I've tried to look at the vsmartcard project but as I don't have the hardware it makes little sense to me. And it does not seem try to integrate into OpenSC, in a way that it would be possible to extract a patch. Second, support for the nPA is not very important since it lacks PKCS#15. If it has crypto capabilities, it is useful. It is hard if not impossible to objectively measure the importance of a card against others. As long as there's a developer and a maintainer and/or users for a card, the card becomes relevant. I think the best measure is the activity of users and developers for a given card. If you want to use nPA cards with/via OpenSC just let us know what needs to be improved or changed in OpenSC to make it happen. Well, in Germany everyone will get this card who applies for an identity card after the 1st of november. So very soon millions of people will have such a card since in Germany you must possess at least an identity card or a passport. So there *is* relevance. But there are at the moment only a hand full of developers since the card is not out in the public. So what needs to be changed? I have an
Re: [opensc-devel] OpenSC with or without OpenSSL -What is the direction?
( As Spanish authorities finally said No-no to allow re-licensing GPL'd DNIe code for inclusion in OpenSC, me an some others have started a written-from-scratch OpenSC DNIe module. We are next to start writing sm code... ) At lun, 11-10-2010 a las 09:56 +0300, Martin Paljak wrote: [] 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. Afaik For Spanish DNIe that is true too 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. I'm coding something similar for DNIe: a sort of virtual channel that hides SM operations to the rest of OpenSC code [...] So what needs to be changed? I have an implementation up and running which is based on OpenSC. It should be easily integrated as card driver. But my implementation uses also the SM abstraction I described above. This abstraction layer of course only implements what is needed for the nPA. So if integration in OpenSC is wanted, the question is whether to rewrite the SM layer to match the card-centric aproach which is used at the moment in OpenSC, whether to rewrite the SM card drivers of OpenSC to use the abstraction or to use the already running nPA-tool and not integrate it into libopensc. Can you prepare two patches against current trunk: the card driver and the related secure messaging code? Yes, please :-) smime.p7s Description: S/MIME cryptographic signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC with or without OpenSSL -???What???is?the?direction?
Hi! 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. This leads to duplicated code. For example, what I saw at the first glance is that every card driver implements bitpadding. 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. 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. 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 writes (but there's some code by Viktor that allows PKCS#15 initialization emulation-virtualization as well, don't know that so well yet), but it is not and should not be too hard to emulate a PKCS#15-like structure for read-only crypto cards on top of almost anything. If the internal PKCS#15 layer is not sufficient to represent the (crypto) objects on your card, please point out the deficiencies so that it could be improved. The process for the new German identity card is complicated and doesn't involve PKCS#15 at all: First EAC, then the terminal is authenticated, and then the chip authenticates to the terminal. If this all was successful, the data is send encrypted to the terminal. But the data itself is not signed by a CA or simalar, the correctness of the data is solely based on the 3 step protocol. I am not too familiar with OpenSC PKCS#15 layer, but maybe I can have a further look, when/if there is more support for the nPA. So I suppose two things. First big patches are not welcome, or at least they are unlikely to be accepted. I'm very sorry if you feel like this. I did not find the time to reply any sooner, nor could anyone else reply to your e-mail as it was in the moderation queue. If you are in doubt, I'd like to assure you that there is no discrimination nor acceptance barriers except for common sense and best practices in OpenSC. This has also been described in the OpenSC development policy [1], to keep it very transparent to anyone who wishes to improve and work with OpenSC. I must admit that my statement above was quite harsh. Big patches are always harder to integrate, there is more discussion about it and so on. That's why it's more unlikely to be accepted. For example, supporting the nPA would not only require to change OpenSC, but it would also mean that you would have to use a patched version of OpenSSL. The whole code we (at the Humboldt University, Berlin)
Re: [opensc-devel] OpenSC with or without OpenSSL - What is the direction?
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engert deeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
Interesting. RSA-PKCS-KEY-PAIR-GEN should have nothing to do with
OpenSSL. Also, OpenSC (and most smart cards) currently only do
properly keys up to 2048 bits.
opensc.h has #define SC_CARD_CAP_RSA_2048, JavaCard 2.2.2 has only
KeyBuilder.LENGTH_RSA_2048
The suggested key sizes apparently only double over years, so 4096
seems more popular than 3072 for some reason :)
___
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?
On 10/5/2010 10:04 AM, Martin Paljak wrote:
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engertdeeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
Interesting. RSA-PKCS-KEY-PAIR-GEN should have nothing to do with
OpenSSL.
Looks like pkcs11/framework-pkcs15.c line 1348 has #ifdef ENABLE_OPENSSL
that will add this mech.
Also, OpenSC (and most smart cards) currently only do
properly keys up to 2048 bits.
The NIST 800-73-1 (March 2006) specs called for the PIV applet to
optionally support 3072 bit keys. So that is what the driver says
is available. Since the ordinary user can not generate a key on the
card, and the only keys that can be used are tied to certificates,
the actual size of the key is determined from the certificate.
opensc.h has #define SC_CARD_CAP_RSA_2048, JavaCard 2.2.2 has only
KeyBuilder.LENGTH_RSA_2048
The suggested key sizes apparently only double over years, so 4096
seems more popular than 3072 for some reason :)
NIST 800-78-2 February 2010, has a nice chart of required key sizes
and 1024 bit keys are to be gone by 12/31/2013, in all cases. There
is no mention of 3072 bit keys, and I don't think there are any
PIV cards that support them today, but i don't think it hurt to say
the card supports 3072.
But 800-78-2 is also pushing for ECDSA p-256 and p-384 for certificates,
and ECDH for Key Management. So the trend appears to be to use EC keys
rather then larger and larger RSA keys.
--
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
Re: [opensc-devel] OpenSC with or without OpenSSL -???What???is?the?direction?
On Thursday, September 30 at 12:02PM, Martin Paljak wrote: The code (also needs a patched version of OpenSSL) is much more extensive than other SM cards in opensc-sm.trunk, that's why I doubt that there is a chance of integrating the nPA into OpenSC. 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. This leads to duplicated code. For example, what I saw at the first glance is that every card driver implements bitpadding. 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. 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. Currently the discussion is stuck at the argument that OpenSC is for PKCS#15, which the nPA doesn't support. So I suppose two things. First big patches are not welcome, or at least they are unlikely to be accepted. Second, support for the nPA is not very important since it lacks PKCS#15. Greets, Frank. pgpxo5JOmzQdD.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?
On Tue, Oct 5, 2010 at 18:56, Douglas E. Engert deeng...@anl.gov wrote:
On 10/5/2010 10:04 AM, Martin Paljak wrote:
Hello
On Thu, Sep 30, 2010 at 18:07, Douglas E. Engertdeeng...@anl.gov wrote:
With OpenSSL-1.0.0a pkcs11-tool -M shows:
Supported mechanisms:
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,3072}, keypairgen
Without OPenSSL, pkc11-tool -M
RSA-PKCS, keySize={1024,3072}, sign, unwrap, decrypt
Note that verify is not listed without OpenSSL, as the
pkcs11/openssl.c adds the OpenSSL hash and verify functions.
Interesting. RSA-PKCS-KEY-PAIR-GEN should have nothing to do with
OpenSSL.
Looks like pkcs11/framework-pkcs15.c line 1348 has #ifdef ENABLE_OPENSSL
that will add this mech.
That's something that needs to be looked into at some stage.
Also, OpenSC (and most smart cards) currently only do
properly keys up to 2048 bits.
The NIST 800-73-1 (March 2006) specs called for the PIV applet to
optionally support 3072 bit keys. So that is what the driver says
is available. Since the ordinary user can not generate a key on the
card, and the only keys that can be used are tied to certificates,
the actual size of the key is determined from the certificate.
It would be nice to support 3072b keys. I have a CryptoStick (OpenPGP)
that support such keys but I've not yet got around to trying to use it
with OpenSC.
NIST 800-78-2 February 2010, has a nice chart of required key sizes
and 1024 bit keys are to be gone by 12/31/2013, in all cases. There
is no mention of 3072 bit keys, and I don't think there are any
PIV cards that support them today, but i don't think it hurt to say
the card supports 3072.
But 800-78-2 is also pushing for ECDSA p-256 and p-384 for certificates,
and ECDH for Key Management. So the trend appears to be to use EC keys
rather then larger and larger RSA keys.
Correct. But I think it will take a few years before EC is as
widespread and available as RSA is today.
___
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, you're not subscribed to opensc-devel mailing list, which is not a good idea if you want to send mails here. I rescued the e-mail from moderation because it is probably of interest to others as well (unlike the viagra and your wife photos attached ones :) but you really should subscribe.) Sorry for being slow on this, I was sick at home and mostly offline last week. On Oct 1, 2010, at 8:36 AM, Frank Morgner wrote: On Thursday, September 30 at 12:02PM, Martin Paljak wrote: The code (also needs a patched version of OpenSSL) is much more extensive than other SM cards in opensc-sm.trunk, that's why I doubt that there is a chance of integrating the nPA into OpenSC. 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. This leads to duplicated code. For example, what I saw at the first glance is that every card driver implements bitpadding. 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. 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? 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 writes (but there's some code by Viktor that allows PKCS#15 initialization emulation-virtualization as well, don't know that so well yet), but it is not and should not be too hard to emulate a PKCS#15-like structure for read-only crypto cards on top of almost anything. If the internal PKCS#15 layer is not sufficient to represent the (crypto) objects on your card, please point out the deficiencies so that it could be improved. So I suppose two things. First big patches are not welcome, or at least they are unlikely to be accepted. I'm very sorry if you feel like this. I did not find the time to reply any sooner, nor could anyone else reply to your e-mail as it was in the moderation queue. If you are in doubt, I'd like to assure you that there is no discrimination nor acceptance barriers except for common sense and best practices in OpenSC. This has also been described in the OpenSC development policy [1], to keep it very transparent to anyone who wishes to improve and work with OpenSC. Second, support for the nPA is not very important since it lacks PKCS#15. If it has crypto capabilities, it is useful. It is hard if not impossible to objectively measure the importance of a card against others. As long as there's a developer and a maintainer and/or users for a card, the card becomes relevant. I think the best measure is the activity of users and developers for a given card. If you want to use nPA cards with/via OpenSC just let us know what needs to be improved or changed in OpenSC to make it happen. [1] http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Sourcecodeversioning Cheers, -- @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] OpenSC with or without OpenSSL - What is the direction?
Hi, Andre Zepezauer wrote: in my opinion the usage of OpenSSL in libopensc.so should be removed altogether. If cryptography is needed by some cards (i.e. for initialisation/personalisation), then this should be done by dedicated tools. CardOS is a good example. It requires encrypted APDU:s for the delete_MF and create_MF commands. This is done by cardos-tool, which has to be executed only before personalisation. Looking at the code of entersafe, gpk and oberthur I came to the conclusion, that a similar approach could work for these drivers too. If parsing of certificates is the reason for using OpenSSL, then the missing functionality of pkcs15-cert.c should be determined and corresponding tickets should be created. As for me, libopensc.so, and especially pkcs15init, should keep the access to the cryptography. It concerns parsing of certificates: to get public key, subject DN, issuer DN, serial, (it's in the x509CertificateAttributes). The same about RSA parsing: get public key, get modulus. SHA1 to calculate the object IDs of the Mozilla and rfc2459 styles. Symmetric cryptography is needed for Secure Messaging . Kind Regards Andre Zepezauer Kind wishes, Viktor Tarasov. ___ 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] OpenSC with or without OpenSSL - What is the direction?
Hello, On Sep 27, 2010, at 11:58 PM, Douglas E. Engert wrote: There has been a effort to be able to build OpenSC without the use of OpenSSL. Yet there is newer code that keeps creeping in to the trunk that requires OpenSSL. This has been discussed several times during past few years. There was the idea of keeping the core libopensc OpenSSL free, for various reasons. As the main function of OpenSC has turned out to be PKCS#11/crypto cards and libopensc is AFAIK not used for anything else, I'm not sure it is any longer relevant. Yes, OpenSSL support is not required by configure and probably OpenSC can be built without OpenSSL, but there is no nice list about what will break if you do it. The OpenSSL dependent code can be divided into 3 areas: (1) Code that tries to get some information from a certificate, such as the public key, or the basic constraints. For example sc_pkcs15_pubkey_from_cert in pkcs15-pubkey.c Much of this code appears to have been added because parse_x509_cert in pkcs15-cert.c does not do a good enough job in supporting more then RSA, and does not parse options like basic constraint that one card driver needs. Except for GOST, AFAIK OpenSC really only support algorithms other than RSA. I don't have cards with DSA but the code for DSA seems to not be complete. (2) Code that deals with symmetric keys for example in, pkcs15-wrap.c It is not clear if the project wants to add native crypto to OpenSC code or continue to use OpenSSL, or some other package. (The gost code appears to introduce a dependency on the gost external engine, to do its crypto.) Any Secure Messaging or some card initialization that needs to authenticate to the card, needs this. GOST is implemented as an engine inside OpenSSL. I've not used the password-protected key import feature, but I think this is conflicting with only hardware crypto princile as well. Either the key has native support from the card or it should be stored as a data object and handled by the application as a generic PEM file. pkcs15-wrap should be removed in the spirit of not automagically generating private/secret keys in software. Looking at the code, only pkcs15-crypt tool seems to use the pkcs15-wrap functions to decrypt the password protected keyblob. (3) Old code that is not being used. p15card-helper.c for example in not used at all. It was introduced by a third party for use with the PIV card, but is no longer used, and in my option could be removed. Unused code should be removed. I bring this up as I am interested in adding ECC support (with named curves only) to OpenSC for the PIV card. No ECC crypto needs to be done, but support for getting the EC pubkey from a cert and saving a pubkey generated by the card is needed. (As an attempt to not require OpenSSL, last week I committed changes that allowed the PIV driver to be built without OpenSSL. OpenSSL is still needed for card administration, as a 3DES Decrypt is still needed. But the administration code and piv-tool are not used by the ordinary users. This type of code falls into (2)) So what is the direction? (A) Continue to use OpenSSL but only in the most limited cases? It would be nice to be able to switch implementations but until there is no real requirement for this, OpenSSL can be used. It is, after all, an industry standard in some sense. (B) Try and stamp it out, but this would then require adding some crypto for symmetric keys and maybe other hash functions? Re-implementing is not an option, IMO. (C) Embrace it, and use its crypto, key and cert structures and simplify OpenSC code? You mean use OpenSC structures inside current sc_* structures? (D) Use some other crypto package? If there's anyone interested in reaping the code and hiding the common cases behind an adapter API (sc_crypto_something) and THEN implement the necessary hash and public key operations for a library other than OpenSSL, it could be done. But changing OpenSSL to something else without a good justification is not reasonable at the moment. Just a more careful selection of what and how is included from OpenSSL could be done. -- @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] OpenSC with or without OpenSSL - What is the direction?
On 9/30/2010 3:56 AM, Martin Paljak wrote: Hello, On Sep 27, 2010, at 11:58 PM, Douglas E. Engert wrote: There has been a effort to be able to build OpenSC without the use of OpenSSL. Yet there is newer code that keeps creeping in to the trunk that requires OpenSSL. This has been discussed several times during past few years. There was the idea of keeping the core libopensc OpenSSL free, for various reasons. I believe one was size, i.e. someone wanted to use OpenSC on some phone or PDA? As the main function of OpenSC has turned out to be PKCS#11/crypto cards and libopensc is AFAIK not used for anything else, I'm not sure it is any longer relevant. Yes, OpenSSL support is not required by configure and probably OpenSC can be built without OpenSSL, but there is no nice list about what will break if you do it. Yes it does build and the PIC card works. Having spent the last few weeks looking at OpenSSL and EC it looks like all the software crypto code is only used for initialization and thus not needed for end users. But SM could change that. The closest thing to a list is the pkcs11-tool -M, with the card of your choice. So it might be a good idea for developers to test their cards without OpenSSL, just to see if it is required or not. It may depend on the calling application, more then OpenSC, if the application depends on OpenSC supporting some hash or verify function. But any good application should implement hash and verify on its own. The OpenSSL dependent code can be divided into 3 areas: (1) Code that tries to get some information from a certificate, such as the public key, or the basic constraints. For example sc_pkcs15_pubkey_from_cert in pkcs15-pubkey.c Much of this code appears to have been added because parse_x509_cert in pkcs15-cert.c does not do a good enough job in supporting more then RSA, and does not parse options like basic constraint that one card driver needs. Except for GOST, AFAIK OpenSC really only support algorithms other than RSA. I don't have cards with DSA but the code for DSA seems to not be complete. Yes, that is what I am seeing. To add EC or a minimal EC with only named curves, the GOST code is a good example of what is needed. The main thing I need is to get the pub key from the cert and I think I can do that, and maybe add DSA support at the same time without using OpenSSL. (I dont have any DSA cards) (2) Code that deals with symmetric keys for example in, pkcs15-wrap.c It is not clear if the project wants to add native crypto to OpenSC code or continue to use OpenSSL, or some other package. (The gost code appears to introduce a dependency on the gost external engine, to do its crypto.) Any Secure Messaging or some card initialization that needs to authenticate to the card, needs this. GOST is implemented as an engine inside OpenSSL. I've not used the password-protected key import feature, but I think this is conflicting with only hardware crypto princile as well. Either the key has native support from the card or it should be stored as a data object and handled by the application as a generic PEM file. pkcs15-wrap should be removed in the spirit of not automagically generating private/secret keys in software. Looking at the code, only pkcs15-crypt tool seems to use the pkcs15-wrap functions to decrypt the password protected keyblob. (3) Old code that is not being used. p15card-helper.c for example in not used at all. It was introduced by a third party for use with the PIV card, but is no longer used, and in my option could be removed. Unused code should be removed. I agree, as it might lead some new developer to try and use it. Should there be a separate thread to ask if there are any objections? I bring this up as I am interested in adding ECC support (with named curves only) to OpenSC for the PIV card. No ECC crypto needs to be done, but support for getting the EC pubkey from a cert and saving a pubkey generated by the card is needed. (As an attempt to not require OpenSSL, last week I committed changes that allowed the PIV driver to be built without OpenSSL. OpenSSL is still needed for card administration, as a 3DES Decrypt is still needed. But the administration code and piv-tool are not used by the ordinary users. This type of code falls into (2)) So what is the direction? (A) Continue to use OpenSSL but only in the most limited cases? It would be nice to be able to switch implementations but until there is no real requirement for this, OpenSSL can be used. It is, after all, an industry standard in some sense. I have noticed that Debian (any maybe others) have started to convert to using GnuTLS in some packages like OpenLDAP, for licening reasons. (I spent two much time tracking down bugs and differences in nss and ldap because of this change.) So I would not suggest it at this time, but it is an option. (B) Try and stamp
Re: [opensc-devel] OpenSC with or without OpenSSL - What is the direction?
Douglas E. Engert wrote: I have noticed that Debian (any maybe others) have started to convert to using GnuTLS in some packages like OpenLDAP, for licening reasons. (I spent two much time tracking down bugs and differences in nss and ldap because of this change.) So I would not suggest it at this time, but it is an option. The GnuTLS API is horribly weird and not really documented in any way. Don't replace OpenSSL with it. (D) Use some other crypto package? If there's anyone interested in reaping the code and hiding the common cases behind an adapter API (sc_crypto_something) and THEN implement the necessary hash and public key operations for a library other than OpenSSL, it could be done. But changing OpenSSL to something else without a good justification is not reasonable at the moment. I strongly agree with Martin here. I think it would be very nice to abstract crypto in OpenSC so that providers other than OpenSSL could be used. For embedded small things there are several crypto libraries to pick and choose from. Maybe some code could even be included in OpenSC itself, but I don't see it as a high priority. As an example of what I mean, I've included Tom St Denis' SHA256 code in a MySQL UDF. Very simple: http://git.stuge.se/?p=mysql-sha256.git;a=blob;f=sha256.c //Peter ___ 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 Douglas, in my opinion the usage of OpenSSL in libopensc.so should be removed altogether. If cryptography is needed by some cards (i.e. for initialisation/personalisation), then this should be done by dedicated tools. CardOS is a good example. It requires encrypted APDU:s for the delete_MF and create_MF commands. This is done by cardos-tool, which has to be executed only before personalisation. Looking at the code of entersafe, gpk and oberthur I came to the conclusion, that a similar approach could work for these drivers too. If parsing of certificates is the reason for using OpenSSL, then the missing functionality of pkcs15-cert.c should be determined and corresponding tickets should be created. Kind Regards Andre Zepezauer ___ 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?
On 9/29/2010 9:51 AM, Andre Zepezauer wrote: Hello Douglas, in my opinion the usage of OpenSSL in libopensc.so should be removed altogether. If cryptography is needed by some cards (i.e. for ), then this should be done by dedicated tools. CardOS is a good example. It requires encrypted APDU:s for the delete_MF and create_MF commands. This is done by cardos-tool, which has to be executed only before personalisation. Looking at the code of entersafe, gpk and oberthur I came to the conclusion, that a similar approach could work for these drivers too. I agree. The PIV card only needs 3DES for initialization/personalization today. The piv-tool was designed to allow for initializing test cards, with the intent that production cards would be issued by card management stations run by others as the NIST standards only cover a few of the commands needed for initialization, leaving the rest up to the card vendors. (i.e. one can generate a key ipair on the card, but you can not load a private key on the card.) Thus the ordinary user would not require OpenSSL. If parsing of certificates is the reason for using OpenSSL, then the missing functionality of pkcs15-cert.c should be determined and corresponding tickets should be created. What has happened as some card driver authors have found it easier to just use OpenSSL, and have added routines like: sc_pkcs15_pubkey_from_cert into pkcs11-pubkey.c Because the parse_x509_cert only works with RSA. But to get this code replaced, will take the will of the community to get this done. Kind Regards Andre Zepezauer -- 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
Re: [opensc-devel] OpenSC with or without OpenSSL - What is the direction?
On Wed, 2010-09-29 at 13:35 -0500, Douglas E. Engert wrote: On 9/29/2010 9:51 AM, Andre Zepezauer wrote: Hello Douglas, in my opinion the usage of OpenSSL in libopensc.so should be removed altogether. If cryptography is needed by some cards (i.e. for ), then this should be done by dedicated tools. CardOS is a good example. It requires encrypted APDU:s for the delete_MF and create_MF commands. This is done by cardos-tool, which has to be executed only before personalisation. Looking at the code of entersafe, gpk and oberthur I came to the conclusion, that a similar approach could work for these drivers too. I agree. The PIV card only needs 3DES for initialization/personalization today. The piv-tool was designed to allow for initializing test cards, with the intent that production cards would be issued by card management stations run by others as the NIST standards only cover a few of the commands needed for initialization, leaving the rest up to the card vendors. (i.e. one can generate a key ipair on the card, but you can not load a private key on the card.) Thus the ordinary user would not require OpenSSL. If parsing of certificates is the reason for using OpenSSL, then the missing functionality of pkcs15-cert.c should be determined and corresponding tickets should be created. What has happened as some card driver authors have found it easier to just use OpenSSL, and have added routines like: sc_pkcs15_pubkey_from_cert into pkcs11-pubkey.c Because the parse_x509_cert only works with RSA. But to get this code replaced, will take the will of the community to get this done. I don't think so, because the function sc_pkcs15_pubkey_from_cert is called only at pkcs15init/pkcs15-lib.c#L2030 The same holds for sc_pkcs15_pubkey_from_prvkey, which is called at pkcs15init/pkcs15-lib.c#L2036 and nowhere else. That shows (at least to me), that these two functions belonging to the tools section of OpenSC and should be placed there. ___ 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?
On 9/29/2010 3:05 PM, Andre Zepezauer wrote:
On Wed, 2010-09-29 at 13:35 -0500, Douglas E. Engert wrote:
On 9/29/2010 9:51 AM, Andre Zepezauer wrote:
Hello Douglas,
in my opinion the usage of OpenSSL in libopensc.so should be removed
altogether. If cryptography is needed by some cards (i.e. for
), then this should be done by dedicated
tools. CardOS is a good example. It requires encrypted APDU:s for the
delete_MF and create_MF commands. This is done by cardos-tool, which has
to be executed only before personalisation. Looking at the code of
entersafe, gpk and oberthur I came to the conclusion, that a similar
approach could work for these drivers too.
I agree. The PIV card only needs 3DES for initialization/personalization
today. The piv-tool was designed to allow for initializing test cards, with
the intent that production cards would be issued by card management stations
run by others as the NIST standards only cover a few of the commands needed
for initialization, leaving the rest up to the card vendors. (i.e. one can
generate a key ipair on the card, but you can not load a private key on the
card.) Thus the ordinary user would not require OpenSSL.
If parsing of certificates is the reason for using OpenSSL, then the
missing functionality of pkcs15-cert.c should be determined and
corresponding tickets should be created.
What has happened as some card driver authors have found it easier to
just use OpenSSL, and have added routines like: sc_pkcs15_pubkey_from_cert
into pkcs11-pubkey.c Because the parse_x509_cert only works with RSA.
But to get this code replaced, will take the will of the community
to get this done.
I don't think so, because the function sc_pkcs15_pubkey_from_cert is
called only at pkcs15init/pkcs15-lib.c#L2030
The same holds for sc_pkcs15_pubkey_from_prvkey, which is called at
pkcs15init/pkcs15-lib.c#L2036 and nowhere else.
That shows (at least to me), that these two functions belonging to the
tools section of OpenSC and should be placed there.
But parse_x509_cert also get the pubkey from a cert. So why are there two
routines? Because parse_x509_cert only works with RSA? Where as
sc_pkcs15_pubkey_from_cert could easily work with more the RSA.
So we have duplicate code, using different methods. We could do a better
and implement sc_pkcs15_pubkey_from_cert without OpenSSL, and use it from
parse_x509_cert.
I am interested in expanding OpenSC to work with EC keys, with at least
named-curves. (The OID of the curve is the parameter.) parse_x509_cert does
not obtain the algorithm parameters, which for RSA are null, and the
pkcs15-piv.c needs to get the public key from the cert in normal use. This
will require a modified parse_x509_cert or sc_pkcs15_pubkey_from_cert.
(Since the PIV specs for EC only require the use of prime256v1 or secp384r1
so I could take a shortcut, and use the size of the point to get the curve,
but in the future, other cards may support EC for other curves or even explicit
parameters.) All the code for EC is in OpenSSL, making it very tempting
to just use OpenSSL.
The gostr3410 [1][2] algorithm is also based on EC, but has its own OID
{iso(1) member-body(2) ru(643) rans(2) cryptopro(2)} and requires parameters,
and it looks like the way it is used does not require parsing the cert to get
a public key so has not been added to parse_x509_cert.
Much of gost is in OpenSSL too, as a separate engine, and the pkcs11/openssl.c
introduces the use of many of the hash and verify functions from OpenSSL.
So getting OpenSSL out of OpenSC is looking like a big project.
[1] http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-00
[2] http://www.faqs.org/rfcs/rfc4357.html
--
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
Re: [opensc-devel] OpenSC with or without OpenSSL - What???is?the?direction?
in my opinion the usage of OpenSSL in libopensc.so should be removed altogether. If cryptography is needed by some cards (i.e. for initialisation/personalisation), then this should be done by dedicated tools. CardOS is a good example. It requires encrypted APDU:s for the delete_MF and create_MF commands. This is done by cardos-tool, which has to be executed only before personalisation. Looking at the code of entersafe, gpk and oberthur I came to the conclusion, that a similar approach could work for these drivers too. I disagree. It is the whole point of card drivers to implement card specific operations. SM and whatever needs encryption is such an operation. Using dedicated card specific tools contradicts OpenSC's currently used approach of using card drivers. If parsing of certificates is the reason for using OpenSSL, then the missing functionality of pkcs15-cert.c should be determined and corresponding tickets should be created. Why reinventing the wheel? The code of OpenSSL is better tested and more powerful. For example, OpenSC's ASN.1 encoding doesn't allow long tags, but OpenSSL does. If OpenSC wants to support new cards there really is the need of SM support. Since this requires cryptography, some cryptographic library is needed. I have written pace-tool which uses OpenSC and OpenSSL to connect to the new German identity card (nPA). It also uses elliptic curve cryptography which could be of interest for you, Douglas. https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard The code (also needs a patched version of OpenSSL) is much more extensive than other SM cards in opensc-sm.trunk, that's why I doubt that there is a chance of integrating the nPA into OpenSC. Greets, Frank. pgpqdM7INbDKt.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC with or without OpenSSL - What is the direction?
There has been a effort to be able to build OpenSC without the use of OpenSSL. Yet there is newer code that keeps creeping in to the trunk that requires OpenSSL. The OpenSSL dependent code can be divided into 3 areas: (1) Code that tries to get some information from a certificate, such as the public key, or the basic constraints. For example sc_pkcs15_pubkey_from_cert in pkcs15-pubkey.c Much of this code appears to have been added because parse_x509_cert in pkcs15-cert.c does not do a good enough job in supporting more then RSA, and does not parse options like basic constraint that one card driver needs. (2) Code that deals with symmetric keys for example in, pkcs15-wrap.c It is not clear if the project wants to add native crypto to OpenSC code or continue to use OpenSSL, or some other package. (The gost code appears to introduce a dependency on the gost external engine, to do its crypto.) Any Secure Messaging or some card initialization that needs to authenticate to the card, needs this. (3) Old code that is not being used. p15card-helper.c for example in not used at all. It was introduced by a third party for use with the PIV card, but is no longer used, and in my option could be removed. I bring this up as I am interested in adding ECC support (with named curves only) to OpenSC for the PIV card. No ECC crypto needs to be done, but support for getting the EC pubkey from a cert and saving a pubkey generated by the card is needed. (As an attempt to not require OpenSSL, last week I committed changes that allowed the PIV driver to be built without OpenSSL. OpenSSL is still needed for card administration, as a 3DES Decrypt is still needed. But the administration code and piv-tool are not used by the ordinary users. This type of code falls into (2)) So what is the direction? (A) Continue to use OpenSSL but only in the most limited cases? (B) Try and stamp it out, but this would then require adding some crypto for symmetric keys and maybe other hash functions? (C) Embrace it, and use its crypto, key and cert structures and simplify OpenSC code? (D) Use some other crypto package? -- 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
