RE: Secure Element API: preliminary draft

Marta,
Thanks again for your feedback, it helps to refine the proposal.
Please find our responses below:

From: Marta Pawlowska [mailto:m.pawlowska@samsung.com]
Sent: Friday, November 15, 2013 6:30 PM
To: POTONNIEE Olivier; GALINDO Virginie
Cc: public-sysapps@w3.org<mailto: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?

[Olivier] Yes, multiple sessions may be 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



[Olivier] A session is just a "handle" on the secure element, it is not sufficient to interact with an secure element application. For this, you need to open a channel. AFAIK, the "exclusivity" is only relevant at application level, I don't know any scenario where you need to get exclusivity on the whole secure element.

The exclusivity should be guaranteed by the API implementation at channel level: once an application gets a channel, no one else can get it as long as the application doesn't close it.



B.      Session Interface
B.1 openBasicChannel()
a. Is openBasicChannel the same as *SELECT* from ISO 7816-4? (EMV command 00A4)

[Olivier] Yes, except for one case: if aid is null, then we open the channel on the default selected application (which is automatically selected on secure element activation), hence no select is sent. Maybe this should be made clearer in the spec.

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.

[Olivier] You are right, there is something missing in the proposal: it must support the select [next] operation. This will allow to do the initial select on partial AID, and from the obtained channel the selectNext() method would allow to iterate on the matching instances (this is the way it is handled in the last OpenMobile API version), without knowing the full aid, and without calling the close() method. Thanks for pointing this out.
I opened an issue to keep track of this: https://github.com/opoto/secure-element/issues/1

                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.

[Olivier] To close a single channel, you can invoke the close() method on the channel object. The close() method on the session closes all underlying channels (following the hierarchical structure illustrated in section 5).


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

[Olivier] Correct, with the restriction I mentioned.


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?

[Olivier] What do you mean by "elsewhere"? The channel number set by application in CLA will be ignored/masked by the transmit() implementation, which will replace it with the channel number assigned to this channel (on logical channels, the application doesn't even know the channel number).
Regarding error handling, if the application passed an invalid argument then the transmit() implementation will send the "invalid_value" SEError to the application (through a promise).

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

[Olivier] LC is not given as it can be computed based on the passed data size. Depending on the size, the transmit() implementation will encode it on 1 or 3 bytes. It is the responsibility of the application to only send data size that is supported by the secure element.


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

[Olivier] Same as LC: depending on LE value, the transmit implementation will encode it on 1 or 3 bytes.


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?

[Olivier] Yes, onSEremoval will be triggered when connection to secure element is lost: smart/SD card unplugged, NFC card out of field, etc. (and possibly WiFi if this is how you connect to your Secure Element ;)
I agree the behavior is underspecified in the current version. The idea is that channels and sessions are automatically closed, similarly to what would be achieved if the application calls Reader.close(). Inovking any operation on these Session and Channel objects would return the "closed" SEError. The Reader and SecureElementManager objects would however still be usable by the application to open new sessions with new secure element.
The case of removable readers is not specifically covered by this spec. I'm not sure if it should.


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.

[Olivier] So far we don't see any reason why this API would not make it possible to comply to the EMV constraints.

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

[Olivier] They are very welcome :)

Best regards,
Marta


[cid:image001.png@01CEEC24.C7541FC0]


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