Secure Messaging - How?

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

Secure Messaging - How?

Anders Rundgren
OpenSC will get Secure Messaging some day it seems based on the Wiki.

What I don't understand is how you are supposed to use Secure Messaging
since it works on the APDU-level which is invisible from PKCS #11.

Anders
_______________________________________________
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 - How?

Viktor TARASOV-2
Anders Rundgren wrote:
> OpenSC will get Secure Messaging some day it seems based on the Wiki.
>
> What I don't understand is how you are supposed to use Secure Messaging
> since it works on the APDU-level which is invisible from PKCS #11.
>  

It'll be implemented at the libopensc level.

In ideal case, the PKCS#11 level is not conscious of the secure
transport layer (STL) presence.
(For a while, in my 'concept proof' implementation, I use a few PKCS#11
API extensions.)

STL is used when it's imposed to use by operation's ACL.
For a while I consider the ACLs that require the SM, External
Authentication, PINs and its combinations .

(Another possible, more simple implementation, is to secure the all
APDUs at the 'send_apdu' level, just before reader->transmit. )

When ACL demands STL, the appropriate callbacks from the dynamically
loadable SM module is used
to initialize and execute secure transaction. This deviation from the
normal processing takes place at the libopensc level .

There two types of this SM loadable module:
'local' -- has direct access to the keysets, mostly used for the tests;
'distant'  -- communicates with some distant entity that is capable to
securize an APDU or to generate secured one.

> Anders
>  

Kind wishes,
Viktor.

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


--
Viktor Tarasov <[hidden email]>

_______________________________________________
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 - How?

Andreas Jellinghaus-2
In reply to this post by Anders Rundgren
Am Dienstag 06 April 2010 10:04:00 schrieb Anders Rundgren:
> OpenSC will get Secure Messaging some day it seems based on the Wiki.
>
> What I don't understand is how you are supposed to use Secure Messaging
> since it works on the APDU-level which is invisible from PKCS #11.

I'm no expert, but I guess you need a card driver and profile that
is designed to work with secure messaging from ground up.

No idea how well PKCS#15 helps here. With some other cards you
only read a chip serial number or number given to the card
(e.g. issuer serial number), and then start secure messaging
based on a key issued to the card. not sure if PKCS#15 has any
way to implement something like that.

Regards, Andreas
_______________________________________________
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 - How?

Anders Rundgren
Andreas Jellinghaus wrote:

> Am Dienstag 06 April 2010 10:04:00 schrieb Anders Rundgren:
>> OpenSC will get Secure Messaging some day it seems based on the Wiki.
>>
>> What I don't understand is how you are supposed to use Secure Messaging
>> since it works on the APDU-level which is invisible from PKCS #11.
>
> I'm no expert, but I guess you need a card driver and profile that
> is designed to work with secure messaging from ground up.
>
> No idea how well PKCS#15 helps here. With some other cards you
> only read a chip serial number or number given to the card
> (e.g. issuer serial number), and then start secure messaging
> based on a key issued to the card. not sure if PKCS#15 has any
> way to implement something like that.

I'm still curious about the applications that OpenSC target with SM.

One application seem to be limiting access to ACL-controlled data
on the card (biometrics, health records, etc) which IMO is fairly
uninteresting since ISO/EIC has defined a new middleware framework
for that purpose which I think is the foundation for the German
e-card as well.

A more generally applicable use of SM is for provisioning cards because
currently you  can't actually see the difference of keys generated
outside of a card or inside of it.  Although you are supposed to
"trust" the middleware for doing the right thing, I believe this
model is broken (you should trust middleware but not *blindly*),
and some kind of SM is probably going to be standard some day.

At least that is what the GlobalPlatform people say.

GlobalPlatform is currently in a transition phase from using shared
secrets to using PKI for on-card pre-provisioned keys.  SCP10 is
the ETSI name of the PKI-version of SM.

Anders


_______________________________________________
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 - How?

Viktor TARASOV-2
Anders Rundgren wrote:

> Andreas Jellinghaus wrote:
>  
>> Am Dienstag 06 April 2010 10:04:00 schrieb Anders Rundgren:
>>    
>>> OpenSC will get Secure Messaging some day it seems based on the Wiki.
>>>
>>> What I don't understand is how you are supposed to use Secure Messaging
>>> since it works on the APDU-level which is invisible from PKCS #11.
>>>      
>> I'm no expert, but I guess you need a card driver and profile that
>> is designed to work with secure messaging from ground up.
>>
>> No idea how well PKCS#15 helps here. With some other cards you
>> only read a chip serial number or number given to the card
>> (e.g. issuer serial number), and then start secure messaging
>> based on a key issued to the card. not sure if PKCS#15 has any
>> way to implement something like that.
>>    
>
> I'm still curious about the applications that OpenSC target with SM.
>  

We use SM to administrate the card content through the untrusted middleware.
Until now it mostly concerned the import of the key material and card
initialization.

Now there are multi-applications cards (IAS/ECC) that contain fully
protected 'administration' applications.
Any change of content of such applications needs SM.

Also there is 'qualified signature' that in some profiles needs two
authentications: Sign PIN and SM.

> One application seem to be limiting access to ACL-controlled data
> on the card (biometrics, health records, etc) which IMO is fairly
> uninteresting since ISO/EIC has defined a new middleware framework
> for that purpose which I think is the foundation for the German
> e-card as well.
>
> A more generally applicable use of SM is for provisioning cards because
> currently you  can't actually see the difference of keys generated
> outside of a card or inside of it.  Although you are supposed to
> "trust" the middleware for doing the right thing, I believe this
> model is broken (you should trust middleware but not *blindly*),
> and some kind of SM is probably going to be standard some day.
>
> At least that is what the GlobalPlatform people say.
>
> GlobalPlatform is currently in a transition phase from using shared
> secrets to using PKI for on-card pre-provisioned keys.  SCP10 is
> the ETSI name of the PKI-version of SM.
>
> Anders
>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>  


--
Viktor Tarasov <[hidden email]>

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