Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-04 Thread Martin Paljak 
Hello,
On Feb 3, 2011, at 11: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()'.

As the context object is fundamental to all OpenSC API calls, there should be 
the basic building blocks readily available to be able to use and create 
contexts in virtually any condition.
Minidriver is one such condition, sc_context_create() must be in a shape that 
it would be usable. The operations done by sc_context_create() documented and 
suitable for such use.


 Next point is reader-pcsc.c: Why do you belief that squeezing in a
 second driver namely cardmod is a good idea?
I think Douglas is incrementally working on the existing codebase. Why the 
cardmod driver was squeezed into reader-pcsc.c the way it is in the first place 
is beyond me, as Francois noted, I was not very hot about it [1].

 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.
This requires defining what a reader driver in OpenSC is and what it does?

My idea is that reader-XXX.c incorporates the necessary code that translate 
from the generic sc_*** operations to the API calls to talk to such reader 
type. Thus OpenCT (ct_* in reader-openct.c), CT-API (CT_* API in loadable 
modules in reader-ctapi.c) and PC/SC (SCard* API calls in reader-pcsc.c).

In this picture there is no new driver, just the code in reader-pcsc.c must be 
modified to adapt to the way a MiniDriver uses libopensc.

 To make things short: Not calling 'sc_context_create()' and implementing
 a new reader-driver would make your proposal obsolete.

[1] 
http://www.opensc-project.org/pipermail/opensc-devel/2011-January/015764.html
-- 
@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] Braking change in OpenSC 0.12.0 tokenInfo

2011-02-04 Thread Toni Sjöblom - Aventra 
Hi,

 -Original Message-
 From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
 Sent: 23. tammikuuta 2011 4:45
 
 On Sat, 2011-01-22 at 15:42 +0200, Martin Paljak wrote:
  On Jan 21, 2011, at 9:33 AM, Aventra wrote:
   Could this fix that Andre has proposed be committed to trunk?
   It should work for all cards, since it only makes two elements of the
 TokenInfo optional.
  Yes, but I'm not able to directly locate the relevant part in the ASN.1
 description (for objId) that tell they are optional that I could reference
in
 the commit message.
 
  If you can speed that up would help.
 
 From A. ASN.1 module (page 65):
 
 AlgorithmInfo ::= SEQUENCE {
   reference   Reference,
   algorithm   PKCS15-ALGORITHM.id({AlgorithmSet}),
   parameters  PKCS15-
 ALGORITHM.Parameters({AlgorithmSet}{@algorithm}),
   supportedOperations PKCS15-
 ALGORITHM.Operations({AlgorithmSet}{@algorithm}),
   algId   PKCS15-
 ALGORITHM.objectIdentifier({AlgorithmSet}{@algorithm}) OPTIONAL,
   algRef  Reference OPTIONAL
 }

I double checked from [1] this what Andre sent earlier.
As defined in the ASN.1 module those two attributes are optional.

This follows the PKCS#15 spec and fixes the regression bug.
Actually by definition the name should be algId instead of objId, but this
makes no difference.

This is important because currently you can't initialize cards using OpenSC
and
previously Initialized cards don't work either.

 In addition to the proposed patch a mechanism is required, so that the
 absence of these two fields could be noticed. That is because
 sc_supported_algo_info.algo_ref [1] will always hold a value. The
 question is, if that value is valid?
 
 In the case of the absence of algRef in AlgorithmInfo (see above) the
 value of sc_supported_algo_info.algo_ref [1] is invalid.
 
 Definition of Reference:
   pkcs15-ub-reference INTEGER ::= 255
   Reference ::= INTEGER (0..pkcs15-ub-reference)

Another question is then, what to do with these values, but for now we need
to fix this
and think of an solution later.

[1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs-15v1_1.asn

Thanks,
Toni

 
 [1]
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/opensc.h#L1
48

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Braking change in OpenSC 0.12.0 tokenInfo

2011-02-04 Thread Martin Paljak 

On Feb 4, 2011, at 2:11 PM, Toni Sjöblom - Aventra wrote:

 Hi,
 
 -Original Message-
 From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
 Sent: 23. tammikuuta 2011 4:45
 
 On Sat, 2011-01-22 at 15:42 +0200, Martin Paljak wrote:
 On Jan 21, 2011, at 9:33 AM, Aventra wrote:
 Could this fix that Andre has proposed be committed to trunk?
 It should work for all cards, since it only makes two elements of the
 TokenInfo optional.
 Yes, but I'm not able to directly locate the relevant part in the ASN.1
 description (for objId) that tell they are optional that I could reference
 in
 the commit message.
 
 If you can speed that up would help.
 
 From A. ASN.1 module (page 65):
 
 AlgorithmInfo ::= SEQUENCE {
  reference   Reference,
  algorithm   PKCS15-ALGORITHM.id({AlgorithmSet}),
  parameters  PKCS15-
 ALGORITHM.Parameters({AlgorithmSet}{@algorithm}),
  supportedOperations PKCS15-
 ALGORITHM.Operations({AlgorithmSet}{@algorithm}),
  algId   PKCS15-
 ALGORITHM.objectIdentifier({AlgorithmSet}{@algorithm}) OPTIONAL,
  algRef  Reference OPTIONAL
 }
 
 I double checked from [1] this what Andre sent earlier.
 As defined in the ASN.1 module those two attributes are optional.
I hoep Andre can fix it, I'm on the road to Brussels for FOSDEM.


-- 
@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

2011-02-04 Thread Douglas E. Engert 


On 2/3/2011 5:19 PM, Andre Zepezauer wrote:
 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).


Correct. The trick is to pass in the handles provided by the BaseCSP to the
lowest level drivers that will be doing the send receive and any other
operations the pcsc driver might want to do. For example if the card
is withdrawn while a send or receive is being done, the pcsc drivers
need to handle it, or report back to cardmod to report en error to
the BaseCSP. This all needs to be looked at closer.


 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.

I was starting for the SVN code that kept track of separate functions.
Yes changes could be made in that area.




-- 

  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] sc_ctx_detect_readers patch

2011-02-04 Thread Andre Zepezauer 
On Fri, 2011-02-04 at 07:58 +0200, Martin Paljak wrote:
 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.)

Attachment shows a different approach. It's not a complete solution but
should be sufficient to demonstrate an alternative method of
SCARDCONTEXT passing.

Regards
Andre
Index: src/libopensc/reader-pcsc.c
===
--- src/libopensc/reader-pcsc.c	(revision 5127)
+++ src/libopensc/reader-pcsc.c	(working copy)
@@ -1900,6 +1900,20 @@
 	SC_FUNC_RETURN(ctx, SC_LOG_DEBUG_VERBOSE, ret);
 }
 
+int sc_cardmod_set_ctx(sc_reader_t *reader, SCARDCONTEXT hSCardCtx, SCARDHANDLE hSCard)
+{
+	struct pcsc_private_data *priv;
+
+	if (reader == NULL || strcmp(reader-driver-name, cardmod) != 0)
+		return SC_ERROR_INVALID_ARGUMENTS;
+
+	priv = GET_PRIV_DATA(reader);
+	priv-gpriv-pcsc_ctx = hSCardCtx;
+	priv-pcsc_card = hSCard;
+
+	return SC_SUCCESS;
+}
+
 struct sc_reader_driver * sc_get_cardmod_driver(void)
 {
 
Index: src/cardmod/cardmod.c
===
--- src/cardmod/cardmod.c	(revision 5127)
+++ src/cardmod/cardmod.c	(working copy)
@@ -1454,6 +1454,14 @@
 			vs-reader = sc_ctx_get_reader(vs-ctx, 0);
 			if(vs-reader)
 			{
+r = sc_cardmod_set_ctx(vs-reader, pCardData-hSCardCtx, pCardData-hScard);
+if (r != SC_SUCCESS)
+{
+	logprintf(pCardData, 0, );
+	/* TODO: free allocated resources */
+	return SCARD_F_UNKNOWN_ERROR;
+}
+
 logprintf(pCardData, 3, %s\n, NULLSTR(vs-reader-name));
 	
 r = sc_connect_card(vs-reader, (vs-card));
___
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

2011-02-04 Thread Douglas E. Engert 


On 2/3/2011 8:25 PM, Andre Zepezauer wrote:
 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.

The trick the cardmod code is using is the detect_readers is setting
up a reader to use the handles provided by the BaseCSP. But it is
trying to pass the handles via the registry in HKLM. This will not work as
multiple contexts maybe initialized at the same time by the same
process using multiple threads. Or by a process run under the user
who does not have rights to update the HKLM. HKCU can not be used
either, as during login there is no current user.

 2. Looking at 'detect_readers' of the current driver looks like rocket
 science [1]. IMO there is something fundamentally wrong.

Yes as I have said over the last two week, the detect_readers should not be
using the registry, and the mega patch removes this code in favor or cardmod
calling sc_ctx_detect_readers(ctx, pcsc_context_handle,pcsc_card_handle)
This then provides the 2 handles provided by the BaseCSP to 
cardmod_detect_readers.
Cardmod_detect_readers then used these to create a single reader, and does what 
ever
else is needed.

sc_ctx_detect_readers can be called to reset the handles of needed.

Rather then using the detect_reader, some other entry point in to the
cardmod pcsc code could be used to do the same thing, maybe cardmod.c could
call this directly bypassing the need to call sc_ctx_detect_readers,
and ops-detect_readers == NULL could be used.


 Regards
 Andre

 [1] 
 http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/reader-pcsc.c#L1662




-- 

  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] sc_ctx_detect_readers patch

2011-02-04 Thread Douglas E. Engert 


On 2/3/2011 11:58 PM, Martin Paljak wrote:

 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.

OK, I like that. This still has to be done before any call to 
sc_ctx_detect_readers.
So you original patch to require the application to call sc_ctx_detect_readers 
is
still needed. So do you want to commit it?

The cardmod.c routines would call sc_context_create  which would setup the pcsc 
driver.
Then cardmod.c would call your use_reader, or use_pcsc_parameters or
pcsc_use_single_reader(ctx, pcsc_context_handle, pcsc_card_handle) Or does it
need to be wrappered as sc_ctx_use_reader?

The cardmod_detect_reader could be converted to be this pcsc_use_single_reader.

Thereader 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.

Or does it need to be wrappered as sc_ctx_use_reader? I assume the other 
drivers would
would not provide this entry point.

Also keep in mind that in a single machine with a single opensc.conf the 
cardmod minidriver
might by used by the BaseCSP for Microsoft applications, and PKCS#11 used by 
other application
like FireFox and Thunderbird.

So would the ctx.c still have:
642 #ifdef ENABLE_CARDMOD
643 if(strcmp(ctx-app_name, cardmod) == 0) {
644 ctx-reader_driver = sc_get_cardmod_driver();
645 }
646 #endif

Or could this be abstracted to use some parameters in the opensc.conf if 
appname = cardmod?

Even if that was done a routine is still needed to pass in the reader handles.



-- 

  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] sc_ctx_detect_readers patch

2011-02-04 Thread Douglas E. Engert 


On 2/4/2011 8:18 AM, Andre Zepezauer wrote:
 On Fri, 2011-02-04 at 07:58 +0200, Martin Paljak wrote:
 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.)

 Attachment shows a different approach. It's not a complete solution but
 should be sufficient to demonstrate an alternative method of
 SCARDCONTEXT passing.

I appreciate the change. But how this will work depends on how Martin
implements the sc_ctx_detect_reader patch. There may or may not
be a reader structure to change. If there was one, then reader-pcsc
must have found all the readers and cards and have handles to them. Just
overwriting the handles may cause a memory leak as the overwritten
handles may not get released. It also means that when the pcsc is done
it will release the handles provided by the BaseCSP, this may cause other
problems.

The current cardmod changes in reader-pcsc.c try and do a lot of work
to make sure extra handles are not obtained, and are not release.
We need to look closer at these changes, and if these can be merged in
better to the original reader-pcsc.c code.


 Regards
 Andre

-- 

  Douglas E. Engert  deeng...@anl.gov
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] MyEID init patch

2011-02-04 Thread Toni Sjöblom - Aventra 
Hi,

 

I have created a very small patch for the MyEID card driver that adds the
appropriate flags when the card is initialized.

Please review and comment or commit. This requires also the fix that Andre
presented a while ago (I also attached that).

 

It also sets some values to the “new” supportedAlgorithms structure, but
these are currently not added to the tokenInfo.

It was a little out of my knowledge how modify the encoding of the
tokenInfo, but maybe somebody else knows how it works.

Maybe you Viktor can look at that, since you originally created the new
tokenInfo handling last year (maybe 7-8 months ago).

 

Thanks,

Toni

 

 



myeid-init.patch
Description: Binary data


tokenInfo.patch
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] emulation dll for DNIe

2011-02-04 Thread Juan Antonio Martinez 
El jue, 03-02-2011 a las 23:58 +0100, Andre Zepezauer escribió:

 There is a problem with reading of public keys and certificates. Try to
 do it manually with opensc-explorer. If it fails with some error like
 'security status not satisfied' then you can login via:
 verify CHV1 31:32:33:34 (ID of PIN 1 and code is 1234)

I finally found the bug: DNIe stores the certificates and keys in
compressed format, and a wild pointer in the detect-and-uncompress
code returned nonsense data

Anyway, I still need path rewriting patch. When everything 
get working I'll need some indications on how to integrate
your module into DNIe and OpenSC code (with proper copyright
notices, of course)

About visibility of certificates and keys patch, notice that 
DNIe requires the user to enter pin for just read (neither
signature nor authentication) user certificates. It's not 
standard, I know, but seems to be a very common issue in 
some cards

  Ok. I'll add some debugging points, write dnie_list_files()...
  and go to sleep :-) (here in Spain is 00:16 am, too late for me) 
 
 Why you need dnie_list_files()? To dump 3f0060817004 you can use:
 cd 6081
 cat 7004

Yes, I know: it was a no-cert-related-problem pending task to
allowed me a bit of relax :-). Btw ¿is there any standard apdu
for listing files?. Some of OpenSC card drivers uses GetData
apdu on DF files, some other uses propietary apdu's, and finally
some others (as mine does) just dirty and slowly iterate and check
every possible file id values...

Thanks again for your help. Now I can restart work

Juan Antonio


smime.p7s
Description: S/MIME cryptographic signature
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel