A fairy tale about ICCIDs, IMSIs and iPads
One of the big news of the last week is AT&T's leak of 114,000 iPad customer records including the e-mail address and ICCID
While that leak is certainly a big issue in itself, there are some people,
most notably Chris Paget, who
claim that this is much more serious than generally assumed. The main
claim here seems to be that ...in order to translate an ICCID into an IMSI,
you need to query the HLR.
I have been reading GSM protocol specifications on every level for the past
years, and never have I seen the ICCID being mentioned anywhere. The GSM
specifications do not require this information to be stored in the HLR, and
the MAP protocol (used on the C interface between MSC and HLR, see 3GPP TS 29.002)
does not even know how to encode/specify it.
Also, there is no technical need for it. The ICCID is never used nor needed
in any part of the GSM protocol. Also, the GSM network typically doesn't store
any information that is not absolutely necessary for its operation. The only
identifier of a SIM card that the network protocols care about is the IMSI.
So unless the US operators in question have either some kind of proprietary
extensions to both their HLR and the MAP protocol, there is to the best of
my knowledge no way how you can relate the ICCID to the IMSI.
And thus, as a result, the IMSI-catcher attack described will not work since
you don't know the IMSI of the SIM card (associated with the customer record)
that you want to catch.
If anyone can show me hard technical facts about ICCIDs being used in the HLRs
of the operators in question, I am happy to post here I was wrong. Otherwise,
I would hope everyone else could also come down to the hard technical facts,
i.e. which particular MAP message is used for this alleged ICCID-to-IMSI query.
UPDATE: As some people have discovered, the three US operators
themselves have decided that they use the same
number to generate both the ICCID and the IMSI. So if you have one, you
can compute the other. No need for HLR access, no need for the MAP protocol.
So the information leak is in fact unrelated to the GSM protocol but simply a
matter of how unfortunate those particular three operators assign their unique
identifiers.
More thoughts on FSF action against Apple over GNU Go
Last week, I blogged about the FSF action against Apple. This week, I intend to add a bit to that.
As it has been pointed out to me, Apple has immediately removed the GPL-infringing
software from its app store. This of course means they have refrained from
further infringing the GPL. It is not publicly known if they have made a
declaration to cease and desist or not.
So yes, by removing the software that was distributed in violation of the GPL
terms, Apple has done legally the right thing: Reduce the danger/risk of
committing further (knowing) infringement.
The FSF (and probably the Free Software community in general) of course want
something else: For Apple to alter their app store terms in a way that would
enable software authors to have Apple distribute their GPL licensed software
in it. While this might be possible very easily with small modifications to
their legal terms and to the implementation of the app store, it is probably
not quite easy to make a legal claim and try to force this upon Apple.
Anyone always has the choice to either distribute GPL licensed software
compliant with its license terms - or not distribute it at all. If Apple
prefers the latter, this is very unfortunate (and you might call it anti-social
or even anti-competitive) but something that they can very well do.
The only questions that I see remaining from a legal point of view: What about
the previous GPL infringements? What can (and/or has) Apple to do in return
to the previous distribution of infringing software? This is where the legal
pressure of the copyright holders leaves room for negotiation. Instead of
monetary damages (which don't really resolve what the GPL aims to do), there
could possibly be a solution where Apple has to provide the GPL license text and complete corresponding source code to the Go program through their app store.
And while they're at it, they might just solve the distributing source code
for copyleft style licensed software problem in a generic way. Or they
might just decide that they're stupid and stubborn and not interested in
solving any problems in the first place.