[RFC] starcos 3 driver

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] starcos 3 driver

Martin Vogt-5
Hello list,

the attachment contains an _experimental_ starcos 3 driver for
opensc. Currently it only supports reading and directory changing,
everything else is _really_ untested.
(It may burn your house, or your card, or you reader)
=>you have been warned :)

I don't know what is needed for a possible inclusion in opensc,
but in the future this may be an option, if anyone is interested
in this.
(At this point, it's only a snapshot of my development tree.)

If you have a comment ("RFC") what is missing, should be improved
etc... please post a reply.

I know, that writing support is missing in the driver, but
up to now I haven't figured out how opensc and the pkcs15-init
mechanism works...(I think I already locked up one card with
writing, so you should definitely not try this)

regards,

Martin

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

sc3.patch.gz (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] starcos 3 driver

Martin Paljak-2
Hello!
On Mar 20, 2010, at 21:48 , Martin Vogt wrote:
> Hello list,
>
> the attachment contains an _experimental_ starcos 3 driver for
> opensc. Currently it only supports reading and directory changing,
> everything else is _really_ untested.
> (It may burn your house, or your card, or you reader)
> =>you have been warned :)
Nice to know.


> I don't know what is needed for a possible inclusion in opensc,
> but in the future this may be an option, if anyone is interested
> in this.
> (At this point, it's only a snapshot of my development tree.)
I think the first requirement would be to have a possibility to expose something (a key or a PIN) via PKCS#11 or pkcs15-tool --dump.

If the card is available from a public source in quantities <=10 (a web shop) so that anyone interested could buy it, there should be no restrictions other than readable and functioning code.

Otherwise, for a closed or restricted card, decent documentation on the card is required and a responsible maintainer contact for the drvier (which means that if the maintainer disappears the support for that card is "discontinued" in OpenSC until somebody picks it up).






> If you have a comment ("RFC") what is missing, should be improved
> etc... please post a reply.
Some small comments-questions:
 - you seem to have diffed it against 0.11 not trunk. sc_ctx_suppress_errors_* is long gone for good.
 - please use the style guide http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Source - at least use tabs and add a bit more whitespace to be more readable and more similar to the rest of OpenSC
 - don't use printf in libopensc/* - it is a library and should return a relevant return code instead and keep stdout/stderr clean unless requested to do so.
 - is the card very different from the older starcos 2.3 driver? If it would be small and simple, maybe a single starcos driver could do, with if-s for different versions. (have not compared the files yet, just asking)
 - do you have a manual for the card? Can you share it (add to the relevant wiki page for example)? If there is a manual that defines different bits to set, maybe re-create the constants by using bitwise operators instead of having a table of opaque constants (sc_algo2apdu table)


> I know, that writing support is missing in the driver, but
> up to now I haven't figured out how opensc and the pkcs15-init
> mechanism works...(I think I already locked up one card with
> writing, so you should definitely not try this)
True, this is a bit complicated. I hope we can have a small howto for new card drivers one day. I don't know the full story with PKCS#15 initialization either, I guess Viktor might be the best source for this information.


--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] starcos 3 driver

Martin Vogt-5
>> (It may burn your house, or your card, or you reader)
>> =>you have been warned :)
> Nice to know.
>
>
>> I don't know what is needed for a possible inclusion in opensc,
>> but in the future this may be an option, if anyone is interested
>> in this.
>> (At this point, it's only a snapshot of my development tree.)
> I think the first requirement would be to have a possibility to expose something (a > key or a PIN) via PKCS#11 or pkcs15-tool --dump.

Yes. this works. (I meant with "reading support" that -D works)

>
> If the card is available from a public source in quantities <=10 (a web shop) so that > anyone interested could buy it, there should be no restrictions other than readable > and functioning code.
I'm unsure about that. I got my card, which has a a pkcs15 struct on it
and a card which is now empty again :-) (for testing the write support.)
But a bit of googleing did not show a web shop where I can buy it.
(But this does not mean, that you cannot buy the cards, I simply havent
found a shop)

>
> Otherwise, for a closed or restricted card, decent documentation on the card is
> required and a responsible maintainer contact for the drvier
The documentation is available, as stated in the FAQ:
http://www.opensc-project.org/faq.html (under the starcos section)
(This should be no problem.)

>> If you have a comment ("RFC") what is missing, should be improved
>> etc... please post a reply.
> Some small comments-questions:
>  - you seem to have diffed it against 0.11 not trunk. sc_ctx_suppress_errors_* is
> long gone for good.

I tried to diff against trunk, but noticed that the debugging macros changed,
so for now I use the stable release.(Is it really necessary to add ~20chars
in every debug call?)

>  - please use the style guide http://www.opensc-project.org/opensc
Yes. I will do that.

>  - don't use printf in libopensc/*
No problem. Currently its only a development version anyway.

>  - is the card very different from the older starcos 2.3 driver?

Initially I started with the 2.3 driver, because I thought, its maybe changing
the ATR, fixing some smaller thing etc.., doing after that
some backporting with if/else constructs and then it works.
(Then I noticed that it wont be so easy.)

I hadn't any knowledge of smartcards and experimented much
with the original 2.3 code, thus there is not much left from it.
In other words, I started with the idea of a patch against 2.3, then I was
forced to do some refactoring, then some more.
Thus, I would say, they differ(in the context that the 2.3 driver needs
a refactoring.)

>If it would be small and simple, maybe a single starcos driver could do, with if-s for >different versions. (have not compared the files yet, just asking)

I had to rework the fci,fcp and in in combination with that the
select_file call, which then needed different cache handling.
Then I worked on the sec_env and because this seemed not to work at
all I experimented a lot with it, which means code rewrite etc...
Although, many apdu calls are still the same, like in the 2.3 driver.

>  - do you have a manual for the card?
Yes.(But I cannot share it.)

> If there is a manual that defines different bits to set, maybe re-create the >constants by using bitwise operators instead of having a table of opaque constants >(sc_algo2apdu table)
This whole set_security_env is still a mystary, and it would be nice
to have more information in the code where the bits from opensc
go into the apdu call. But I have not found another solution yet
(and I doubt that there is anything possible), like getting the bits
from opensc and then altering  matching bits for the apdu.

>> I know, that writing support is missing in the driver, but
>> up to now I haven't figured out how opensc and the pkcs15-init
>> mechanism works...(I think I already locked up one card with
>> writing, so you should definitely not try this)
> True, this is a bit complicated. I hope we can have a small howto for new card >drivers one day. I don't know the full story with PKCS#15 initialization either, I >guess Viktor might be the best source for this information.

Up to now, I cannot even come up with a question, because I dont know
what to ask :-).
But I think I will figure out something.

regards,

Martin
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] starcos 3 driver

Martin Paljak-2
On Mar 24, 2010, at 14:29 , Martin Vogt wrote:
>>> I don't know what is needed for a possible inclusion in opensc,
>>> but in the future this may be an option, if anyone is interested
>>> in this.
>>> (At this point, it's only a snapshot of my development tree.)
>> I think the first requirement would be to have a possibility to expose something (a > key or a PIN) via PKCS#11 or pkcs15-tool --dump.
>
> Yes. this works. (I meant with "reading support" that -D works)
OK. Just to verify: the driver successfully exposes keys and PINs on the card via pcks15-tool --dump and the keys can be successfully used for example with Firefox for SSL authentication?

Just wanted to make sure that the read support was on a meaningful level (nut just filesystem read support for select file/read binary).


>
>>
>> If the card is available from a public source in quantities <=10 (a web shop) so that > anyone interested could buy it, there should be no restrictions other than readable > and functioning code.
> I'm unsure about that. I got my card, which has a a pkcs15 struct on it
> and a card which is now empty again :-) (for testing the write support.)
> But a bit of googleing did not show a web shop where I can buy it.
> (But this does not mean, that you cannot buy the cards, I simply havent
> found a shop)
As a general rule, unless there exists a well known webshop selling the cards, it is extremely difficult to a) get in touch with vendors b) buy small quantities of cards (without a promise of a multi-thousand deal afterwards). Which basically renders many modern cards as unavailable for the general consumer market.

Maybe you can ask your source for more information or maybe you can channel cards to other interested people (developers)

Why it matters? If the only option is to blindly put the code into OpenSC then there really needs to be a link to an active maintainer or at least somebody who can test whatever changes or investigate whatever issues might pop to mailing list or issue tracker.
If you're willing to do it - no problem as long as you remain responsive. But in any case it would be better if there was a possibility to buy the cards without hassle in small quantities.


>> Otherwise, for a closed or restricted card, decent documentation on the card is
>> required and a responsible maintainer contact for the drvier
> The documentation is available, as stated in the FAQ:
> http://www.opensc-project.org/faq.html (under the starcos section)
> (This should be no problem.)
If you have not signed a NDA for the documentation? If not, can you share it?



>>> If you have a comment ("RFC") what is missing, should be improved
>>> etc... please post a reply.
>> Some small comments-questions:
>>  - you seem to have diffed it against 0.11 not trunk. sc_ctx_suppress_errors_* is
>> long gone for good.
>
> I tried to diff against trunk, but noticed that the debugging macros changed,
> so for now I use the stable release.
Also the core API has changed (no slots on reader level for example)

> (Is it really necessary to add ~20chars
> in every debug call?)
IMO not. What would you suggest? Shorter constants?



>>  - don't use printf in libopensc/*
> No problem. Currently its only a development version anyway.
If the goal is to keep the version easily mergeable  with OpenSC, it would be better to use sc_debug instead.


>>  - is the card very different from the older starcos 2.3 driver?
>
> Initially I started with the 2.3 driver, because I thought, its maybe changing
> the ATR, fixing some smaller thing etc.., doing after that
> some backporting with if/else constructs and then it works.
> (Then I noticed that it wont be so easy.)
>
> I hadn't any knowledge of smartcards and experimented much
> with the original 2.3 code, thus there is not much left from it.
> In other words, I started with the idea of a patch against 2.3, then I was
> forced to do some refactoring, then some more.
> Thus, I would say, they differ(in the context that the 2.3 driver needs
> a refactoring.)
>
>> If it would be small and simple, maybe a single starcos driver could do, with if-s for >different versions. (have not compared the files yet, just asking)
>
> I had to rework the fci,fcp and in in combination with that the
> select_file call, which then needed different cache handling.
> Then I worked on the sec_env and because this seemed not to work at
> all I experimented a lot with it, which means code rewrite etc...
> Although, many apdu calls are still the same, like in the 2.3 driver.


OK. Thought so (that it's not that trivial) :)



>
>>  - do you have a manual for the card?
> Yes.(But I cannot share it.)
Why? Have you signed an NDA or is there something similar that forbids you from doing it?

>
>> If there is a manual that defines different bits to set, maybe re-create the >constants by using bitwise operators instead of having a table of opaque constants >(sc_algo2apdu table)
> This whole set_security_env is still a mystary, and it would be nice
> to have more information in the code where the bits from opensc
> go into the apdu call. But I have not found another solution yet
> (and I doubt that there is anything possible), like getting the bits
> from opensc and then altering  matching bits for the apdu.

Look for similar code in OpenSC. In such cases having symbolic constants and manual composition of command byte is much better than using cryptic numeric constants. Even though they seem to match very often (like pcsc pinpad code and ccid command blocks) they don't match 1:1


>>> I know, that writing support is missing in the driver, but
>>> up to now I haven't figured out how opensc and the pkcs15-init
>>> mechanism works...(I think I already locked up one card with
>>> writing, so you should definitely not try this)
>> True, this is a bit complicated. I hope we can have a small howto for new card >drivers one day. I don't know the full story with PKCS#15 initialization either, I >guess Viktor might be the best source for this information.
>
> Up to now, I cannot even come up with a question, because I dont know
> what to ask :-).

OK, good luck.
--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] starcos 3 driver

bobduprout
This post has NOT been accepted by the mailing list yet.
In reply to this post by Martin Vogt-5
Hi,
I got an error when I try to compile with this patch:
libtool: link: gcc -fno-strict-aliasing -g -O2 -o .libs/base64 base64.o sc-test.o  ../../src/libopensc/.libs/libopensc.so ../../src/common/.libs/libcompat.a
../../src/libopensc/.libs/libopensc.so: undefined reference to `sc_get_starcos3_driver'
Do you have any clue to solve that?
Best Regards