OASIS PKCS #11 TC

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

OASIS PKCS #11 TC

Anders Rundgren-2
Here is yet another take on the eternal smart card middleware problem:
https://www.oasis-open.org/committees/document.php?document_id=52364&wg_abbrev=pkcs11

IMO, the only workable solution is standardizing cards.   This may only address 80% of the
market but that is better than nothing.

Anyway while the card community is "thinking"...other much bigger parties are "doing":
http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf

A built-in crypto process on the CPU itself!  That's exactly what is needed!

https://openkeystore.googlecode.com/svn/resources/trunk/docs/tee-se-combo.pdf

Anders

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OASIS PKCS #11 TC

Martin Paljak-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,


On 20/03/14 10:14 , Anders Rundgren wrote:
> Here is yet another take on the eternal smart card middleware
> problem:
> https://www.oasis-open.org/committees/document.php?document_id=52364&wg_abbrev=pkcs11
Thanks
>
for the link.

A nice overview of what OpenSC also tries to do and what it has faced,
nothing really new there. We all know that minidriver sucks the One
Microsoft way and that TokenD sucks the Infinite Apple way. And that
for many situations PKCS#11 provides a more flexible framework, but
with drawbacks (like Linux, with its choices).

> IMO, the only workable solution is standardizing cards.   This may
> only address 80% of the market but that is better than nothing.
And that's what Google is doing with their u2f? To some extent ISO7816
does that. If PKCS#15 failed to deliver, why would a newer standard be
better? A more concrete profile? I'm sure that 80% of people would be
happy with the .net card, given that 80% of people use Windows and
wouldn't care...


> Anyway while the card community is "thinking"...other much bigger
> parties are "doing":
> http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf
>
> A built-in crypto process on the CPU itself!  That's exactly what
> is needed!


TEE (formerly TPM? SecureElement? Many names...) is for sure a really
interesting concept, but has similar properties to an implanted rfid
chip. Really convenient, but many people have understandable dislikes.

While always-connected secure key containers have an important role in
the future, I'm sure, personally I still like to have keys in a "safe
place", unpowered, disconnected, but available if needed.

> https://openkeystore.googlecode.com/svn/resources/trunk/docs/tee-se-combo.pdf



- --
>
Martin
+372 515 6495
-----BEGIN PGP SIGNATURE-----
Comment: Pretty good, eh?

iQEcBAEBCAAGBQJTLylnAAoJEKzwIt3aPjKj1DIIANQKWWQuwBvItQxg0NQNLxC7
dfMygw7VceIokn/2ACQi8832Y0o91qQJGT6slaD29OVJMVvryJG0iGOBj6aHtvzL
QZPFnk3qMoOpttA7+VltFp1rLXzyjdbB/FooHkTS1gM0TzjFb8zSZKDaY2Qt2AR1
sc96lu0sU0p4WgXfpAqfrsPYPFMy5egvR1BTFBw6z+FcAGfZEhK4nCCtshK4b84U
i97HVdLRj8Di3mFwGXt+vWgp6uYlF5P0aFLZEE0FEmWD57gjJmPhiUfQsgeetZMK
UyrqBQQ/7/ZikHHptmBsD4/oeYZ+CfAyTBnLzg1A8i77clRrvpdAqw0Y3L8cX3E=
=jCJe
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OASIS PKCS #11 TC

Anders Rundgren-2
On 2014-03-23 19:35, Martin Paljak wrote:

> Hello,
>
>
> On 20/03/14 10:14 , Anders Rundgren wrote:
>> Here is yet another take on the eternal smart card middleware
>> problem:
>> https://www.oasis-open.org/committees/document.php?document_id=52364&wg_abbrev=pkcs11
> Thanks
>
> for the link.
>
> A nice overview of what OpenSC also tries to do and what it has faced,
> nothing really new there. We all know that minidriver sucks the One
> Microsoft way and that TokenD sucks the Infinite Apple way. And that
> for many situations PKCS#11 provides a more flexible framework, but
> with drawbacks (like Linux, with its choices).
>
>> IMO, the only workable solution is standardizing cards.   This may
>> only address 80% of the market but that is better than nothing.

> And that's what Google is doing with their u2f? To some extent ISO7816
> does that. If PKCS#15 failed to deliver, why would a newer standard be
> better? A more concrete profile? I'm sure that 80% of people would be
> happy with the .net card, given that 80% of people use Windows and
> wouldn't care...

Exactly! It is indeed hard seeing any light in this tunnel when all
vendors, implementers and users don't agree on anything.


>> Anyway while the card community is "thinking"...other much bigger
>> parties are "doing":
>> http://images.apple.com/ipad/business/docs/iOS_Security_Feb14.pdf
>
>> A built-in crypto process on the CPU itself!  That's exactly what
>> is needed!
>
>
> TEE (formerly TPM? SecureElement? Many names...) is for sure a really
> interesting concept, but has similar properties to an implanted rfid
> chip. Really convenient, but many people have understandable dislikes.

In theory such schemes could jeopardize privacy but in practice the
existing systems are much worse, at least when used by "ordinary" users
in contrast to security & privacy experts.

I'm personally uninterested in the latter category since they know how to
protect themselves from various cyber-misfortunes.


> While always-connected secure key containers have an important role in
> the future, I'm sure, personally I still like to have keys in a "safe
> place", unpowered, disconnected, but available if needed.

I may be naive and overly optimistic but AFAICT embedded security containers
have a _potential_ of becoming more secure than external tokens since the
development of traditional tokens is essentially stuck where it was 10 years
ago due to Microsoft's limited understanding of for example on-line banking.

In addition, if you leave a key at home, wouldn't that be a key that you don't
have much use for? I believe securing the frequently used keys is most important.

Anyway since most user have more than 10 keys it isn't realistic carrying those
around not to mention that they integrate pretty poorly with mobile devices.

IMO, it would be better if security folks started to look into embedded tokens
and see how they could be improved rather than dismissing the idea since it
is already pretty obvious that it is unstoppable.

The following is an interesting take on this subject:

https://communities.intel.com/community/itpeernetwork/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display

Personally, I think Intel's solution to trusted path is total nonsense.

Anders

>
>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/tee-se-combo.pdf
>
>
>
>


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel