8 Mar
2011
8 Mar
'11
9:09 p.m.
On Tue, Mar 8, 2011 at 6:01 PM, Mad <mad(a)auth.se> wrote:
Some alternatives exist to the approaches outlined above. But we would
need a programmable smart card with support for COMP128-v2.
I've found online some resellers and integrators I'd love to inquire.
I'll do it, when I have time.
Cheers,
alfonso
--
Alfonso De Gregorio
BeeWise - Security Event Futures - http://beewise.org/
On Tue, 8 Mar 2011 16:31:47 +0100, Alfonso De Gregorio
wrote:
Interesting question, how do we know if it's comp128-2 what is being
used by a specific operator?
You need to gain access to EFkey. In theory access to this file should
be forbidden. Yet, it already happened in the past to observe failures
in the way the access control mechanism have been engineered - I'd
love to have with me a link to a research about this, but I'm on the
move and can't find it at the moment.
With the card provisioning, operators store in EFkey: the
authentication algorithm identifier, the key value, a key mask, and an
integrity checksum.
The file format is defined by the manufacturer and varies from model to model.
Looking to the GemXplore 3G reference manual is possible to know that
Gemalto assigns the following algorithm identifiers:
COMP128_V1 0x0040
COMP128_V2 0x00F8
COMP128_V3 0x0044
and stores the EFKey quantities according to the following format:
byte# description
1-2 Algo ID of the algorithm to use
3-18 Key value
19-34 Key mask value
35-36 Integrity checksum =( SUM(byte 1… byte 34) XOR FF)(*)
Access to Ki, via other means, would not be sufficient to distinguish
(by keying a reference implementation) between v2 and v3 of COMP128,
unless the SIM card support only one of them. All other authentication
algorithm in use on second generation networks are public or leaked in
the past, namely: COMP128, Milenage 2G, CAVE, DES, 3DES, XOR.
Actually comp128-2 has a 54bit Kc it seems.
Have you observed a COMP128-2 implementation returning a 54bit long
Kc?, or have you heard about this from somebody else?
Can you please disclose more about the SIM model and the operator
running this A3/A8 implementation? They can use whatever algo they want - or their
equipment vendor provides
- in their sims and auth infrastructure producing deliberately weakened
Kcs.
Yes, they can use whatever key derivation they want and deploy in
their SIM cards and core network, indeed. As a matter of fact,
COMP128-v1 itself was not intended to be prescriptive. Telcos were
expected to select their A3/A8 algorithm of choice. Of course they
didn't, as incentives were no incentives to select anything different
from the algorithm considered during the standardization efforts.
One more
weakened key derivation function (after the first version)
would be interesting per se. Still, it would be even more interesting
to give a closer look at this obscure cipher we carry in our
pockets...
No question, there still are given out sims weakening the anyway broken
a5/1.
Interestingly I observed that operators have mixed occurrence of weak for
one and non-weak Kcs for another sim.
Another possibility is that they are able to determine that for all sims
by choice of the RAND the network sends. So some people, contract-wise,
phone-wise or regions could be easier tapped than others.
But it's just speculation...
The most promising approach after (really) good cryptologists looking at
in- and output is to open up and grinding down a sim chip and taking
pictures to reconstruct its logic, as it has been done with mifare etc.
Aren't there people reading this who are experienced in the latter? Regards,
Mad