Re: Why the Security Element API should be shelved

Hi Janusz,
Thanx for the input!
I take the liberty to comment your comments :-)

On 2013-07-02 09:14, Janusz Majnert wrote:
> Hi,
> I thought it should work something along the lines: W3C proposes an API 
> -> competing platforms make the API available to UAs by exposing 
> platform libraries -> competing UAs implement the API.
> In this scenario:
> * only the platform vendor needs an NDA, but presumably already has one 
> since the Secure Element HW is used
> * it is the platform vendor that implements the system-level abstraction 
> for the HW (as always)
> * UAs only need to know the W3C API definition and the system-level 
> abstraction API

I think this is the "dividing factor" between Security Element APIs and
most other APIs: The level of abstraction possible is very limited because
the true end-point security-wise should IMHO not be the UA, but the SE.

Why is that? Secure Messaging which is a core feature in most smart cards
cannot [easily] be abstracted as far as I can tell.

That is, the UA would (at least in my take on this subject...), be a
transparent proxy for server-to-SE exchanges.

> I agree that having a "universal" API, like sendAPDU(hexData), is not a 
> good idea. The development of this API should as always be driven by 
> foreseeable use cases and allow for interoperability.

My previous statement about the UA as a transparent proxy may appear as
supporting something like sendAPDU(hexData), but (again in my take on this
subject...), I'm actually advocating a semi-trusted and semi-transparent
proxy which makes a simple SE feasible, while still featuring a nice GUI
and HTTPS communication (aka "heavy lifting").  In such an arrangement
the "APDUs" must be fully known (and readable) by the UA/client platform,
to cope with ASN.1/JSON/XML marshaling/unmarshaling, while secret data and
APDU sequence order is secured through Secure Messaging.

Yes, this is essentially the opposite of an abstract SE API solution...

Regarding Secure Messaging: The smart card industry's methods for creating
Secure Messaging sessions are IMHO not suitable for embedded SEs because
they usually presume a trust/business relationship between service providers
and device vendors which doesn't really work on an Internet scale.

It is quite possible that I'm severely biased since I have developed an
SE-scheme which works as described above :-)  Anyway, the primary motivation
behind this project was the failures of the traditional approaches which
were created in another time and for an entirely different market.

I think that you agree that none of the big vendors would be interested in
openly discussing an SE API, if they had to reveal this much of fairly
intricate information :-)

Well, of course I won't hinder anybody trying in the unlikely event they
actually got a green light from their IP department...

Regards
Anders Rundgren
Senior consultant,
PrimeKey solutions AB

> 
> 
> Regards,
> Janusz Majnert
> Samsung R&D Institute Poland
> Samsung Electronics
> 
> 
> On 2013-07-02 08:38, Anders Rundgren wrote:
>> http://www.fidoalliance.org/faqs.html
>>
>> The FIDO authentication protocol needs to be part of a standardized, interoperable ecosystem to be successful. Building this ecosystem requires the active commitment of everybody from hardware chipset vendors, to the manufacturers of back-end server systems. Coordination across the divergent interests of these players is a complex affair, and one that current technical standards bodies are not well suited to handle.
>>
>> The FIDO Alliance will refine the protocol, and monitor the extensions required to meet market needs and to make the protocol robust and mature. Implementation will not be undertaken by the FIDO Alliance. The mature protocol will be presented to the IETF, W3C or similar body after which it will be open to all industry players to implement.
>>
>> -------------------
>>
>> IMO,  the very same considerations apply to a Security Element API.
>> The current W3C input document does not come with a description of what the anticipated applications are which makes standardization of a possible Security Element API a true guesswork (t appears to be an opaque protocol which by definition is "universal" but that's hardly going to make it particularly interoperable).
>>
>> The lack of a discussion around these issues is also an indication that something is missing from the plot.   It might be "interest", but it may also be "openness".
>> In fact, just getting the datasheet for most Security Elements including the one embedded in many high-end Android phones requires a signed NDA!
>>
>> True standardization is probably at least 5 years down the road and there will be multiple and competing standards as well.
>> FIDO Alliance will presumably provide one of the candidates although standardization at this stage will essentially be a formality.
>>
>> Don't get me wrong; standardization is great but some targets aren't suited for standardization.
>>
>> Anders
>>
>>
> 
> 
> 
>

Received on Tuesday, 2 July 2013 09:33:27 UTC