Extended-Length-Problem

The authentication with the German eID card uses the „Extended Access Control“ protocol according to [BSI-TR3110] as depicted in the following figure. This protocol in particular comprises in step (2) the so called „Terminal Authentication“, where the card-verifiable certificate (cert) of the service provider (eService) is transmitted from the PICC-SAL via the IFD-API according to [ISO24727] and the NFC-stack of the smart phone to the eID card (PICC) in order to be verified with a corresponding VERIFY CERTIFICATE command according to [ISO7816] (part 8, section 11.11).

extendedlength 700

Unfortunately the currently available NFC-enabled smart phones do not support extended length APDUs and consequently the verification of the card-verifiable certificate and hence the entire authentication protocol fails. On Android-based smartphones the supported APDU-length can be determined with the getMaxTransceiveLength function for example. While the typical size of the transmitted certificates is more than 400 Byteshttp://www.openecard.org/framework/extendedlength#_ftn1[1], many currently available smartphones are only able to transmit 261 Byteshttp://www.openecard.org/framework/extendedlength#_ftn2[2] via NFC without major modifications of the operating system.

It remains to hope that future smart phones will be able to support longer APDUs and/or future generations of eID cards will support the so called „Command Chaining“ according to [ISO7816] (part 4, section 5.1.1.1).

 


http://www.openecard.org/framework/extendedlength#_ftnref1[1] The certificates, which are used within the Open eCard demo are 438 bytes (CVCA-certificate), 230 bytes (DV-certificate) and 323 bytes (certificate of the service provider) long.

http://www.openecard.org/framework/extendedlength#_ftnref2[2] Unmodified versions of Samsung S III and Galaxy Nexus phones only support the transmission of 261 bytes via NFC.