search

Orange-OpenSource / IoT-SAFE-APDU-library

APDU library to communicate with a GSMA IoT SAFE applet ( https://www.gsma.com/iot/iot-safe)
BSD 3-Clause "New" or "Revised" License
21 stars 13 forks source link

2.21 Read file, SW inconsistencies #4

Open creiter32 opened 3 years ago

creiter32 commented 3 years ago

Hi,

I have a question and a suggestion regarding the Read file command:

1) Why are there two status words with the meaning of Offset out of bounds ? Table 2.21.4.2 defines both 6981h and 6A86h for this. For 6981h Read file is even the only place where this status code is used.

2) Is more of an suggested improvement, to avoid cases like this: https://github.com/Orange-OpenSource/IoT-SAFE-APDU-library/commit/66553cd5799c4907e3f27489736fe85b82c78ac1

I think the specification of the command would be more useful, if read file returns 6300h More data available as long as the end of the file has not been read and dropping the part "and returns 256 bytes or less if it reaches the end file" as that size is more limited in practice. Thus the Le parameter could be used to specify the number of bytes to read and be compliant to the IoT SAFE specification.

ffontaine commented 3 years ago

Hi, thanks for your question, I'll try to get an answer from the GSMA.

Concerning https://github.com/Orange-OpenSource/IoT-SAFE-APDU-library/commit/66553cd5799c4907e3f27489736fe85b82c78ac1, the issue was not related to the IoT SAFE applet but to the modem. With the same applet, I had a behavior difference between the Arduino MKR NB 1500 (u-blox modem) and the GMS01Q. On u-blox, if the response is greater than the buffer, a 61h response is sent. However, on GMS01Q, if the response is greater than the buffer, the response is just truncated. The response is not even correct as the return code is not present. I'm not an expert in applet/modem development but it seems that the management of the response length is handled by the modem and not by the applet. However, you're right that the specification should be used to specify that Le should be used to specify how many bytes should be returned.

creiter32 commented 3 years ago

Yes, I saw that this is a problem with this particular modem, but in the relevant standards for smartcards/eSIMs I didn't find any statement that APDUs with maximum length must be supported. This could be problematic for the portability of the IoT SAFE applet in general.

fitho1 commented 3 years ago

Please note that this issue also effects other APDU commands with output chaining, especially "Compute Signature Update", "Read Public Key", and "Get Data - Object List". There the maximum output length is also currently fixed to 256 bytes (Le = 0). It would be good to have a consistent approach for all these commands.

ffontaine commented 3 years ago

Thanks for your feedback, it will be discussed on next GSMA IoT SAFE meeting. Following their feedback, I'll update the code.

fitho1 commented 3 years ago

An additional suggestion that might improve and simplify the IoT SAFE specification: The "Read File" command could also be used to read the content of public keys. If so, the "Read Public Key" command could be removed. (Currently, the "Read Public Key" command uses output chaining, which requires the Applet to store state (including the currently selected public key ID or label, and the current data offset), even though the command does not use a "Session".)