Correct encoding of the Compute signature - Update APDU

[creiter32]

This question concerns the encoding of the Compute signature – Update APDU, precisely the length field of the tag 9Bh (Table 2.10.3.2)

In https://github.com/Orange-OpenSource/IoT-SAFE-APDU-library/blob/master/src/iot_safe_internal.c#L610 I see this is implemented using a fixed width field.

In other implementations (https://github.com/ThalesGroup/iot-safe-middleware/blob/master/iotsafelib/common/src/ROT.cpp#L404) I can see that the length of the data to sign is passed in a variable length encoding.

The IoT Security Applet Interface Description doesn't seem to be clear, if a variable length encoding according to ASN.1 DER (I don't see this mentioned anywhere in the specification) is needed, or if the length is always encoded in 3 bytes (to allow for the maximum specified length of 0xFFFFFF). What is the correct way to encode this?

[ffontaine]

Thanks for your interest in IoT SAFE, the "Full text processing" mode (and so the tag 9Bh) was not tested with the applet of our two partners. We only used the "Pad and sign processing" mode (with the tag 9Eh). Nevertheless, your question is perfectly valid and I'll talk with the GSMA and Thales to clarify this point and update the implementation or the specification accordingly.

[ffontaine]

Just to keep you informed that this point has not been officially answered by the GSMA but I hope that it will be soon.

[creiter32]

I found another issue of the same kind here: https://github.com/Orange-OpenSource/IoT-SAFE-APDU-library/blob/master/src/iot_safe_internal.c#L622

Here the Tag 33h from table 2.10.4.1 can have the range 0x40h to 0x100h, is this supposed to be always 2 bytes?

[ffontaine]

To keep you updated, there is a consensus to say that 9Bh has a fixed length however there is a debate on the actual size: 2 or 3 bytes.

[creiter32]

Hi, thanks for the update.

Just my two cents on this topic, maybe you can take this into the disussion, I think using a fixed length of 2 bytes makes sense for the following reasons:

• If you go for 3 bytes, this is the only place where a type bigger than uint16 is needed
• Javacard by default only has a 16bit (short) type and it's cumbersome to implement a uint24 (some Javacard implementions don't support 32bit (int) types)
• If someone really needs to sign messages bigger than 2^16 bytes, they can move the hashing part to the host and just sign the hash
• The transfer time over UART (ISO7816) for 2^16 is quite significant (several seconds) already

[ffontaine]

Thanks a lot, before reading your arguments, I thought that 3 bytes was better because it was more "future-proof" but that was my only argument. I'll try to push for 2 bytes even if means that the specification, the applet and the middleware will have to be updated. It is probably better to update now than later.