opensc-devel

[Opensc-devel] Motives for OpenSC?

[Anders R. <and...@gm...>]

When I look into the OpenSC mailing list I wonder if something isn't fundamentally broken.

In the end (after provisioning) all smart PKI cards do more or less the same thing;
That is, performs a pretty well standardized RSA or EC operation.

Wouldn't it be a better use of resources defining a standard PKI card where the operating system
vendors provide the *single* driver instead of relying on installation of third-part SW?

With automatic updates (of OS and Token), you wouldn't be stuck with a specific design either.
The static structure of current PKI-tokens is extremely counter-productive.  There are no security
issues doing firmware updates on-the-fly; it just requires a bit more memory in order to be robust.

Naturally this wouldn't stop anybody from continuing creating "unique" cards but
a guess is that these cards would only attract a fraction of the market.

Anders

Re: [Opensc-devel] Motives for OpenSC?

[Andreas S. <and...@ca...>]

Hi Anders,

I fully agree with your position. If you look at the current design of
popular smart card operating systems (other than plain JavaCards), then
these contain an incredible amount of functionality, but only the basic
cryptographic functions and a little PIN management is really used at
the end.

The same for standards: Why should I use a complex PKCS#15 structure to
just describe the obvious: I have a user authentication mechanism, some
administrative authentication, a set of keys and certificates. On the
token/card level I do not need more than what is actually usable at the
PKCS#11 level.

This combined with a secure provisioning interface is what we had in
mind with the SmartCard-HSM design. Keep it simple and stupid - but secure.

The key question is how we get a common interface standard ? This is
something the user rather than the supplier has to do. It doesn't work
for vendor driven ISO standardization, but it works for user driven
standardization like EMV or MRTDs.

Andreas


On 08/17/2013 07:10 AM, Anders Rundgren wrote:
> When I look into the OpenSC mailing list I wonder if something isn't fundamentally broken.
> 
> In the end (after provisioning) all smart PKI cards do more or less the same thing;
> That is, performs a pretty well standardized RSA or EC operation.
> 
> Wouldn't it be a better use of resources defining a standard PKI card where the operating system
> vendors provide the *single* driver instead of relying on installation of third-part SW?
> 
> With automatic updates (of OS and Token), you wouldn't be stuck with a specific design either.
> The static structure of current PKI-tokens is extremely counter-productive.  There are no security
> issues doing firmware updates on-the-fly; it just requires a bit more memory in order to be robust.
> 
> Naturally this wouldn't stop anybody from continuing creating "unique" cards but
> a guess is that these cards would only attract a fraction of the market.
> 
> Anders
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead. 
> Download for free and get started troubleshooting in minutes. 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

Re: [Opensc-devel] Motives for OpenSC?

[Douglas E. E. <dee...@an...>]

On 8/17/2013 12:10 AM, Anders Rundgren wrote:
> When I look into the OpenSC mailing list I wonder if something isn't fundamentally broken.
>
> In the end (after provisioning) all smart PKI cards do more or less the same thing;
> That is, performs a pretty well standardized RSA or EC operation.
>
> Wouldn't it be a better use of resources defining a standard PKI card where the operating system
> vendors provide the *single* driver instead of relying on installation of third-part SW?

This is the same old situation the industry has always had... Vendors have always control the market.

But more recently governments have started setting the standards, and at least one OS vendor,
Microsoft, has defined its own standards. Microsoft supports at least the U.S. gov PIV standard
and its .NET card standard. In both cases, the user is not expected to issue cards, a government
or enterprise is expected to provision the cards.

>
> With automatic updates (of OS and Token), you wouldn't be stuck with a specific design either.
> The static structure of current PKI-tokens is extremely counter-productive.  There are no security
> issues doing firmware updates on-the-fly; it just requires a bit more memory in order to be robust.
>
> Naturally this wouldn't stop anybody from continuing creating "unique" cards but
> a guess is that these cards would only attract a fraction of the market.

And that is where OpenSC comes in, supporting these unique cards on non Windows platforms,
which is a tiny fraction of the market.

>

> Anders
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@an...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

Re: [Opensc-devel] Motives for OpenSC?

[Jean-Michel P. - G. <jm...@go...>]

Le samedi 17 août 2013 à 07:10 +0200, Anders Rundgren a écrit :
> Wouldn't it be a better use of resources defining a standard PKI card
> where the operating system
> vendors provide the *single* driver instead of relying on installation
> of third-part SW? 

As written previously, Microsoft did follow this path and Apple dropped
this approach recently. And OpenSC is mainly for GNU/Linux although it
supports all systems.

Another point is that security devices have a hardware side with
firmware and an OS side. Validating firmware is extremely expensive and
resource consuming. See for example Common Criteria (CC):
http://www.commoncriteriaportal.org/products/

Therefore, moving OpenSC from user-space to kernel space and defining
SPECs for a common smartcard would not change the global amount of work
for vendors.

Nevertheless, I keep your idea in memory, as it could be very
interesting. One interesting point is that small is beautiful. Keeping a
smartcard very simple makes it difficult to attack. And this is the main
point for us at GOOZE.

Kind regards,
-- 
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu