[opensc-devel] add new public key algorithm (GOSTR3410)
Hello! I propose a patch for add GOST R 34.10-2001 algorithm (only PKCS#11 for the present). PKCS#11 and GOST: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf This patch is first step. If it OK, I'll do: - cleanup code - add support to tools (pkcs15-init pkcs15-tool pkcs11-tool) - add off-card GOSTR3410 keypair generation - add GOST R 34.11-94 (CKM_GOSTR3410) Patch for trunk revision 3743 attached. Could you please add it? Thanks opensc-trunk-r3743_gost3410.diff.bz2 Description: Binary data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to fix pkcs11 access with multiple PINs
2009/9/21 Andreas Jellinghaus : > Am Sonntag 20 September 2009 17:25:59 schrieb Martin Paljak: >> Hmm, that is an interesting idea. It would also have to include scconf >> which currently is distributed separately, but then again is also used >> by other software like pam_pkcs11 for example. > > yes, but don't they use a copy of the code or something? > oops, I wasn't aware we had libscconf.so.2 as standalone library. > hmm, not sure what is best for pam_pkcs11, but if there is only > one other user, why don't we make it internal too? pam_pkcs11 has its own copy of the scconf source code (with some minor differences). pam_pkcs11 does not use a libscconf.so.2 library. Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to fix pkcs11 access with multiple PINs
Am Montag 21 September 2009 10:24:05 schrieb Alon Bar-Lev: > You *CAN* use the OpenSSH PKCS#11 patch *WITHOUT* OpenSSH X.509 patch. sorry, I had forgotten about that. Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to fix pkcs11 access with multiple PINs
On Mon, Sep 21, 2009 at 11:08 AM, Andreas Jellinghaus wrote: > I wouldn't like to kill opensc support in openssh, unless we have a > lightwight patch to enable it with pkcs#11. (i.e. not a patch that > adds full x.509 stuff. I know you have one that does this, but for > me it's not simple enough, so I prefer a much easier system with > openssh). I cannot count the number of times I wrote this for you: You *CAN* use the OpenSSH PKCS#11 patch *WITHOUT* OpenSSH X.509 patch. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to fix pkcs11 access with multiple PINs
Hi everyone, On Sep 21, 2009, at 9:08, Andreas Jellinghaus wrote: > I wouldn't like to kill opensc support in openssh, unless we have a > lightwight patch to enable it with pkcs#11. (i.e. not a patch that > adds full x.509 stuff. I know you have one that does this, but for > me it's not simple enough, so I prefer a much easier system with > openssh). > > ah, one more issue: > what about our internal tools? > opensc-tool, opensc-explorer, pkcs15-init, etc.? > > they need to be able to use the internal api, and I doubt we can > rewrite > them to use pkcs11 only. (in fact we don't need to, pkcs11-tool > should be > able to do everything pkcs#11 has to offer). > So does OpenSC.tokend: zero:~ joao$ otool -L /root/OpenSC.tokend/Contents/MacOS/OpenSC /root/OpenSC.tokend/Contents/MacOS/OpenSC: /System/Library/Frameworks/PCSC.framework/Versions/A/PCSC (compatibility version 1.0.0, current version 36160.0.0) /System/Library/PrivateFrameworks/SecurityTokend.framework/Versions/A/ SecurityTokend (compatibility version 1.0.0, current version 36808.0.0) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 36910.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 550.0.0) /Library/OpenSC/lib/libopensc.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/OpenSC/lib/libpkcs15init.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/OpenSC/lib/libscconf.2.dylib (compatibility version 3.0.0, current version 3.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0) zero:~ joao$ Unless we modify it, of course :) Regards, João ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to fix pkcs11 access with multiple PINs
Am Montag 21 September 2009 08:43:16 schrieb Alon Bar-Lev: > On Sun, Sep 20, 2009 at 6:25 PM, Martin Paljak wrote: > > > not sure if the changes we have so far break ABI. but if we break ABI, > > > then I favor to merge libopensc, libpkcs15init and opensc-pcks11.so > > > into one library / shared object. > > > > Hmm, that is an interesting idea. It would also have to include scconf > > which currently is distributed separately, but then again is also used > > by other software like pam_pkcs11 for example. > > > > Alon, what do you think of it (from the build system POV) and do you > > think you have the interest and time to work on it? > > First, I like the modulation. It is much simpler to maintain modulated > piece of software. well, good maintenance should include clean interfaces between the modules and documenting the interfaces. we completely failed here, we have many symbold exported, but sometimes not enough, and we have no good api documentation, and in many parts the decission where something was implemented is not a good design, but simply historic development. also some designs are no longer important: for example I haven't heard of anyone trying to build opensc-pkcs11.so without support for pkcs15init, which was one reason to keep that code modular. also while it is possible in opens to have frameworks other than pkcs15, noone implemented one, and it is unlikely anyone ever will. > Second, it is a very bad idea to provide a PKCS#11 library with none > PKCS#11 exports. true. but the question is rather: keep some hack so openssh can be used with opensc, or remove everything except pkcs#11 symbols? I wouldn't like to kill opensc support in openssh, unless we have a lightwight patch to enable it with pkcs#11. (i.e. not a patch that adds full x.509 stuff. I know you have one that does this, but for me it's not simple enough, so I prefer a much easier system with openssh). ah, one more issue: what about our internal tools? opensc-tool, opensc-explorer, pkcs15-init, etc.? they need to be able to use the internal api, and I doubt we can rewrite them to use pkcs11 only. (in fact we don't need to, pkcs11-tool should be able to do everything pkcs#11 has to offer). so I think we are back to two binaries - libopensc.so and opensc-pkcs11.so - or more (keep scconf as standalone lib? keep pkcs15init as standalone lib?). > Merging between libopensc and libpkcs15init is making sense, but what > the benefit will be? > Anyway two options: > 1. Make the libpkcs15init internal library (.a) it will not be > distributed, but linked against executables. > 2. Merge libopensc and libpkcs15init into a single library. I favor 2. but without moving all code around, unless that really helps. Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to fix pkcs11 access with multiple PINs
Am Sonntag 20 September 2009 17:25:59 schrieb Martin Paljak: > Hmm, that is an interesting idea. It would also have to include scconf > which currently is distributed separately, but then again is also used > by other software like pam_pkcs11 for example. yes, but don't they use a copy of the code or something? oops, I wasn't aware we had libscconf.so.2 as standalone library. hmm, not sure what is best for pam_pkcs11, but if there is only one other user, why don't we make it internal too? after all scconf is neither well documented nor maintained nor has seen any development in years, so a static copy shouldn't make anything worse. from building pov I guess it won't be hard, we need either have make create a dir/libdir.a and then link all of them into opensc-pkcs11.so or create that one directly from dir/file.c files. > It can be a step-by-step move. We declare PKCS#11 as THE interface, > combine *.export files for compatibility, then gradually refine the > API and headers (which should then only be used by OpenSC tools) lets say, the question is not if we want to promote PKCS#11 (I think we all do), but if we want to break openssh support for opensc completely. we could keep the old api somehow exposed it we want openssh to keep working. I would favor that, as openssh is the most important app for me. > > * keep license LGPL 2.1+ or change to LGPL 3.0+? > > What are the differences and why? LGPL3 is a GPL3 spinoff, so it has tigher rules on patents etc. I don't think we need to switch, but if we want to, then a new major version is a good time to do that. > > * keep allowing drivers with no source or mandate changes > > to libopensc be LGPL'ed (or compatible)? > > I'm not an expert but to my understanding all libopensc modifications > that get distributed must come with source? no, only derived code needs to be published. for example changes to our code need to be published. but if you write a new driver on your own without using any driver as blue-print, then you have the option to keep your code proprietory and not publish it under LGPL. but if we remove the interface for loading plugin drivers and make most API internal, we make a statement that new drivers are also considered changes within the library and thus derived work, and we expect people to publish their code under LGPL. its similar to the kernel developers marking export symbols as GPL with the statement: if you use those symbols, you derive from the work we did creating the whole framework and thus we expect you to publish your code under GPL. well, I'm not a lawyer, but at least we can send signals if we continue to say "use the lib however you want, changes to non-core can be kept proprietory" or "any change within the lib is considered derived work and we want it to be published under LGPL." Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-user] Gemalto Classic TPC IM
Am Donnerstag 22 Mai 2008 15:42:19 schrieb Georges Bart:
> > I bought a card from gemalto (Classic TPC IM) and I've got some problem
> > to interact with it and opensc.
>
> I think your card is using the GemSafe v2 applet with a PKCS#15 mapping.
>
> I sent a patch last year to try to support this card in OpenSC.
> http://www.opensc-project.org/pipermail/opensc-user/2007-August/001958.html
>
> I attach a new version of the patch against trunk as of today and with
> corrections suggested by Andreas.
oops, this patch was ignored for some reason.
can everyone please review the patch?
unless some issue is found, I think we should
apply it.
I'm not 100% sure why the new function sc_pkcs15_read_file_key_ref is needed,
or if we can handle that some other way. but it's not a big deal if we mark
it "gemsave V2 workaround" and keep that change.
Regards, Andreas
Index: src/libopensc/ctx.c
===
--- src/libopensc/ctx.c (révision 3516)
+++ src/libopensc/ctx.c (copie de travail)
@@ -60,6 +60,7 @@ static const struct _sc_driver_entry int
{ "gpk",(void *(*)(void)) sc_get_gpk_driver },
#endif
{ "gemsafeV1", (void *(*)(void)) sc_get_gemsafeV1_driver },
+ { "gemsafeV2", (void *(*)(void)) sc_get_gemsafeV2_driver },
{ "miocos", (void *(*)(void)) sc_get_miocos_driver },
{ "mcrd", (void *(*)(void)) sc_get_mcrd_driver },
{ "asepcos",(void *(*)(void)) sc_get_asepcos_driver },
Index: src/libopensc/pkcs15-pubkey.c
===
--- src/libopensc/pkcs15-pubkey.c (révision 3516)
+++ src/libopensc/pkcs15-pubkey.c (copie de travail)
@@ -399,7 +399,11 @@ sc_pkcs15_read_pubkey(struct sc_pkcs15_c
}
info = (const struct sc_pkcs15_pubkey_info *) obj->data;
- r = sc_pkcs15_read_file(p15card, &info->path, &data, &len, NULL);
+ if (info->path.len)
+ r = sc_pkcs15_read_file(p15card, &info->path, &data, &len,
NULL);
+ else
+ r = sc_pkcs15_read_file_key_ref(p15card, info->key_reference,
&data, &len);
+
if (r < 0) {
sc_error(p15card->card->ctx, "Failed to read public key file.");
return r;
Index: src/libopensc/pkcs15.c
===
--- src/libopensc/pkcs15.c (révision 3516)
+++ src/libopensc/pkcs15.c (copie de travail)
@@ -867,8 +867,14 @@ __sc_pkcs15_search_objects(sc_pkcs15_car
/* Enumerate the DF's, so p15card->obj_list is
* populated. */
r = sc_pkcs15_parse_df(p15card, df);
- SC_TEST_RET(p15card->card->ctx, r, "DF parsing failed");
- df->enumerated = 1;
+ /* The DF is here but we can't read it yet */
+ if (r == SC_ERROR_SECURITY_STATUS_NOT_SATISFIED)
+ sc_do_log(p15card->card->ctx, SC_LOG_TYPE_DEBUG,
__FILE__, __LINE__, __FUNCTION__, "DF parsing failed");
+ else if (r < 0)
+ sc_do_log(p15card->card->ctx, SC_LOG_TYPE_ERROR,
__FILE__, __LINE__, __FUNCTION__, "%s: %s\n", "DF parsing failed",
sc_strerror(r)); \
+ else
+ /* r == SC_SUCCESS */
+ df->enumerated = 1;
}
/* And now loop over all objects */
@@ -1608,6 +1614,60 @@ int sc_pkcs15_parse_unusedspace(const u8
return 0;
}
+int sc_pkcs15_read_file_key_ref(struct sc_pkcs15_card *p15card,
+ int key_reference,
+ u8 **buf, size_t *buflen)
+{
+ u8 *data = NULL;
+ size_t len = 0;
+ int r;
+
+ assert(p15card != NULL && buf != NULL);
+
+ if (p15card->card->ctx->debug >= 1)
+ sc_debug(p15card->card->ctx, "called, key ref=%d\n",
key_reference);
+
+ r = -1; /* file state: not in cache */
+ /* if (p15card->opts.use_cache) {
+ r = sc_pkcs15_read_cached_file(p15card, path, &data, &len);
+ } */
+ if (r) {
+ unsigned char buffer[512];
+
+ r = sc_get_data(p15card->card, key_reference, buffer,
sizeof(buffer));
+ if (r < 0) {
+ free(data);
+ goto fail_unlock;
+ }
+
+ len = r;
+
+ data = (u8 *) malloc(len);
+ if (data == NULL) {
+ r = SC_ERROR_OUT_OF_MEMORY;
+ goto fail_unlock;
+ }
+ data[0] = 0x30;
+ data[1] = 0x82;
+ data[2] = 0x00;
+ data[3] = 0x8B;
+ data[4] = 0x02;
+ data[5] = 0x81;
+ data[6] = 0x81;
+ data[7] = 0x00;
+ memcpy(data+8, buffer+14, len-14);
+ data[0x88] = 0x02;
+ data[0x89] = 0x04;
+ mem
[opensc-devel] westcos_select_file and iso7816_select_file
Hello!
I propose a patch for src/libopensc/card-westcos.c if it's working.
src/libopensc/card-westcos.c:westcos_select_file:
309:case SC_PATH_TYPE_PATH:
apdu.p1 = 9;// Why is it needed? ("9" ?)
336:if (file_out != NULL) {
apdu.resp = buf;
apdu.resplen = sizeof(buf);
apdu.le = 255;
} else {
apdu.resplen = 0;
apdu.le = 0;
apdu.cse = SC_APDU_CASE_3_SHORT;
}
Is this correct? (See
http://www.opensc-project.org/opensc/changeset/3700/trunk/src/libopensc
and
http://www.opensc-project.org/pipermail/opensc-devel/2009-June/012280.html)
Patch for trunk revision 3741 attached.
Thanks
diff -u -r opensc-trunk-r3742/src/libopensc/card-westcos.c
opensc-trunk-r3742_new/src/libopensc/card-westcos.c
--- opensc-trunk-r3742/src/libopensc/card-westcos.c 2009-09-12
07:04:48.0 +0400
+++ opensc-trunk-r3742_new/src/libopensc/card-westcos.c 2009-09-21
11:11:15.0 +0400
@@ -280,100 +280,11 @@
static int westcos_select_file(sc_card_t * card, const sc_path_t * in_path,
sc_file_t ** file_out)
{
- sc_context_t *ctx;
- sc_apdu_t apdu;
- u8 buf[SC_MAX_APDU_BUFFER_SIZE];
- u8 pathbuf[SC_MAX_PATH_SIZE], *path = pathbuf;
- int r, pathlen;
- sc_file_t *file = NULL;
- priv_data_t *priv_data = NULL;
- if (card->ctx->debug >= 1)
- sc_debug(card->ctx, "westcos_select_file\n");
- if (card == NULL)
- return SC_ERROR_INVALID_ARGUMENTS;
- priv_data = (priv_data_t *) card->drv_data;
- priv_data->file_id = 0;
- ctx = card->ctx;
- memcpy(path, in_path->value, in_path->len);
- pathlen = (int)in_path->len;
- sc_format_apdu(card, &apdu, SC_APDU_CASE_4_SHORT, 0xA4, 0, 0);
- switch (in_path->type) {
- case SC_PATH_TYPE_FILE_ID:
- apdu.p1 = 0;
- if (pathlen != 2)
- return SC_ERROR_INVALID_ARGUMENTS;
- break;
- case SC_PATH_TYPE_DF_NAME:
- apdu.p1 = 4;
- break;
- case SC_PATH_TYPE_PATH:
- apdu.p1 = 9;
- if (pathlen == 2 && memcmp(path, "\x3F\x00", 2) == 0) {
- apdu.p1 = 0;
- }
+ priv_data_t *priv_data = (priv_data_t *) card->drv_data;
- else if (pathlen > 2 && memcmp(path, "\x3F\x00", 2) == 0) {
- apdu.p1 = 8;
- pathlen -= 2;
- memcpy(path, &in_path->value[2], pathlen);
- }
- break;
- case SC_PATH_TYPE_FROM_CURRENT:
- apdu.p1 = 9;
- break;
- case SC_PATH_TYPE_PARENT:
- apdu.p1 = 3;
- pathlen = 0;
- apdu.cse = SC_APDU_CASE_3_SHORT;
- break;
- default:
- return SC_ERROR_INVALID_ARGUMENTS;
- }
- apdu.p2 = 0;/* first record, return FCI */
- apdu.lc = pathlen;
- apdu.data = path;
- apdu.datalen = pathlen;
- if (file_out != NULL) {
- apdu.resp = buf;
- apdu.resplen = sizeof(buf);
- apdu.le = 255;
- } else {
- apdu.resplen = 0;
- apdu.le = 0;
- apdu.cse = SC_APDU_CASE_3_SHORT;
- }
- r = sc_transmit_apdu(card, &apdu);
- if (r)
- return (r);
- if (file_out == NULL) {
- if (apdu.sw1 == 0x61)
- return 0;
- return sc_check_sw(card, apdu.sw1, apdu.sw2);
- }
- r = sc_check_sw(card, apdu.sw1, apdu.sw2);
- if (r)
- return (r);
- switch (apdu.resp[0]) {
- case 0x6F:
- file = sc_file_new();
- if (file == NULL)
- return SC_ERROR_OUT_OF_MEMORY;
- file->path = *in_path;
- if (card->ops->process_fci == NULL) {
- sc_file_free(file);
- return SC_ERROR_NOT_SUPPORTED;
- }
- if (apdu.resp[1] <= apdu.resplen)
- card->ops->process_fci(card, file, apdu.resp + 2,
- apdu.resp[1]);
- *file_out = file;
- break;
- case 0x00: /* proprietary coding */
- return SC_ERROR_UNKNOWN_DATA_RECEIVED;
- default:
- return SC_ERROR_UNKNOWN_DATA_RECEIVED;
- }
- return 0;
+ assert(iso_ops && iso_ops->select_file);
+ priv_data->file_id = 0;
+ return iso_ops->select_file(card, in_path, file_out);
}
static int _westcos2opensc_ac(u8 flag)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
