RE: Secure Element API: preliminary draft

Thanks Marta for your comments, we will come back to you soon.
Regards,
Virginie
gemalto

From: Marta Pawlowska [mailto:m.pawlowska@samsung.com]
Sent: vendredi 15 novembre 2013 18:30
To: POTONNIEE Olivier; GALINDO Virginie
Cc: public-sysapps@w3.org
Subject: Secure Element API: preliminary draft


Dear Olivier and Virginie,

I've read your draft and I have few comments and questions.


A.      Render Interface
A.1 openSession()
a. Is it possible to have server sessions open at the same time?

b. You wrote that session MUST NOT lock access to the secure element. However from *SMART CARDS* point of view (e.g. in cases of EMV) you need to actually guarantee an exclusive access to secure element for transaction. Why? You can't make two transaction at the same time.

Proposition for solution:

-          Add method "openExclusive()" that will lock secure element for session

-          Add parameter that  (when true) will lock secure element for session



B.      Session Interface
B.1 openBasicChannel()
a. Is openBasicChannel the same as *SELECT* from ISO 7816-4? (EMV command 00A4)
b. If *YES*, how to perform selection like this on Smart cards with multiple applications? Standard EMV for Samart Cards allow to select multiple applications, not just only first one. EMV needs to build whole application tree before actually allow user to select application.
According to openBasicChannel description we can open only one application at once therefore when trying to build application tree (EMV smart card) user would need to open channel and close in a loop which is not very handy.
                B.2 close()
a. Why we can't close only one channel? Why we must close all channels? I do not know real use case, but I can imagine that I would like to have open Basic Channel and just  for checking something in logical channel, then close only this logical channel.


C.      Channel Interface
C.1 transmit() - it does not allow to use select, therefore I assume openBasicChannel is equal to select.


D.      SE Command Interface
D.1 CLA

a.       cla - byte cla (ISO7816) this is channel number

If I open channel somewhere else, what happens when I put here byte from different (nor currently used/wrong) channel? Who returns the error? How this error will be handled and passed to web application?

D.2 LC (missing description in spec) - data field length
a. In most Smart Cards LC = 1 byte (Simple LC)
b. How do you want to count data field length? Do you plan to count it automatically?
If *YES* how library will know if Smart Card supports Enhanced LC (3 bytes) or not? How library will know to to encode it on 1 or 3 bytes? Smart Card does not process the data if LC is encoded incorrectly.  (Most Smart Cards does not support Enhanced LC, but there are one that does support it.)

D.3 short LE - expected response data length

a. short LE = 2 bytes, which means you want to use enhanced LE, however most Smart Cards supports only Simple LE (1 byte).


E.       General comments

a.       Assuming Card will be removed from slot or Wi-fi will connection will be lost, I understand we get onSEremoval, what about open Channels? Who should close the channels? What about Secure Element object? Should we use close() or it will be done somehow else?

b.      Just out of curiosity, have you considered: cards NFC (possibly EMV) how fast it will work? Contactless Smart Cards have very strict limist about response and transaction times.


Please let me know your opinion and comments about my comments ;)

Best regards,
Marta


[cid:image001.png@01CEE47D.23015D60]


Marta Pawlowska
Samsung R&D Institute Poland
Samsung Electronics
Office +48 22 377 9562
Cell +48 664 750 224
m.pawlowska@samsung.com<mailto:m.pawlowska@samsung.com>


________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus