[WebCrypto.Next] Rethinking the 7816/APDU SE interface

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

[WebCrypto.Next] Rethinking the 7816/APDU SE interface

Anders Rundgren-2
Originally sent to: http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0022.html
-------------

I have sort of "dissed" the idea to making a 7816/APDU-level SE-interface
for the web.  Still, Mozilla is building such a thing for Firefox OS.

After thinking a bit more on this, I believe we are both right!

Firefox OS is a "Web OS" and therefore everything is exposed through
web interfaces but that doesn't necessarily mean that the same methods
must be used in for example Android. In fact, probably all of the myriad of
payment apps available for Android are based on the native (Java) API.

AFAICT  the only applications that actually *need* to operate at the 7816/APDU-
level do it through NFC which in turn can be driven by whatever the platform offers.

That the Google Wallet or Apple Pay would
    1. be rewritten as web apps
    2. be 100% portable and thus be distributed from a single source is a cool idea
but it won't happen for a bunch of reasons (even including aesthetics and branding),
and therefore there's no point *standardizing* a web-based 7816/APDU API.

No, we won't be able making EMV-payments on the traditional web but there's
no need for that either; the WebCrypto API (with proper backing) is entirely
sufficient and much better suited for web-payments than schemes that were
designed for local usage in specific certified payment terminals. Since the
WebCryoto API isn't really there yet, I suggest that we continue on that path
instead of trying to compete with something which is already working and
close to being established.

Cheers,
AndersR



------------------------------------------------------------------------------
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: [WebCrypto.Next] Rethinking the 7816/APDU SE interface

Frank Morgner
FFxOS is still a year or two away from an APDU interface. I think they
have planned this feature for 2.1. Today we don't even have a final
release of 1.3 as far as I know. Anyway, this still looks interesting
since direct USB access for web application is currently built into
chromium, which in the end also allows sending raw APDUs.

All that is left is to compile opensc with emscripten and suddenly you
have a web application with access to traditional pkcs#11 tokens...
(chromium's application would additional need to compile pcsc-lite and
libccid with emscripten)

On Thursday, October 16 at 08:00AM, Anders Rundgren wrote:

> Originally sent to: http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0022.html
> -------------
>
> I have sort of "dissed" the idea to making a 7816/APDU-level SE-interface
> for the web.  Still, Mozilla is building such a thing for Firefox OS.
>
> After thinking a bit more on this, I believe we are both right!
>
> Firefox OS is a "Web OS" and therefore everything is exposed through
> web interfaces but that doesn't necessarily mean that the same methods
> must be used in for example Android. In fact, probably all of the myriad of
> payment apps available for Android are based on the native (Java) API.
>
> AFAICT  the only applications that actually *need* to operate at the 7816/APDU-
> level do it through NFC which in turn can be driven by whatever the platform offers.
>
> That the Google Wallet or Apple Pay would
>     1. be rewritten as web apps
>     2. be 100% portable and thus be distributed from a single source is a cool idea
> but it won't happen for a bunch of reasons (even including aesthetics and branding),
> and therefore there's no point *standardizing* a web-based 7816/APDU API.
>
> No, we won't be able making EMV-payments on the traditional web but there's
> no need for that either; the WebCrypto API (with proper backing) is entirely
> sufficient and much better suited for web-payments than schemes that were
> designed for local usage in specific certified payment terminals. Since the
> WebCryoto API isn't really there yet, I suggest that we continue on that path
> instead of trying to compete with something which is already working and
> close to being established.
>
> Cheers,
> AndersR
>
>
>
> ------------------------------------------------------------------------------
> 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
>
--
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: [WebCrypto.Next] Rethinking the 7816/APDU SE interface

Anders Rundgren-2
On 2014-10-16 17:02, Frank Morgner wrote:

> FFxOS is still a year or two away from an APDU interface. I think they
> have planned this feature for 2.1. Today we don't even have a final
> release of 1.3 as far as I know. Anyway, this still looks interesting
> since direct USB access for web application is currently built into
> chromium, which in the end also allows sending raw APDUs.
>
> All that is left is to compile opensc with emscripten and suddenly you
> have a web application with access to traditional pkcs#11 tokens...
> (chromium's application would additional need to compile pcsc-lite and
> libccid with emscripten)

You can indeed do that but such web-applications require the same kind
of security and installation measures as native applications and then
you have (IMO) lost most of the point with the web.

Google's U2F does not require such measures because it was designed for
the web in the first place.  I'm proposing that future standardization
efforts should continue this path and leave APDU's to native applications.

Anders

>
> On Thursday, October 16 at 08:00AM, Anders Rundgren wrote:
>> Originally sent to: http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0022.html
>> -------------
>>
>> I have sort of "dissed" the idea to making a 7816/APDU-level SE-interface
>> for the web.  Still, Mozilla is building such a thing for Firefox OS.
>>
>> After thinking a bit more on this, I believe we are both right!
>>
>> Firefox OS is a "Web OS" and therefore everything is exposed through
>> web interfaces but that doesn't necessarily mean that the same methods
>> must be used in for example Android. In fact, probably all of the myriad of
>> payment apps available for Android are based on the native (Java) API.
>>
>> AFAICT  the only applications that actually *need* to operate at the 7816/APDU-
>> level do it through NFC which in turn can be driven by whatever the platform offers.
>>
>> That the Google Wallet or Apple Pay would
>>      1. be rewritten as web apps
>>      2. be 100% portable and thus be distributed from a single source is a cool idea
>> but it won't happen for a bunch of reasons (even including aesthetics and branding),
>> and therefore there's no point *standardizing* a web-based 7816/APDU API.
>>
>> No, we won't be able making EMV-payments on the traditional web but there's
>> no need for that either; the WebCrypto API (with proper backing) is entirely
>> sufficient and much better suited for web-payments than schemes that were
>> designed for local usage in specific certified payment terminals. Since the
>> WebCryoto API isn't really there yet, I suggest that we continue on that path
>> instead of trying to compete with something which is already working and
>> close to being established.
>>
>> Cheers,
>> AndersR
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
>


------------------------------------------------------------------------------
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