fidesmo / apdu-over-ble Goto Github PK

We're not adapting to Max memory for APDU changes.

For a client to say "want SE" and for the server to say "have SE like X". Include connection parameters (like protocol or maximum APDU size, element type etc) in the notification sent for the request.

SE-s are inherently session based stateful things, so an explicit session init (similar to the existing closing method) should exist.

When a peripheral is notifying the client that the APDU responses are ready it needs to retry the notification until it is received. Certain phones seem to miss the notification and then the transaction fails. A sensible retry mechanism seems to be retry every second in total 5 times.

We have a description issue here. Where we first say that memory is set in kilobytes, while later in the payload specification specifying it as Payload: memory (in bytes).

I suppose the correct one is in bytes, as kilobytes will give very rough estimation (and we generally do not much care if memory limit is very big).

WDYT @miguelcardo ?

The BLE interface is comparable to the NFC interface, in high level. By definition, APDU-chat is a command-response pair protocol. In Java terms, the smallest interface to use is byte[] transmit(byte[]), like the relevant Android interface.

Responses to APDU commands, from the secure element, must be checked, depending on context, at earliest point and the only place where this can happen is the caller (not the SE element itself or the BLE server implementation, which have no knowledge of the context of those command-response pairs).

If the BLE interface is implemented against an always connected secure element via T=0, additional commands are to be sent to the secure element when the returned SW is 61XX or 6CXX. This must be documented for APDU handling.

Removing the additional APDU nesting allows to trim the protocol by a few bytes to speed it up slightly.

Good point from @pepegar: In the table we have a length for the Max Memory for APDU processing field specified as <20 bytes and below we define the field value as a 32-bit unsigned integer. Maybe it will be cleaner to directly specify size as 4 bytes then?
Same probably can be applied to the Conversation Finished – we can make it more strict: like let it be 32-bit integer also. So in the future we could use it to return some errors.
@miguelcardo

The "MTU" (minimum transfer unit) size negotiation is already defined in the BLE protocol stack. By default, the size available for data is 20 bytes, but some devices like the iPhone negotiates it automatically and uses the max size supported by the peripheral.

Because the data will be divided in small chunks by BLE internally, we'll have to deal with 3 levels of packets in our implementation:

• APDU fragmentation
• Custom BLE packet fragmentation
• BLE fragmentation

In order to simplify the protocol in future versions, we could evaluate to remove the middle layer (Custom BLE packe fragmentation) and its size negotiation characteristic (Max Memory for APDU processing). In this scenario we only have to send the APDUs and manage the packets with BLE native support.

@miguelcardo @sergkh

Do you have any sample, how to send APDU command to BLE Smartcard reader? I try to do an android application to scan the BLE device and connected it to read all UUID service. But I don't know how to send APDU to collect data from the smartcard. Welcome your comment.

We need to investigate new threats caused by creating a BLE interface towards the NFC and how to eliminate or minimize them. For example, some applications (e.g. U2F) require the user to tap an NFC reader with the token (an NFC card) - the action of tapping the reader can be considered a user presence verification, equivalent to pressing a button on the device. Since BLE can be always on, the U2F confirmation would always be given, thus defeating the purpose of the second authentication factor.

We need to add a channel to pass various HW errors from the device to application.

Some of possible errors are:
• Communication error with chip
• Battery too low
• Busy (e.g. if an NFC transaction is ongoing or similar)