Re: A briefing on the W3C SE API

On 2014-04-12 21:03, Kumar McMillan wrote:
> On Apr 12, 2014, at 1:27 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>
>> To get some feeling for the difficulties combining traditional smart cards and browsers, you may take a peek at:
>> http://lists.w3.org/Archives/Public/public-sysapps/2014Apr/0057.html
>>
>> I feel pity for Mozilla who bought into this API which also suffers from the "minor" snag that SIM-cards cannot be used except through cooperation with operators.
> Actually, it’s the operators who are proposing a patch for the SE web API to Firefox OS right now (not Mozilla) because they are partnering with Mozilla to bring devices to market. As I understand it, this effort isn’t to solve the problem in a new [and better] way it’s to make Firefox OS connect to the secure elements that are already going to be built into these devices anyway. As I also understand it, no one in Mozilla’s security group is particular excited about it.

Security elements that are going to be built into the devices anyway?  This sounds pretty strange in my ears at least compared to what Google, Apple and Microsoft are doing with embedded security solutions which AFAIK have no connections whatsoever to GP and 7816.

I thought the SE API was for enabling the SIM in new applications which is a fair idea but IMO carried out in a poor way.  Why is that?  Since they (SIMAlliance and Operators) haven't come up with a specific "Mobile Profile", applications like VPNs will require SIM-specific middleware to work.   That the OpenSC project continues year after year doesn't come as a surprise.  It's a virtual consultant paradise out there!

Most of the mentioned security problems are actually due to the lack of an SE architecture designed for the web.

Some of these issues also stem from the fact that the smart card industry seem to have a problem with the idea that security applications execute in the platform rather than in dedicated Java applications stored in the SE.  The latter is natural for "cards" but hardly for "devices".   In a device secure keys and basic cryptographic operations should be sufficient.  If the platform is broken, the SE won't help much.

The server side isn't unaffected either.   Personally, I'm unconvinced that application developers appreciate working with low-level smart card commands if they could rather use WebCrypto, PKCS #11, JCE, etc.

Anders


>> Banks and operators are not the most obvious bedfellows, IMO it is rather the opposite.
>>
>> Apple, Google and Microsoft have so far not commented on this API which is sort of understandable since they have already invested in embedded security hardware which is much easier to deal with.   Of course without any coordination whatsoever.
>>
>> I.e. this topic is effectively out of scope for true standardization.  Microsoft and the US government once had a chance coming up with a universal solution when the FIPS201/PIV standard was designed.  However, the smart card vendors kept the most interesting part for themselves (initialization) which the mildly put non-visionary NIST folks didn't realize would make their great standard useless for the private sector like banks who simply cannot motivate spending $200+ per seat for a "Security Solution".  The rest is history with an endless series of security breaches due to the use of unauthenticated credit-card numbers.
>>
>> Due to this situation I feel pretty OK continuing with the Firefox WebCrypto extension ( https://bugzilla.mozilla.org/show_bug.cgi?id=978867 ).  And if someone finds a better mousetrap?  Well, that's life :-)
>>
>> thanx,
>> Anders
>>
>>

Received on Monday, 14 April 2014 11:26:11 UTC