State of card drivers

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

State of card drivers

Frank Morgner
Hey guys!

I see we have a number of pull requests hanging concerning new card
drivers. We have some internal card drivers that don't seem to have a
maintainer. We have seen errors in OpenSC that could be exploited by a
rouge smart card.

Still, we don't seem to have a clear policy about new code in OpenSC.
Here is what I would suggest regarding the card driver level (which I
know relatively good):

    Only mature drivers with active maintainers should be loaded by
    default.

This means that

1. All new card drivers belong into a separate driver library that is
  *not* loaded together with all internal drivers.

  I this would allow us to faster accept contributions (but it would
  still require changes for the existing pull requests).

2. Old drivers need to be reviewed. If there is no maintainer, the
   driver needs to be separated and disabled by default.

   I would work on this from time to time, I invite others to do the
   same.

3. Automatic tests need to be applied for drivers that are enabled by
   default.
   
   @Victor Is your smart card farm still up an running? Where can we
   check whether all of the cards are still working?

Loading external card drivers is already built into OpenSC so
refactoring the existing code should be relatively easy. Having an
external driver would also comply with the feeling of most contributors
that think that the card driver allows him to do everything he wants
(which sometimes is implementing core functionality over and over
again).

Also, we need to look at OpenSC as software that implements security.
Even though it does not deal with keys directly, it still defines what
you actually *do* with the keys stored on your card.


--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of card drivers

Douglas E Engert


On 10/20/2014 3:34 PM, Frank Morgner wrote:

> Hey guys!
>
> I see we have a number of pull requests hanging concerning new card
> drivers. We have some internal card drivers that don't seem to have a
> maintainer. We have seen errors in OpenSC that could be exploited by a
> rouge smart card.
>
> Still, we don't seem to have a clear policy about new code in OpenSC.
> Here is what I would suggest regarding the card driver level (which I
> know relatively good):
>
>      Only mature drivers with active maintainers should be loaded by
>      default.
>
> This means that
>
> 1. All new card drivers belong into a separate driver library that is
>    *not* loaded together with all internal drivers.
>
>    I this would allow us to faster accept contributions (but it would
>    still require changes for the existing pull requests).

Maybe, but may be overkill. The how to you make it an internal driver
at some time?

>
> 2. Old drivers need to be reviewed. If there is no maintainer, the
>     driver needs to be separated and disabled by default.
>
>     I would work on this from time to time, I invite others to do the
>     same.

We need to consider the users, not just developers. How can we make it easier
for a user to turn on a driver that we fell is obsolete. We need some
feed back from users that a driver is still in use, even if its  just comments
in opensc.conf to e-mail us that it is still being used, and especially
if it is being used by some organization, and not just one person.

>
> 3. Automatic tests need to be applied for drivers that are enabled by
>     default.
>
>     @Victor Is your smart card farm still up an running? Where can we
>     check whether all of the cards are still working?
>
> Loading external card drivers is already built into OpenSC so
> refactoring the existing code should be relatively easy. Having an
> external driver would also comply with the feeling of most contributors
> that think that the card driver allows him to do everything he wants
> (which sometimes is implementing core functionality over and over
> again).
>
> Also, we need to look at OpenSC as software that implements security.
> Even though it does not deal with keys directly, it still defines what
> you actually *do* with the keys stored on your card.
>

  True.

>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: State of card drivers

Frank Morgner
On Tuesday, October 21 at 07:27AM, Douglas E Engert wrote:

>
>
> On 10/20/2014 3:34 PM, Frank Morgner wrote:
> > Hey guys!
> >
> > I see we have a number of pull requests hanging concerning new card
> > drivers. We have some internal card drivers that don't seem to have a
> > maintainer. We have seen errors in OpenSC that could be exploited by a
> > rouge smart card.
> >
> > Still, we don't seem to have a clear policy about new code in OpenSC.
> > Here is what I would suggest regarding the card driver level (which I
> > know relatively good):
> >
> >      Only mature drivers with active maintainers should be loaded by
> >      default.
> >
> > This means that
> >
> > 1. All new card drivers belong into a separate driver library that is
> >    *not* loaded together with all internal drivers.
> >
> >    I this would allow us to faster accept contributions (but it would
> >    still require changes for the existing pull requests).
>
> Maybe, but may be overkill. The how to you make it an internal driver
> at some time?
An internal driver should be robust and tested. We can't really tell
this from a new piece of code just by looking at it. One would need
actual cards to run meaningful tests. Currently I don't even know which
of the existing drivers are tested that way. Anyway, only time will tell
if a (new) driver introduces security problems. That's why I'd rather
deactivate it by default. How about waiting one or two release cycles
before changing opensc.conf to activate the external driver by default
(note that no code change is required to do this)?

> > 2. Old drivers need to be reviewed. If there is no maintainer, the
> >     driver needs to be separated and disabled by default.
> >
> >     I would work on this from time to time, I invite others to do the
> >     same.
>
> We need to consider the users, not just developers. How can we make it easier
> for a user to turn on a driver that we fell is obsolete. We need some
> feed back from users that a driver is still in use, even if its  just comments
> in opensc.conf to e-mail us that it is still being used, and especially
> if it is being used by some organization, and not just one person.
I consider new card driver as experimental features that still need
testing. From a security point of view it would not very wise to
activate all this by default (for users *and* developers). I think
editing a file is as minimal configuration as it gets. Maybe one could
add some clickable application for Windows users ;-)

> > 3. Automatic tests need to be applied for drivers that are enabled by
> >     default.
> >
> >     @Victor Is your smart card farm still up an running? Where can we
> >     check whether all of the cards are still working?
> >
> > Loading external card drivers is already built into OpenSC so
> > refactoring the existing code should be relatively easy. Having an
> > external driver would also comply with the feeling of most contributors
> > that think that the card driver allows him to do everything he wants
> > (which sometimes is implementing core functionality over and over
> > again).
> >
> > Also, we need to look at OpenSC as software that implements security.
> > Even though it does not deal with keys directly, it still defines what
> > you actually *do* with the keys stored on your card.
> >
>
>   True.
>
--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

attachment0 (985 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: State of card drivers

Douglas E Engert


On 10/22/2014 10:22 AM, Frank Morgner wrote:

> On Tuesday, October 21 at 07:27AM, Douglas E Engert wrote:
>>
>>
>> On 10/20/2014 3:34 PM, Frank Morgner wrote:
>>> Hey guys!
>>>
>>> I see we have a number of pull requests hanging concerning new card
>>> drivers. We have some internal card drivers that don't seem to have a
>>> maintainer. We have seen errors in OpenSC that could be exploited by a
>>> rouge smart card.
>>>
>>> Still, we don't seem to have a clear policy about new code in OpenSC.
>>> Here is what I would suggest regarding the card driver level (which I
>>> know relatively good):
>>>
>>>       Only mature drivers with active maintainers should be loaded by
>>>       default.
>>>
>>> This means that
>>>
>>> 1. All new card drivers belong into a separate driver library that is
>>>     *not* loaded together with all internal drivers.
>>>
>>>     I this would allow us to faster accept contributions (but it would
>>>     still require changes for the existing pull requests).
>>
>> Maybe, but may be overkill. The how to you make it an internal driver
>> at some time?
>
> An internal driver should be robust and tested. We can't really tell
> this from a new piece of code just by looking at it. One would need
> actual cards to run meaningful tests. Currently I don't even know which
> of the existing drivers are tested that way. Anyway, only time will tell
> if a (new) driver introduces security problems. That's why I'd rather
> deactivate it by default. How about waiting one or two release cycles
> before changing opensc.conf to activate the external driver by default
> (note that no code change is required to do this)?

OK, I was also thinking about old card drivers that are not maintained,
and may not even be used anymore. How do we get rid of them?

>
>>> 2. Old drivers need to be reviewed. If there is no maintainer, the
>>>      driver needs to be separated and disabled by default.
>>>
>>>      I would work on this from time to time, I invite others to do the
>>>      same.
>>
>> We need to consider the users, not just developers. How can we make it easier
>> for a user to turn on a driver that we fell is obsolete. We need some
>> feed back from users that a driver is still in use, even if its  just comments
>> in opensc.conf to e-mail us that it is still being used, and especially
>> if it is being used by some organization, and not just one person.
>
> I consider new card driver as experimental features that still need
> testing. From a security point of view it would not very wise to
> activate all this by default (for users *and* developers). I think
> editing a file is as minimal configuration as it gets. Maybe one could
> add some clickable application for Windows users ;-)
>
>>> 3. Automatic tests need to be applied for drivers that are enabled by
>>>      default.
>>>
>>>      @Victor Is your smart card farm still up an running? Where can we
>>>      check whether all of the cards are still working?
>>>
>>> Loading external card drivers is already built into OpenSC so
>>> refactoring the existing code should be relatively easy. Having an
>>> external driver would also comply with the feeling of most contributors
>>> that think that the card driver allows him to do everything he wants
>>> (which sometimes is implementing core functionality over and over
>>> again).
>>>
>>> Also, we need to look at OpenSC as software that implements security.
>>> Even though it does not deal with keys directly, it still defines what
>>> you actually *do* with the keys stored on your card.
>>>
>>
>>    True.
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel