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@01CE518C.41DEB9F0

 

 

Marta Pawlowska

Samsung R&D Institute Poland

Samsung Electronics

Office +48 22 377 9562

Cell +48 664 750 224

m.pawlowska@samsung.com