Strange USIM response to READ RECORD command

[Jouni Malinen]

On Thu, Dec 15, 2011 at 01:55:19AM +0100, Simon Baatz wrote:
> when trying to get the identity (i.e. the IMSI) for EAP-AKA from the
> USIM, the USIM I use here responds in a way which is unexpected by the
> scard_get_record_len function in pcsc_funcs.c.
> 
> If I read ETSI TS 102 221 correctly, the UICC should respond with '6c
> <length>' if the Le is 0 or greater than the real length.
> scard_get_record_len sets Le to 255. However, the response is '67
> <length>' ( 'incorrect parameter P3'?) and not '6c <length>':

ETSI TS 102 221 does not seem very clear on the exact requirements here.

> SCARD: scard_transmit: send - hexdump(len=5): 00 b2 01 04 ff
> SCARD: scard_transmit: recv - hexdump(len=2): 67 16
> SCARD: file length determination response - hexdump(len=2): 67 16
> 
> If I change Le to be 0, then the expected answer is returned:
> 
> SCARD: scard_transmit: send - hexdump(len=5): 00 b2 01 04 00
> SCARD: scard_transmit: recv - hexdump(len=2): 6c 16
> SCARD: file length determination response - hexdump(len=2): 6c 16

Interesting. I would not have expected this type of difference. Anyway,
67 XX is marked as a possible status condition for READ RECORD, so it
sounds reasonable to accept the 0x67 version, too, as the length.

> Thus, the UICC seems to handle the two cases differently. I am not an
> expert for UICC/SIM/USIM and thus, I am unsure whether the problem is in
> the UICC or the code.
> Nevertheless, what is the correct fix/workaround for this? Should we set
> Le to zero, or should we also accept '67 <length>' as a response here?

I guess it would be fine to use Le=0. However, I would rather not change
that without going through a thorough testing with number of SIM cards
(and I don't have time to do that now). Accepting 0x67 as an alternative
response here seems like the safest option and that's what I pushed into
hostap.git.

-- 
Jouni Malinen                                            PGP id EFC895FA