secure messaging with OpenSC

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

secure messaging with OpenSC

Tarasov Viktor
Hello,

I would like to discuss an extension for the libopensc API, that
implements secure messaging.

In the attachment there is the patch to the common OpenSC part.

The full patch was tested with Oberthur card.
(Java card, secure messaging is conform to GlobalPlatform .)

The main headlines are:
- secure messaging (SM) is used only for APDUs that really need it:
secure channel initialized just before, and closed immeadiatly after.

- secured APDUs are generated by some external SM_server (in my case
it's HTTPS server).
OpenSC access SM_server via the SM_module. SM_module to be used is
defined in opensc.conf
and is loaded during the sc_context initialization.

- SM_module exports three functions: initialize(), get_apdus() and
finalize():
first one is to get the host challenge;
second is to get the secured APDUs;
last one is to return the confirmation.

- libopensc card driver use cache of the curent EF's and DF's FCIs and
detects the moment when SM has to be used.

- APDUs processing is deviated to the SM procedures at the level of
libopensc commands
(not at the APDU transmission level) -- key_generation, key_import,
pin_unblock,
binary_write.

Current trunk version of libopensc/card-oberthur.c contains (in comments)
the SM specific procedures.
Full patch (too voluminous for this mail)
contains SM_server tool to generate secured APDUs, and SM_module
implementations.

It would be nice to hear your opinions,
kind wishes,
Viktor.


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

opensc-0.11.1.trunk.20061204-sm-common.patch.tgz (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: secure messaging with OpenSC

Andreas Jellinghaus-2
Hi Viktor,

I like the idea of adding secure messagin!

but in general: I think it would be nice to be able to
encrypt all communication. think of contactless smart
cards, I don't want data like the certificate go over
the air unencrypted for privacy reasons.

about the code: why add it as loadable module?
if you have cards where the secure messaging details are
under NDA that is ok. still it might be easier for all
of us if you had a private opensc version with that patched
in, rather than us loading modules.

also the patch adds a "sm" subdirectory, but does not include
any files in that dir. so we can't compile/test it. personally
I would prefer to keep all files in one directory (the
libopensc/ libpkcs15init split for example is something we now
regret, didn't get us much except complexity).

> - secured APDUs are generated by some external SM_server (in my case
> it's HTTPS server).
> OpenSC access SM_server via the SM_module. SM_module to be used is
> defined in opensc.conf
> and is loaded during the sc_context initialization.

why that? if you want a server to send commands to the card, that could
be done much easier without using opensc on the client at all - a simple
openct or pcsc app could do that.

it is ok for you to do that, but I wonder if other people will want that
as well - whether it makes sence to have this in the generic code we ship?

> Current trunk version of libopensc/card-oberthur.c contains (in comments)
> the SM specific procedures.
> Full patch (too voluminous for this mail)
> contains SM_server tool to generate secured APDUs, and SM_module
> implementations.

I guess for the general use it might be nicer to have everything build
into opensc, without external modules and external server. still if we
find a scenario where other people will want that too, we can think
of adding it. but normal users will not want to install a webserver
to initialized a oberthur card with secure messaging ...

we could merge a generic secure messaging into opensc, and offer the
webserver / rpc / ... code as patch in the contrib directory and see
if people want to use it? sure, would be extra work to maintain, but
I would prefer not to merge it till we get feedback (adds a lot of
complexity most people won't need).

can you put up a full diff somewhere? either post it to the list,
attach it to a new bug, or commit it to
        https://www.opensc-project.org/svn/files/trunk/contrib
?

Thanks, Andreas
p.s. sorry for answering this late. currently I have next to no time for
opensc.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: secure messaging with OpenSC

Tarasov Viktor
Andreas Jellinghaus a écrit :
> Hi Viktor,
>
> I like the idea of adding secure messagin!
>
> but in general: I think it would be nice to be able to
> encrypt all communication. think of contactless smart
> cards, I don't want data like the certificate go over
> the air unencrypted for privacy reasons.
Ok, it can be done at APDU transmit level, as Nils suggested.
I'll think about it.
Key-set can be placed locally: into opensc.conf or into the loadable module.

Rather, I supposed, that SC midlleware do not know the card's key-set.
SM_server (or entity that know key-set) is an integral part of the Smart
Card Manager,
that in its turn is coupled with PKI.
The cards key-sets are stored (or generated with some master key stored )
somewhere in secure place (cryptobox, other smartcard, ...).
So, the intention was to reduce the requests to SM_server and encrypt
only the sensible exchanges.

> about the code: why add it as loadable module?
> if you have cards where the secure messaging details are
> under NDA that is ok. still it might be easier for all
> of us if you had a private opensc version with that patched
> in, rather than us loading modules.
For me it seemed more flexible: in one case you place the key-set localy,
in other case the key-set is on a distant server. The OpenSC library is
the same,
the difference is in a relatively small module.
Also, with the loadable module there not so much changes to the OpenSC
common part.


>
> also the patch adds a "sm" subdirectory, but does not include
> any files in that dir. so we can't compile/test it. personally
> I would prefer to keep all files in one directory (the
> libopensc/ libpkcs15init split for example is something we now
> regret, didn't get us much except complexity).
It can be moved to "tools" or to the "contribution".
For me essential is that OpenSC API gives the possibility to implement at
least on the card driver level.

>
>> - secured APDUs are generated by some external SM_server (in my case
>> it's HTTPS server).
>> OpenSC access SM_server via the SM_module. SM_module to be used is
>> defined in opensc.conf
>> and is loaded during the sc_context initialization.
>
> why that? if you want a server to send commands to the card, that could
> be done much easier without using opensc on the client at all - a simple
> openct or pcsc app could do that.
The to use SM inside the normal pkcs15 or pkcs11 sessions,
and to hide (as far as possible) the SM specifities from these levels.

> it is ok for you to do that, but I wonder if other people will want that
> as well - whether it makes sence to have this in the generic code we
> ship?
That's why I posted it. I would like to get know if there is an interest
to SM,
and how the people are currently use it.
IMHO, implementation of loadable module has little impact to the common
OpenSC part.
Then each card driver decides for its own if it will use SM .

>
>> Current trunk version of libopensc/card-oberthur.c contains (in
>> comments)
>> the SM specific procedures.
>> Full patch (too voluminous for this mail)
>> contains SM_server tool to generate secured APDUs, and SM_module
>> implementations.
>
> I guess for the general use it might be nicer to have everything build
> into opensc, without external modules and external server. still if we
> find a scenario where other people will want that too, we can think
> of adding it. but normal users will not want to install a webserver
> to initialized a oberthur card with secure messaging ...
I do not propose to include external server.
I propose extention to API, that makes possible using of SM via the
loadable module.
If there will be an interest, part of SM procedures, currently included
in card-oberthur.c,
can be generalized into the separate file in libopensc.

In the full patch there are examples of the loadable modules,
library that contains the procedures of the GlobalPlatform SM processing
and command line tool that helps generate secured APDUs.

>
> we could merge a generic secure messaging into opensc, and offer the
> webserver / rpc / ... code as patch in the contrib directory and see
> if people want to use it? sure, would be extra work to maintain, but
> I would prefer not to merge it till we get feedback (adds a lot of
> complexity most people won't need).
>
> can you put up a full diff somewhere? either post it to the list,
> attach it to a new bug, or commit it to
>     https://www.opensc-project.org/svn/files/trunk/contrib
> ?
contrib/opensc-0.11.1.trunk.20061204-sm.patch.tgz
It's the full patch for opensc-0.11.1/trunk of 2006.12.04 .
>
> Thanks, Andreas
> p.s. sorry for answering this late. currently I have next to no time
> for opensc.
Thank you,
kind wishes,
Viktor.

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

Re: secure messaging with OpenSC

Tarasov Viktor
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus a écrit :
> I like the idea of adding secure messagin!
>
> but in general: I think it would be nice to be able to
> encrypt all communication. think of contactless smart
> cards, I don't want data like the certificate go over
> the air unencrypted for privacy reasons.

Hello,

Updated SM patch to OpenSC,
submitted into the svn/files/trunk/contrib,
now includes the possibility to encrypt all communication.

When encrypting all communication the SM initialized in sc_connect().
SM transform procedure is called at the APDU transmit level. It receives
APDU in clear and returns it in securized form.

In attachement there is the part of this patch that concerns
the OpenSC common files.

Kind wishes,
Viktor.







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

opensc-0.11.1.trunk.20061204-sm-common.patch.tgz (9K) Download Attachment