Re: [opensc-devel] sc_ctx_detect_readers patch
On Feb 3, 2011, at 10:04 PM, Douglas E. Engert wrote: > I have updates #321 with a new version of the cardmod patch > and would like to start to commit it in pieces. > > Piece 1 is the attachment I sent on 1/28 as new.martin.patch > based on Martin's patch from 1/19. This was the patch that would > work for Brian. The main change is adding two parameters to all > the *_detect_readers routines. Martin's patch already required these > to be added in a number of places. > > Is there any objection to adding this patch now? I would consider using a new hook, like "use_reader" or "use_pcsc_parameters" to send the arguments to reader-pcsc.c and set the (pcsc, not cardmod) driver to "cardmod state". The reader operations API is by no means set in stone. Nor is there need to abstract it away too much, the usage pattern is known and the code path to implement it should be as simple as possible (sc_XXX wrapper that will not be used by any other reader driver, like sc_cancel and sc_wait_for_event are examples of "somewhat bad ideas". Yet it is a working pattern.) -- @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] sc_ctx_detect_readers patch
On Thu, 2011-02-03 at 15:55 -0600, Douglas E. Engert wrote: > > On 2/3/2011 3:14 PM, Andre Zepezauer wrote: > > On Thu, 2011-02-03 at 14:04 -0600, Douglas E. Engert wrote: > >> I have updates #321 with a new version of the cardmod patch > >> and would like to start to commit it in pieces. > >> > >> Piece 1 is the attachment I sent on 1/28 as new.martin.patch > >> based on Martin's patch from 1/19. This was the patch that would > >> work for Brian. The main change is adding two parameters to all > >> the *_detect_readers routines. Martin's patch already required these > >> to be added in a number of places. > >> > >> Is there any objection to adding this patch now? > > > > Yes, why you want to call 'sc_context_create()' altogether. There is not > > much functionality in it. So you could easily implement the required > > initialisation in 'CardAcquireContext()'. > > I disagree there is a lot of functionality in it. It main functions is to > read the config files, and other initialization needed by OpenSC, and that > is more then enough to justify calling it. I got it. The whole file ctx.c is basically one single function, that is scattered into a lot of small functions, which are mostly called once. The fact that most of these functions are 'static' makes it even more interesting. So, it seem that calling 'sc_context_create()' is really required. There is still the option to separate reader-pcsc and reader-cardmod. That this would be the best solution shows the following example: 1. A Mini-Driver doesn't need to detect readers at all. Thus it should define "driver->ops->detect_readers = NULL". That's the trick. 2. Looking at 'detect_readers' of the current driver looks like rocket science [1]. IMO there is something fundamentally wrong. Regards Andre [1] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/reader-pcsc.c#L1662 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] sc_ctx_detect_readers patch
> Its not a straight forward as you might think. Have you tried reading the 135 > page "Windows Smart Card Minidriver Specification"? > http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx At least in so far to get a picture of the workings. And my impression is, that all the state management of cards is handled by the framework and thus the reader-driver is only required to do I/O (i.e. send/receive APDU:s). BTW: The main handle in OpenSC is 'sc_pkcs15_card_t' and not 'sc_context_t'. In fact 'sc_context_t' is really unimportant. But sc_pkcs15_card_t holds all the operational state the is required to make things working. Have a look at VENDOR_SPECIFIC, there is only one OpenSC specific field needed. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] sc_ctx_detect_readers patch
On 2/3/2011 3:14 PM, Andre Zepezauer wrote: > On Thu, 2011-02-03 at 14:04 -0600, Douglas E. Engert wrote: >> I have updates #321 with a new version of the cardmod patch >> and would like to start to commit it in pieces. >> >> Piece 1 is the attachment I sent on 1/28 as new.martin.patch >> based on Martin's patch from 1/19. This was the patch that would >> work for Brian. The main change is adding two parameters to all >> the *_detect_readers routines. Martin's patch already required these >> to be added in a number of places. >> >> Is there any objection to adding this patch now? > > Yes, why you want to call 'sc_context_create()' altogether. There is not > much functionality in it. So you could easily implement the required > initialisation in 'CardAcquireContext()'. I disagree there is a lot of functionality in it. It main functions is to read the config files, and other initialization needed by OpenSC, and that is more then enough to justify calling it. I am starting from the cardmod code already in SVN listed as experimental, which has some bugs, and would not work with login. Having to duplicate sc_context_create was more then I wanted to do at this time. That could be another project in the future. > > Next point is reader-pcsc.c: Why do you belief that squeezing in a > second driver namely cardmod is a good idea? I don't. I am using the code already in SVN that duplicates much of reader-pcsc. The main difference in the cardmod and pcsc code it to use the handles provided by the BaseCSP rather then searching for readers and trying to find cards. > Why not implement a new one? Yes the code in cardmod code in reader-pcsc.c could be in a separate source file, or could even be added as if statements in the current pcsc code. > Read the documents provided by Microsoft. What do you think I have been doing?! How do you think the current cardmod code was developed?! > Most things are managed > by the CSP framework and therefore a reader-cardmod would be straight > forward consisting mostly of stub functions. > That is what the current cardmod.c is trying to do. francois.lebl...@cev-sa.com has done a nice job of implementing these "stubs" and had cardmod working for certutil. But he asked a few weeks ago why would cardmod did not work with login. So I got interested, I have an environment where I can use a smartcard to login to AD, and web servers that will accept smartcards for authentication. I have found a few bugs, and looked closer at how Windows uses it during login. Its not a straight forward as you might think. Have you tried reading the 135 page "Windows Smart Card Minidriver Specification"? http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx > To make things short: Not calling 'sc_context_create()' and implementing > a new reader-driver would make your proposal obsolete. > > Regards > Andre > > -- 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] emu
> Ok, now module loads... but fails on locating pkcs15 files,
> as rsc_pkcs15_make_absolute_path() removes "5015" on _every_
> file...
>
> FYI: I know about these paths:
>
> These are (afaik) standard locations:
> 3F00: DF Master.File
> 3F005015: DF PKCS15 App
> 3F0050155031: EF ODF
> 3F0050155032: EF Tokeninfo
> 3F0050155033: EF Unused
> 3F0050156000: EF AODF
> 3F0050156001: EF PRKDF
> 3F0050156002: EF PUKDF
> 3F0050156004: EF CDF
> 3F0050156005: EF DODF
>
> These are DNIe specific, addressed by above pkcs15 files,
> and shows the "relative path" problem
No problem. Remove that 'rsc_pkcs15_make_absolute_path()' hack and try
the attached file instead. If it isn't working, then send output of
"opensc-tool -s 00:A4:08:00:04:50:15:50:31:00 -s 00:B0:00:00:00".
#include
#include
#include "../config.h"
#include "libopensc/log.h"
#include "libopensc/asn1.h"
#include "libopensc/pkcs15.h"
/* Card driver related */
static
int match_card(struct sc_card *card)
{
/* Do card recognition here */
return 1;
}
/* Helper functions to get the pkcs15 stuff bound. */
static
int dump_ef(sc_card_t *card, const char *path, u8 *buf, size_t *buf_len) {
int rv;
sc_file_t *file = sc_file_new();
sc_format_path(path, &file->path);
sc_select_file(card, &file->path, &file);
if (file->size > *buf_len)
return SC_ERROR_BUFFER_TOO_SMALL;
rv = sc_read_binary(card, 0, buf, file->size, 0);
if (rv < 0)
return rv;
*buf_len = rv;
return SC_SUCCESS;
}
static const struct sc_asn1_entry c_asn1_odf[] = {
{ "privateKeys", SC_ASN1_STRUCT, SC_ASN1_CTX | 0 | SC_ASN1_CONS, 0, NULL, NULL },
{ "publicKeys", SC_ASN1_STRUCT, SC_ASN1_CTX | 1 | SC_ASN1_CONS, 0, NULL, NULL },
{ "trustedPublicKeys", SC_ASN1_STRUCT, SC_ASN1_CTX | 2 | SC_ASN1_CONS, 0, NULL, NULL },
{ "secretKeys", SC_ASN1_STRUCT, SC_ASN1_CTX | 3 | SC_ASN1_CONS, 0, NULL, NULL },
{ "certificates",SC_ASN1_STRUCT, SC_ASN1_CTX | 4 | SC_ASN1_CONS, 0, NULL, NULL },
{ "trustedCertificates", SC_ASN1_STRUCT, SC_ASN1_CTX | 5 | SC_ASN1_CONS, 0, NULL, NULL },
{ "usefulCertificates", SC_ASN1_STRUCT, SC_ASN1_CTX | 6 | SC_ASN1_CONS, 0, NULL, NULL },
{ "dataObjects", SC_ASN1_STRUCT, SC_ASN1_CTX | 7 | SC_ASN1_CONS, 0, NULL, NULL },
{ "authObjects", SC_ASN1_STRUCT, SC_ASN1_CTX | 8 | SC_ASN1_CONS, 0, NULL, NULL },
{ NULL, 0, 0, 0, NULL, NULL }
};
static const unsigned int odf_indexes[] = {
SC_PKCS15_PRKDF,
SC_PKCS15_PUKDF,
SC_PKCS15_PUKDF_TRUSTED,
SC_PKCS15_SKDF,
SC_PKCS15_CDF,
SC_PKCS15_CDF_TRUSTED,
SC_PKCS15_CDF_USEFUL,
SC_PKCS15_DODF,
SC_PKCS15_AODF,
};
static
int parse_odf(const u8 * buf, size_t buflen, struct sc_pkcs15_card *p15card)
{
const u8 *p = buf;
size_t left = buflen;
int r, i, type;
sc_path_t path;
struct sc_asn1_entry asn1_obj_or_path[] = {
{ "path", SC_ASN1_PATH, SC_ASN1_CONS | SC_ASN1_SEQUENCE, 0, &path, NULL },
{ NULL, 0, 0, 0, NULL, NULL }
};
struct sc_asn1_entry asn1_odf[10];
sc_path_t *path_prefix = calloc(1, sizeof(sc_path_t));
sc_format_path("3F005015", path_prefix);
sc_copy_asn1_entry(c_asn1_odf, asn1_odf);
for (i = 0; asn1_odf[i].name != NULL; i++)
sc_format_asn1_entry(asn1_odf + i, asn1_obj_or_path, NULL, 0);
while (left > 0) {
r = sc_asn1_decode_choice(p15card->card->ctx, asn1_odf, p, left, &p, &left);
if (r == SC_ERROR_ASN1_END_OF_CONTENTS)
break;
if (r < 0)
return r;
type = r;
r = sc_pkcs15_make_absolute_path(path_prefix, &path);
if (r < 0)
return r;
r = sc_pkcs15_add_df(p15card, odf_indexes[type], &path, NULL);
if (r)
return r;
}
return 0;
}
/***/
/* Public Module Functions */
/***/
const char *sc_driver_version() {
return PACKAGE_VERSION; /* defined in config.h of OpenSC */
}
int bind(sc_pkcs15_card_t *p15card, sc_pkcs15emu_opt_t *options)
{
u8 buf[1024];
sc_pkcs15_df_t *df;
sc_pkcs15_object_t *p15_obj;
size_t len = sizeof(buf);
int rv;
/* Check for correct card driver (i.e. iso7816) */
if (strcmp(p15card->card->driver->short_name, "iso7816") != 0)
return SC_ERROR_WRONG_CARD;
/* Check for correct card */
if (match_card(p15card->card) != 1)
return SC_ERROR_WRONG_CARD;
/* Set root path of this application */
p15card->file_app = sc_file_new();
sc_format_path("3F00", &p15card->file_app->path);
/* Load TokenInfo */
rv = dump_ef(p15card->card, "3F0050155032", buf, &len);
if (rv != SC_SUCCESS) {
sc_debug(p15card->card->ctx, SC_LOG_DEBUG_NORMAL, "Reading of EF.TOKENINFO failed: %d", rv);
return rv
Re: [opensc-devel] sc_ctx_detect_readers patch
On Thu, 2011-02-03 at 14:04 -0600, Douglas E. Engert wrote: > I have updates #321 with a new version of the cardmod patch > and would like to start to commit it in pieces. > > Piece 1 is the attachment I sent on 1/28 as new.martin.patch > based on Martin's patch from 1/19. This was the patch that would > work for Brian. The main change is adding two parameters to all > the *_detect_readers routines. Martin's patch already required these > to be added in a number of places. > > Is there any objection to adding this patch now? Yes, why you want to call 'sc_context_create()' altogether. There is not much functionality in it. So you could easily implement the required initialisation in 'CardAcquireContext()'. Next point is reader-pcsc.c: Why do you belief that squeezing in a second driver namely cardmod is a good idea? Why not implement a new one? Read the documents provided by Microsoft. Most things are managed by the CSP framework and therefore a reader-cardmod would be straight forward consisting mostly of stub functions. To make things short: Not calling 'sc_context_create()' and implementing a new reader-driver would make your proposal obsolete. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] cardmod driver now working with login switching cards in XP and Vista
Further testing of the cardmod on Vista and XP showed that the BaseCSP may change the pCardData->hSCardCtx and pCardData->hScard while calling cardmod routines. For example if the user switches cards during login when they see they have the wrong card inserted. The current cardmod code assumed that these would not change and would do a sc_context_create, sc_connect_card, sc_pkcs15_bind once in the CardAcquireContext routine. LoginUI.exe stresses cardmod, and may have multiple contexts open at the same time, and change the handles in a single session if a card is switched. Ticket #321 (See [1]) has a second patch [2] which will now check if hSCardCtx or hScard have changed, and do sc_pkcs15_unbind and sc_disconnect_card. It will then call sc_ctx_detect_readers with the new handles, sc_connect_card, sc_pkcs15_bind and reread the pkcs15 objects from the new card. The cardmod_detect_readers was change to call _sc_delete_reader to remove the previous reader, if any, before adding any new reader. _sc_delete_reader is a new routine, that will also be used in sc_release_context to delete all the readers. I plan to commit the _sc_delete_reader as seperate patch. Internet Explorer authentication to a web site may use hashAlg == CALG_SSL3_SHAMD5. Code was added to use the SC_ALGORITHM_RSA_HASH_MD5_SHA1. On XP I am using the BaseCSP see [3]. [1] http://www.opensc-project.org/opensc/ticket/321 [2] http://www.opensc-project.org/opensc/attachment/ticket/321/cardmod.mega.20110203.patch [3] http://support.microsoft.com/kb/909520 -- 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
[opensc-devel] sc_ctx_detect_readers patch
I have updates #321 with a new version of the cardmod patch
and would like to start to commit it in pieces.
Piece 1 is the attachment I sent on 1/28 as new.martin.patch
based on Martin's patch from 1/19. This was the patch that would
work for Brian. The main change is adding two parameters to all
the *_detect_readers routines. Martin's patch already required these
to be added in a number of places.
Is there any objection to adding this patch now?
The patch is attached again.
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Index: src/tools/piv-tool.c
===
--- src/tools/piv-tool.c (revision 5125)
+++ src/tools/piv-tool.c (working copy)
@@ -480,7 +480,8 @@
const char *object_id = NULL;
const char *key_info = NULL;
const char *admin_info = NULL;
-
+ sc_context_param_t ctx_param;
+
setbuf(stderr, NULL);
setbuf(stdout, NULL);
@@ -566,8 +567,11 @@
BIO_set_fp(bp,stdout,BIO_NOCLOSE);
}
- r = sc_establish_context(&ctx, app_name);
- if (r) {
+ memset(&ctx_param, 0, sizeof(sc_context_param_t));
+ ctx_param.app_name = app_name;
+
+ r = sc_context_create(&ctx, &ctx_param);
+ if (r != SC_SUCCESS) {
fprintf(stderr, "Failed to establish context: %s\n", sc_strerror(r));
return 1;
}
Index: src/tools/netkey-tool.c
===
--- src/tools/netkey-tool.c (revision 5125)
+++ src/tools/netkey-tool.c (working copy)
@@ -556,6 +556,8 @@
exit(1);
}
+ /* FIXME: use util_connect_card */
+ sc_ctx_detect_readers(ctx, NULL, NULL);
printf("%d Readers detected\n", sc_ctx_get_reader_count(ctx));
if(reader < 0 || reader >= (int)sc_ctx_get_reader_count(ctx)){
fprintf(stderr,"Cannot open reader %d\n", reader);
Index: src/tools/util.c
===
--- src/tools/util.c (revision 5125)
+++ src/tools/util.c (working copy)
@@ -11,6 +11,7 @@
#include
#include "util.h"
+/** Handles the common options of utilities and connects to the right card, specified with --reader */
int util_connect_card(sc_context_t *ctx, sc_card_t **cardp,
const char *reader_id, int do_wait, int verbose)
{
@@ -18,6 +19,8 @@
sc_card_t *card;
int r, tmp_reader_num;
+ /* Detecting for readers is the responsibility of the application */
+ sc_ctx_detect_readers(ctx, NULL, NULL);
if (do_wait) {
unsigned int event;
@@ -28,7 +31,7 @@
fprintf(stderr, "Error while waiting for a reader: %s\n", sc_strerror(r));
return 3;
}
- r = sc_ctx_detect_readers(ctx);
+ r = sc_ctx_detect_readers(ctx, NULL, NULL);
if (r < 0) {
fprintf(stderr, "Error while refreshing readers: %s\n", sc_strerror(r));
return 3;
Index: src/pkcs11/pkcs11-global.c
===
--- src/pkcs11/pkcs11-global.c (revision 5125)
+++ src/pkcs11/pkcs11-global.c (working copy)
@@ -228,6 +228,10 @@
goto out;
}
+ rc = sc_ctx_detect_readers(context, NULL, NULL);
+ if (rc != SC_SUCCESS)
+ sc_log(context, "Warning: reader detection failed: %d (%s)", rc, sc_strerror(rc));
+
/* Load configuration */
load_pkcs11_parameters(&sc_pkcs11_conf, context);
@@ -378,7 +382,7 @@
/* Trick NSS into updating the slot list by changing the hotplug slot ID */
sc_pkcs11_slot_t *hotplug_slot = list_get_at(&virtual_slots, 0);
hotplug_slot->id--;
- sc_ctx_detect_readers(context);
+ sc_ctx_detect_readers(context, NULL, NULL);
}
card_detect_all();
Index: src/libopensc/reader-pcsc.c
===
--- src/libopensc/reader-pcsc.c (revision 5125)
+++ src/libopensc/reader-pcsc.c (working copy)
@@ -843,7 +843,7 @@
}
}
-static int pcsc_detect_readers(sc_context_t *ctx)
+static int pcsc_detect_readers(sc_context_t *ctx, void * notused1, void * notused2)
{
struct pcsc_global_private_data *gpriv = (struct pcsc_global_private_data *) ctx->reader_drv_data;
DWORD active_proto, reader_buf_size;
@@ -1659,7 +1659,7 @@
return SC_SUCCESS;
}
-static int cardmod_detect_readers(sc_context_t *ctx)
+static int cardmod_detect_readers(sc_context_t *ctx, void * pcsc_context_handle, void * pcsc_card_handle)
{
SCARDHANDLE card_handle;
u8 feature_buf[256], rbuf[SC_MAX_APDU_BUFFER_SIZE];
@@ -1683,38 +1683,9 @@
sc_debug(ctx, SC_LOG_DEBUG_NORMAL, "Probing pcsc readers");
- if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\OpenSC Project\\Opensc",\
- NULL, KEY_READ, &key)==ERROR_SUCCESS)
- {
- CHAR val[1024];
- DWORD type;
- LONG size = sizeof(val);
+ gpriv->pcsc_ctx = *(SCARDCONTEXT *)pcsc_context_handle;
+ card_handle = *(SCARDHANDLE *)pcsc_card_handle;
- if(RegQueryValueEx(key,"pcsc_ctx", NULL, &type,
- val, &size) == ERROR_SUCCESS)
- {
- if(type == REG_DWORD)
- {
-gpriv->pcsc_ctx = *(DWORD*)val;
- }
- }
-
- if(RegQueryValueEx(key,"pcsc_card", NULL, &type,
-
Re: [opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files
On Thu, 2011-02-03 at 16:15 +0100, Andre Zepezauer wrote: > Hello Juan Antonio, > > attached tar file contains an external loadable emulator. Most things in > it are written to the information I got from your 'pkcs15-tool -D' dump. > But don't expect it to work instantly. > > I assumed following locations: > * EF.TokenInfo 3F005032 > * EF.ODF 3F005031 > > Maybe put an 'exit(0)' at the end of the 'bind' function and use > 'OPENSC_DEBUG=9'. I mean until you got that stuff loaded correctly. I was talking about that 'bind' function: Index: src/libopensc/pkcs15.c === --- src/libopensc/pkcs15.c (revision 5126) +++ src/libopensc/pkcs15.c (working copy) @@ -959,12 +959,14 @@ goto error; } done: + exit(0); fix_starcos_pkcs15_card(p15card); *p15card_out = p15card; sc_unlock(card); SC_FUNC_RETURN(ctx, SC_LOG_DEBUG_NORMAL, SC_SUCCESS); error: + exit(0); sc_unlock(card); sc_pkcs15_card_free(p15card); SC_FUNC_RETURN(ctx, SC_LOG_DEBUG_NORMAL, r); ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files
Hello Juan Antonio, attached tar file contains an external loadable emulator. Most things in it are written to the information I got from your 'pkcs15-tool -D' dump. But don't expect it to work instantly. I assumed following locations: * EF.TokenInfo 3F005032 * EF.ODF 3F005031 Maybe put an 'exit(0)' at the end of the 'bind' function and use 'OPENSC_DEBUG=9'. I mean until you got that stuff loaded correctly. Post your new logs when the emulator is working or ask questions if there are problems in getting it loaded. Regards Andre dnie.tar Description: Unix tar archive ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC on Android
Hello,
On Jan 26, 2011, at 10:09 AM, Ludovic Rousseau wrote:
> I just found the page "SmartCardPKI" [1] on the seek-for-android
> project. The goal is to build OpenSC for Android. They provide a patch
> [2] but I do not remember reading any discussion about it on the
> OpenSC mailing lists. Maybe they do not want to integrate their
> changes upstream.
>
> So far the changes I have seen are:
> - use dlopen() instead of lt_dlopen()
See #323 [1] for a patch that should do it automagically, while still
defaulting to libltdl if available. Please test/review.
It needs some more tinkering but is generally usable. Tested with Linux and
Visual studio. This also improves buildability on Windows, which
now possible directly from a SVN checkout and only needed ("optional")
additions are OpenSSL and zlib.
> - direct linking with libpcsclite.so
That should be the next step - defaulting to direct linking, unless it is not
doable for some reason or specially requested to build a dynamically loadable
version.
internal-winscard.h should be a fallback to replace the header coming with the
system. The idea of dynamic loading is nice but in real life syncing it to the
system implementation or current pcsc specification revision can be a pain.
[1] http://www.opensc-project.org/opensc/ticket/323
--
@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] DNIe driver: Needs Information on writing pkcs15-xxxx files
> Mensaje original > De: andre.zepeza...@student.uni-halle.de > Fecha: 03/02/2011 13:06 > Para: >CC: > Asunto: Re: [opensc-devel] DNIe driver: Needs Information on writing > pkcs15- files >On Thu, 2011-02-03 at 12:03 +0100, jons...@terra.es wrote: >> Hi All: >> >> I've concluded that DNIe card is not so pkcs15 compliant as >> promissed... >> I think I need rewriting of several file permissions and paths, as >> information >> provided in card pkcs15 structure seems to be wrong or incomplete >> >> I've studying the source code of provided drivers, but still unsure on >> how to process. >> >> Is there any kind of information about how to write pkcs15-xxx files? >> specifically, >> to specify visibility flags of public keys and rewriting paths in CDF >> file >Please send the following dumps: >pkcs15-tool -D >opensc-tool -f >Explain what should be fixed. If there are only minor issues (i.e. some >wrong flags or paths) then you can go with a very lightweight emulator. >I will explain later. Here it comes: Notice that there is an "official DNIe driver" released under GPL license (thus cannot be integrated into OpenSC mainstream), by spanish authorities that (partially) works DNIe contains 5 Certificates: At DF 3F006081 - User certificate for Authentication - User certificate for Signing - CA Certificate for User certificate validation At EF 3F00601F - ICC Certificate to stablish cwa14890 Secure Messaging channel At EF 3F006020 -Intermediate CA Cert for ICC cert validation --- [jantonio@drake libopensc]$ pkcs11-tool --login -O Official DGP's published GPL driver does not require "--login". Using slot 1 with a present token (0x1) Logging in to "DNI electrónico (PIN1)". Please enter User PIN: Private Key Object; RSA label: KprivAutenticacion ID: 4130364236323435383832383133323230313031313131313634303236 Usage: sign warning: PKCS11 function C_GetAttributeValue(MODULUS_BITS) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12) Public Key Object; RSA 0 bits ^^^ an error: RSA key object should show 2048 bits not zero label: KpuAutenticacion ID: 4130364236323435383832383133323230313031313131313634303236 Usage: verify Certificate Object, type = X.509 cert label: CertAutenticacion ID: 4130364236323435383832383133323230313031313131313634303236 Private Key Object; RSA label: KprivFirmaDigital ID: 4630364236323435383832383133323230313031313131313634303236 Usage: sign warning: PKCS11 function C_GetAttributeValue(MODULUS_BITS) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12) Public Key Object; RSA 0 bits ^^^ Same error: RSA key object should show 2048 bits not zero label: KpuFirmaDigital ID: 4630364236323435383832383133323230313031313131313634303236 Usage: verify Certificate Object, type = X.509 cert label: CertFirmaDigital ID: 4630364236323435383832383133323230313031313131313634303236 Data object 136525816 label: 'ADMIN_DatosFiliacion' application:'' app_id: -1 flags: modifiable private Data object 136525864 label: 'ADMIN_ImagenFacial' application:'' app_id: -1 flags: modifiable private Data object 136522528 label: 'ADMIN_ImagenFirma' application:'' app_id: -1 flags: modifiable private ^ Notice that ICC Certificate and ICC CA Cert are not shown (it does in Official driver) - [jantonio@drake libopensc]$ pkcs15-tool -D Using reader with a card: OmniKey CardMan 4321 00 00 PKCS#15 Card [DNI electrónico]: Version: 0 Serial number : 06B62458828132 Manufacturer ID: DGP-FNMT Flags : Login required, PRN generation PIN [PIN1] Object Flags : [0x3], private, modifiable ID : 01 Flags : [0x211], case-sensitive, initialized, integrity-protected Length : min_len:4, max_len:16, stored_len:8 Pad char : 0x00 Reference : 1 Type : ascii-numeric Private RSA Key [KprivAutenticacion] Object Flags : [0x3], private, modifiable Usage : [0xC], sign, signRecover Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local ModLength : 2048 Key ref: 1 Native : yes Path : 3f0050153f110101 ^ All the paths shown are wrong: real path is (in this case) 3f003f110101 My feeling is that DNIe doesn't store absolute paths, just relative, and my driver just appends data to current path (that is 3f005015+DataFromCard) ID : 4130364236323435383832383133323230313031313131313634303236 Private RSA Key [KprivFirmaDigital] Object Flags : [0x3], private, m
Re: [opensc-devel] r5124
On Feb 3, 2011, at 3:22 PM, Andre Zepezauer wrote: > That patch could be some lines shorter when using > sc_pkcs15_compare_id(). Additionally that would improve readability. > > I don't know what kind of function you did mean. Extracting only that > patch into a new function? I mean the lookup functionality looks like it could be re-used. -- @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] r5124
On Thu, 2011-02-03 at 14:36 +0200, Martin Paljak wrote: > Hello, > > On Thu, Jan 27, 2011 at 20:08, Andre Zepezauer > wrote: > > Hello Martin, > > > > some comments on r5124: > > > > 1. The values of pin_info->reference and prkey_info->key_reference > > shouldn't be compared because: > > > > * pin_info->reference is used as P2 parameter in VERIFY command > > * prkey_info->key_reference is used in MSE SET tag 0x84 > > OK, I see your point. > Looking at your patch: could it be extracted into a small lookup > function like the current one that is used? such a small lookup > function with a small doxygen doc would look really nice. That patch could be some lines shorter when using sc_pkcs15_compare_id(). Additionally that would improve readability. I don't know what kind of function you did mean. Extracting only that patch into a new function? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r5124
Hello, On Thu, Jan 27, 2011 at 20:08, Andre Zepezauer wrote: > Hello Martin, > > some comments on r5124: > > 1. The values of pin_info->reference and prkey_info->key_reference > shouldn't be compared because: > > * pin_info->reference is used as P2 parameter in VERIFY command > * prkey_info->key_reference is used in MSE SET tag 0x84 OK, I see your point. Looking at your patch: could it be extracted into a small lookup function like the current one that is used? such a small lookup function with a small doxygen doc would look really nice. I see it has been working up to because of a coincidence... ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files
On Thu, 2011-02-03 at 12:03 +0100, jons...@terra.es wrote: > Hi All: > > I've concluded that DNIe card is not so pkcs15 compliant as > promissed... > I think I need rewriting of several file permissions and paths, as > information > provided in card pkcs15 structure seems to be wrong or incomplete > > I've studying the source code of provided drivers, but still unsure on > how to process. > > Is there any kind of information about how to write pkcs15-xxx files? > specifically, > to specify visibility flags of public keys and rewriting paths in CDF > file Please send the following dumps: pkcs15-tool -D opensc-tool -f Explain what should be fixed. If there are only minor issues (i.e. some wrong flags or paths) then you can go with a very lightweight emulator. I will explain later. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files
Hi All: I've concluded that DNIe card is not so pkcs15 compliant as promissed... I think I need rewriting of several file permissions and paths, as information provided in card pkcs15 structure seems to be wrong or incomplete I've studying the source code of provided drivers, but still unsure on how to process. Is there any kind of information about how to write pkcs15-xxx files? specifically, to specify visibility flags of public keys and rewriting paths in CDF file Thanks in advance Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Some basic questions about the reader-pcscs.c modifications for cardmod
"Douglas E. Engert" a écrit sur 01/02/2011 22:25:04 : > [image supprimée] > > Re: Some basic questions about the reader-pcscs.c modifications for cardmod > > Douglas E. Engert > > A : > > OpenSC-devel, François Leblanc > > 01/02/2011 22:27 > > I have been doing some more testing. > > The current cardmod code is assuming the PCSC card handles are > set at the CardAcquireContext and not changed. The cardmod then I'm not agree, new memory allocation for the structure is made at each call of CryptAcquireContext, so each call define a new memory zone initialized with card handle/context provided by baseCSP... You have as structure with diffrents parameters as call to CryptAcquireContext... > initializes OpenSC, and and connects to the card, and calls > sc_pkcs15_bind, and reads objects off the card. > > But if the card is removed and a new card inserted, the BaseCSP may > establish a second context, then uses the first context again but > pass in new handles! Cardmod does not update its cached information. > This is the situation where the user inserted the wrong card, and > then inserted a different card. > > Other CSPs that use OpenSC pkcs11 , don't try and pass in the > provided handles but let reader-pcsc find the readers and cards using > reader-pcsc.c using new PCSC handles. If there is only one reader this > can work. But if there are more then one reader, some additional code > is need in the CSP to get the reader name from the BaseCSP handles, > and pass in the reader name to OpenSC so the same reader is used. > > So what is the better way to do this? Use the PCSC handles passed > from the BaseCSP, or get the reader name, and get pkcs11 to use > this reader? You can't, I've tested this BAseCSP module locks the card for itself so if you try to access the card other than provided context/handle you will be bloked. moreover (and I think it's for securities) you can't change handle and context in the BaseCSP (I've crash doing this if I remember...) Unfortunatly the reader name only can't let you retreive the handle of card... (but for security it's a good find!) > > I hope to test this week changes to have cardmod detect the change > in handles, and do the right thing. > > > On 1/28/2011 4:24 PM, Douglas E. Engert wrote: > > > > Other CSPs have been able to use the OpenSC opensc-pkcs11.dll > > which uses the standard reader-pcsc.c code. This would imply that > > they let reader-pcsc.c get its own handles to the card, and don't > > use the one provided by the caller of the CSP. > > > > So why does cardmod require so many modifications to reader-pcsc.c? > > And to answer some of my own questions... > I guess so that the handles are not lost. But this ads a lot of extra > code to reader-pcsc.c > > > > > The modifications also turn off: detect_card_presents, lock unlock, > > release, wait_for_event and reset. I would expect some of these to > > be critical to any CSP or mini-driver? > > Some of these functions like card removal must be being done by the > BaseCSP. Locking and reset may not be. > > > > > Why does the cardmod reader-pcsc.c need to load the constant > > winscard.dll, when the normal pcsc code loads the DEFAULT_PCSC_PROVIDER > > that is defined in the Configure/Makefiles as winscard.dll? > > > > I think more of the reader-pcsc.c code be shared. > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 Regards, François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Some basic questions about the reader-pcscs.c modifications for cardmod
Hello, "Douglas E. Engert" a écrit sur 28/01/2011 23:24:27 : > [image supprimée] > > Some basic questions about the reader-pcscs.c modifications for cardmod > > Douglas E. Engert > > A : > > OpenSC-devel, François Leblanc > > 28/01/2011 23:26 > > > Other CSPs have been able to use the OpenSC opensc-pkcs11.dll > which uses the standard reader-pcsc.c code. This would imply that > they let reader-pcsc.c get its own handles to the card, and don't > use the one provided by the caller of the CSP. > > So why does cardmod require so many modifications to reader-pcsc.c? This already answer but I can tell it again: So if you build a complete "CSP" you manage all the card, open context, power on card (so get handle on card) etc etc. You have to provide all cryptographics functions too defined in a CSP (CryptAcquireContext , CryptImportKey, etc etc). It's like developing a complete pkcs11 librairie. Moreover you have to make sign this "CSP" by Microsoft to be available and it's annoying point. So with this method you can use a pkcs11 dll working. If you use BaseCSP, this module provide basic "CSP" functionnalities ( CryptImportKey , etc) and you only need to provide a dll that manage your card with a defined API to access cryptographics functions of the card, in fact it's BaseCSP.dll witch detect the card and lunch your dll to access to the card. In this method you don't have developping all cryptographics functions, and more over you don't have to sign the dll. The bad side it(s like it is BaseCSP detecting card insertion, and manage the card, it's BaseCSP module who create context and power_on the card. At this point your card is loocked by BaseCSP module. BaseCSP module provide to your dll card context and handle to let you access your card. So the goal in this method it's to get card context and handle from BaseCSP to access card, it's why pcsc_reader code is modified since the standard way it's to create a context and power on card witch give you a card handle... Summary: CSP: + : use pkcs11 module, généric -: Hard to code, need to dévelop all cryptographics functions, need to be signed by Microsoft. BaseCSP: +: More easy, ligth API to develop -: Need to use provided card handle and card context. > > The modifications also turn off: detect_card_presents, lock unlock, > release, wait_for_event and reset. I would expect some of these to > be critical to any CSP or mini-driver? > Hum I've to see exactly but like I describe it's the BaseCSP module which manage the card, so some function can be uncompatible with BaseCSP module. > Why does the cardmod reader-pcsc.c need to load the constant > winscard.dll, when the normal pcsc code loads the DEFAULT_PCSC_PROVIDER Since cardmod it's used in windows environnement only it can use only winscard.dll. > that is defined in the Configure/Makefiles as winscard.dll? > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 Regards, François. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
