RE: Secure Element API: preliminary draft

Hi Olivier,

Sorry for late reply, I was very busy. Thank you for your answers, I have
few answers and comment for you, please find it inline. 

 

Best regards,

Marta

 

From: POTONNIEE Olivier [mailto:Olivier.POTONNIEE@gemalto.com] 
Sent: Thursday, November 28, 2013 3:34 PM
To: Marta Pawlowska
Cc: GALINDO Virginie; public-sysapps@w3.org
Subject: 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
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.

[Marta] Yes, I would like to make it more clear in 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

 

[Marta] Thank you J

 

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

 

[Marta] I overlooked it somehow, agree this is covered J

 

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

 

[Marta] I'm not sure if we should mask it for an application. Do we want to
change data? Maybe it would be better to put this responsibility on
application so we check it only and trough an error "invalid parameter" if
it is incorrect?

 

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.

 

[Marta] I like an idea of automatic closing session and channel. We also
could add specific event sent to application with notification that it was
closed automatically due to connection lost. What do you think?

 

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.

[Marta] This is just my curiosity ;). 

I meant here only time constrains. Why? I'm wondering if it will be quick
enough to get certification? I'll try to find the detail about timing, but
afaik native devices has problem with that. I'm consider scenario when card
is connected in distributed architecture like with external device connected
via Bluetooth. 

 

 

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

 

[Olivier] They are very welcome J 

 

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

 

 

  _____  

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