> > 2. You can copy a sim card. > > Please forgive me if this sounds naive, but I was under a *STRONG* > impression that it is practically impossible to copy a smart > card. [Isnt > that what is used as a SIM card]. From the little that I know of smart > cards, security is their forte. I know absolute security is an unknown > concept but still copying a smart card, wouldnt that be too > difficult?? Wouldnt the cost involved in doing so probably be > more than > the benefits? Indeed, you can not just copy the SIM card. However, the only thing you need is the subscriber's private authentication key (referred to as Ki in GSM terminology), her/his IMSI-number and perhaps the ESN number (?). Out of these, only the private authentication key Ki is protected and the SIM card never reveals it. The private key never leaves the card, it is only used for challenge/response-style authentication towards the network. Now here is where the main fault lies: the A3-algorithm that is used as the checksum algorithm is flawed, at least the example implementation that is known as COMP128 that is floating around the Internet. With a trial-and-error test, by feeding different challenges to the card and observing the responses, you can calculate the value of Ki. Once you have that, you can spoof the person the Ki belongs to. Now, the SIM card only calculates these responses when you give the PIN number or when the network asks to. If you have physical access to the SIM card and know the PIN, you can clone it. This isn't very interesting. More interesting is the fact, that you can put up a base station (been done, and it was well within the budget of perhaps a small group of individuals), spoof to be the network and start bombing the phone with challenges. After a while you will get Ki. I don't think anyone's done this in real life, because of simply the fact that possessing those kind of equipment would be illegal. But the way GSM networks work, there is no way this could be stopped. Now A5 is the algorithm within the phone, used to encrypt calls. A3 and A8 are both checksum algorithms that are used 1) to figure out the response to the challenge/response authentication and 2) to calculate the session encryption key for A8. Now I believe the story goes, cellular operators are free to make modifications to these algorithms - they simply distribute modified SIM cards as well as modify their AuCs (Authentication Centers). Does anyone do this in real life? And where does COMP128 fit in here? Is it a known implementation of A3/A8? > > 3. You can eavesdrop comunications between basestations. > > Out of plain curiosity, is the data encrypted while in > transit. I asked > the dealer here in my country who promptly replied YES, but I > doubt he had > even a vague idea of what I was talking about. Given the > amount of data > and the required level of low latency in cell phones and the fact SIM > cards are no Crays, I would *LOGICALLY* doubt it. But then I > would love to > be sure. Well I'm not sure about inter-basestation traffic, but most base stations communicate up to the core networks and to the base station controllers (BSCs) using microwave links or radio links. These interfaces are almost always proprietary, and no, they do not encrypt. All you need to do is figure out the proprietary protocol and get to where the beam is (even directed microwave transmissions spread enough). The traffic from the phone to the base station is still encrypted, though. And it's not done on the SIM card, but in the phone. The SIM card calculates a session encryption key for the phone to encrypt with using the challenge from the network and you private key Ki. -- Toni Heinonen, CISSP Teleware Oy +358 40 836 1815 ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Sun Jan 27 2002 - 14:15:09 PST