globalplatform-developers

[Globalplatform-developers] Branch for NSS token support

[Aaron C. <ac...@gm...>]

Hello,

Over the past few days, I've implemented (very) basic 
GPShell/GlobalPlatform support for using an NSS token to establish GPSC 
sessions.  The advantage of NSS support is that the GP secure channel 
keys can be stored in an HSM (rather than in plaintext in the script 
files).  Using an HSM to store the GP keys is a requirement for me.

Right now this support is very hackish and only works with SCP01; 
however, I'm (hopefully) going to be adding SCP02 support over the next 
few days.  Things are a bit tricky because some of the crypto needs to 
be migrated to the NSS token, but on the plus side, due to the 
prevalence of session keys in the GP spec, most of the crypto code can 
remain openssl (only the session key generation functions need to be 
duplicated and ported to NSS).

If there's any interest in me sharing this NSS implementation, can I get 
commit rights?  I'm currently thinking that a separate branch is the 
best place to put this experimental code.  I'm not sure of the 
granularity of the access controls you're allowed, but if it's possible 
to restrict my access to that a new "globalplatform-nss" branch that you 
create, that'd be fine with me.

Anyways, just let me know if you're interested.

V/r,
Aaron

Re: [Globalplatform-developers] Branch for NSS token support

[Karsten O. <wid...@t-...>]

Hi,

of course this is of interest. Nice would be a generic PKCS#11
implementation, preferably using libopencryptoki, so every HSM can be
supported. Could you provide this?

A separate branch created from the trunk is a good idea for the start,
and if everything is working this can be merged back.

Please send me your SF account and you will get the access to the
repository.

Thanks,
Karsten

Am 01.02.2014 23:19, schrieb Aaron Curley:
> Hello,
>
> Over the past few days, I've implemented (very) basic 
> GPShell/GlobalPlatform support for using an NSS token to establish GPSC 
> sessions.  The advantage of NSS support is that the GP secure channel 
> keys can be stored in an HSM (rather than in plaintext in the script 
> files).  Using an HSM to store the GP keys is a requirement for me.
>
> Right now this support is very hackish and only works with SCP01; 
> however, I'm (hopefully) going to be adding SCP02 support over the next 
> few days.  Things are a bit tricky because some of the crypto needs to 
> be migrated to the NSS token, but on the plus side, due to the 
> prevalence of session keys in the GP spec, most of the crypto code can 
> remain openssl (only the session key generation functions need to be 
> duplicated and ported to NSS).
>
> If there's any interest in me sharing this NSS implementation, can I get 
> commit rights?  I'm currently thinking that a separate branch is the 
> best place to put this experimental code.  I'm not sure of the 
> granularity of the access controls you're allowed, but if it's possible 
> to restrict my access to that a new "globalplatform-nss" branch that you 
> create, that'd be fine with me.
>
> Anyways, just let me know if you're interested.
>
> V/r,
> Aaron
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable 
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Globalplatform-developers mailing list
> Glo...@li...
> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers
>

Re: [Globalplatform-developers] Branch for NSS token support

[Aaron C. <ac...@gm...>]

Karsten,

Thanks for the quick reply.  My SF username is accwebs.

My NSS experience is limited so I may be doing things incorrectly; 
however, the path that I'm currently following is to use NSS's PK11 
library.  So, as long as an HSM can be registered as a "slot" in the NSS 
database, I believe the HSM should be able to work with my code.  
Database path and slot name are configurable in the GP shell script 
although I'm still trying to work out the best possible command syntax.

As for libopencryptoki, I *think* that NSS's "internal" slot may be 
implemented by libopencryptoki, so we may be thinking along the same 
lines.  (Unfortunately, NSS's documentation is practically nonexistent 
so its hard to understand its architecture so I can speak intelligently 
on the subject.)

V/r,
Aaron

On 2/1/2014 5:24 PM, Karsten Ohme wrote:
> Hi,
>
> of course this is of interest. Nice would be a generic PKCS#11
> implementation, preferably using libopencryptoki, so every HSM can be
> supported. Could you provide this?
>
> A separate branch created from the trunk is a good idea for the start,
> and if everything is working this can be merged back.
>
> Please send me your SF account and you will get the access to the
> repository.
>
> Thanks,
> Karsten
>
> Am 01.02.2014 23:19, schrieb Aaron Curley:
>> Hello,
>>
>> Over the past few days, I've implemented (very) basic
>> GPShell/GlobalPlatform support for using an NSS token to establish GPSC
>> sessions.  The advantage of NSS support is that the GP secure channel
>> keys can be stored in an HSM (rather than in plaintext in the script
>> files).  Using an HSM to store the GP keys is a requirement for me.
>>
>> Right now this support is very hackish and only works with SCP01;
>> however, I'm (hopefully) going to be adding SCP02 support over the next
>> few days.  Things are a bit tricky because some of the crypto needs to
>> be migrated to the NSS token, but on the plus side, due to the
>> prevalence of session keys in the GP spec, most of the crypto code can
>> remain openssl (only the session key generation functions need to be
>> duplicated and ported to NSS).
>>
>> If there's any interest in me sharing this NSS implementation, can I get
>> commit rights?  I'm currently thinking that a separate branch is the
>> best place to put this experimental code.  I'm not sure of the
>> granularity of the access controls you're allowed, but if it's possible
>> to restrict my access to that a new "globalplatform-nss" branch that you
>> create, that'd be fine with me.
>>
>> Anyways, just let me know if you're interested.
>>
>> V/r,
>> Aaron
>>
>> ------------------------------------------------------------------------------
>> WatchGuard Dimension instantly turns raw network data into actionable
>> security intelligence. It gives you real-time visual feedback on key
>> security issues and trends.  Skip the complicated setup - simply import
>> a virtual appliance and go from zero to informed in seconds.
>> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Globalplatform-developers mailing list
>> Glo...@li...
>> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers
>>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Globalplatform-developers mailing list
> Glo...@li...
> https://lists.sourceforge.net/lists/listinfo/globalplatform-developers