A guide to 3GPP security documents
Warning: this document is not maintained!
I first wrote this document in 2000, and it has not received updates since 2001. It should therefore be regarded as obsolete. I have nevertheless made it available as references to it exist and some people may still want to look at it at their own risk.
You can always come back here and read the whole page if you get confused.
This page is here for people who want to learn about and study cryptographic aspects of 3GPP security documents. Please email me at user janos located at the site pobox.com with suggestions. Because of the obsolete status of this page, just about the only kind of suggestion I will consider is inserting a pointer to newer or better Web pages of this type.
3GPP, the 3rd Generation Partnership project, serves to produce standards for 3rd generation wireless phones. It kind of grew out of GSM.
In the last few years, GSM took a lot of flak for their approach to crypto algorithm design, which relied on keeping the algorithms secret. In fact, their various algorithms have been broken, as described here . (A person knowledgeable about GSM provided an alternative point of view on this: GSM broke entirely new ground in its use of cryptography in a mass market product - and the first steps were a bit tentative. It was also designed at a time when export restrictions on cryptographic products were a good deal tighter than they are now - which amongst other things meant that the algorithms were kept secret and could not benefit from public scrutiny. The result is a system which has generally done a good job of protecting its subscribers and operators, but in which some holes have appeared, and which is definitely showing its age today. Several pieces of cryptanalysis have been published. )
3GPP has chosen a superior approach to their crypto requirements. They are making open to the public all of their drafts, standards and recommendations, and rely on their algorithms withstanding the scrutiny of any interested researchers.
My aim in producing this page was to make it clear to any such "interested researchers" where and how these algorithms are published.
This page has nothing to do with North American wireless crypto standards promulgated by TIA. For more information on those algorithms, please refer to this FTP site .
3GPP organizational information
You can find out a lot about 3GPP by going to their Web site . You can probably find out anything that is on this page by going over to their Web site instead. Nevertheless, here are a few more concise hints.
3GPP is quite fond of acronyms. The parts of the organization that produce documents (that we are interested in) are called TSGs, which stands for Technical Specification Groups. The TSGs have names like SA, CN, RAN, etc. This explains a lot of the subdirectories in the root directory of their FTP server, ftp://ftp.3gpp.org .
The TSG of interest here is called SA, which stands for Services and System Aspects (I think). It corresponds to ftp://ftp.3gpp.org/TSG_SA .
The TSG SA has various working groups, also known as WGs. The WGs are called simply SA1, SA2, SA3, SA4, SA5. The one of interest to us is SA3 (also known as S3), which is responsible for Security. It corresponds to ftp://ftp.3gpp.org/TSG_SA/WG3_Security/ .
Here is how S3 operates. They meet every couple of months. Each meeting has a number. For example, S3 had their meeting #14 in Oslo, Norway, from August 1 to August 4 of 2000. This meeting is often referred to as S3#14. Documents from this meeting are to be found in ftp://ftp.3gpp.org/TSG_SA/WG3_Security/TSGS3_14_Oslo/ . This directory, and other meetings directories, have various subdirectories, the two most interesting ones of them are Report , and Docs . The former contains a report that summarizes what happened at the meeting and what documents were considered/produced there.
The actual documents are stored in the Docs directory. They have names like S3-000404.pdf, which denotes S3 document number "0404" in the year 20"00". Now you can see why you need to look at the report to find your way around.
S3 is generally responsible for the maintenance and developement of a certain set of 3GPP documents, which fall into two groups: TSes (technical standards) and TRs (technical reports). However, the S3 is not allowed to make changes in these documents itself. Instead, it has to produce CRs (change requests) which are forwarded for approval up one level, to the TSG SA, at their next plenary meeting. TSG SA will usually, but not always, approve the CR and agree to make the changes.
Another designation that often occurs in the WG meeting documents is LS, which stands for Liaison Statement. These are produced if S3 reaches a point in their discussion where it becomes necessary to consult another WG for guidance. This can happen, for example, if some document produced by that other WG is not clear on something. Since the other WG will not be in session at the same time, an LS is drafted and sent to them to deal with at their next meeting. The other WG will produce another LS in turn to answer the question, and send it back to S3 for its next meeting, and so on.
TSG SA plenary meetings occur somewhat less frequently than S3 meetings. They are also numbered, e.g., meeting #8 took place in Duesseldorf, Germany, from June 26 to June 28, 2000. You can find documents about their meetings in ftp://ftp.3gpp.org/TSG_SA/TSG_SA/ .
Two other organizations that are sometimes mentioned are ETSI and SAGE. ETSI stands for European Telecommunications Standards Institute , which had close ties with GSM and is still somehow connected to 3GPP. SAGE stands for Security Algorithms Group of Experts , and either belongs to or has been established by ETSI. SAGE tends to produce algorithms and algorithm evaluations for 3GPP, or, more specifically, for S3.
Now that all that is covered, let's get down to the documents. Most (but not all) 3GPP documents are available in PDF format, which is what I will give pointers to below, whenever possible. Every document is available in a MS Word format too, but I'll let MS Word enthusiasts worry about that.
- At Eurocrypt 2000, Prof. Michael Walker, who is the chair of the S3 group, gave a lecture entitled On the security of 3GPP networks . I think that this is a very good introduction to the topic.
The design of 3GPP security is such that not every carrier has to use
algorithms for authentication and key exchange (AKA). Therefore,
producing a standard, 3GPP publishes a recommendation or example
for those providers who do not wish to design and implement their own
algorithms. GSM used a similar approach
(the infamous COMP128 algorithm became an example),
and experience has shown that most carriers
chose to implement the example algorithm. The current suggestion for
AKA algorithms is called
MILENAGE was introduced at S3#16, which was held in December 2000. It has been made official by SA#11 in March 2001. It is based on Rijndael .
SAGE has released an evaluation of MILENAGE. This can be found right here .
The air interface encryption and integrity algorithms
must be the same for all carriers
(so that a subscriber can roam into another carrier's territory
and still be able to
communicate with the base stations located there).
The 3GPP algorithms used for these purposes
are both built around a block cipher
(Here is a note on
intellectual property rights
The Kasumi documents bear apparently restrictive labels such as,
"Subject to a Restriced Usage Undertaking".
I contacted members of the 3GPP Security (S3) group for clarification,
and two knowledgeable persons independently gave me the same answer.
Namely, Mitshubishi has IPR on KASUMI, but they are licencing it freely
for use in 3G systems. The documents can be readily scrutinized
for the purpose of determining the suitability of the system for 3G.
However, it is not the case that KASUMI can be used for other
purposes without an agreement with Mitsubishi and 3GPP.
For more details, including documents with names such as
"IPR Licence Agreement" and "Restriced Usage
Undertaking", go to the
3GPP conditions Web page
Disclaimer: I am not a lawyer and this is not legal advice.
You are responsible for ensuring that your conduct complies with all
applicable laws, etc.
Note that the last page of Walker's presentation includes a handy list
the TRs and TSes that relate to 3GPP security. These can be helpful in
filling in background information on 3GPP terminology or design.
These documents can generally be found under ftp://ftp.3gpp.org/Specs/ . The latest versions of the specifications can be found in the subdirectory corresponding to the latest SA meeting, for example ftp://ftp.3gpp.org/Specs/2000-12/ .
Here are the pointers to the Release 99 versions from the December 2000 meeting.
Principles, objectives and requirements
- TS 33.120, Security principles and objectives (This is not a tutorial introduction to 3GPP security. If you are disappointed by its contents, also refer to TR 33.102 .)
- TS 21.133, Security threats and requirements
- TR 33.102, 3GPP security architecture
- TR 33.103, Integration guidelines
- TR 33.105, Cryptographic algorithm requirements
- TR 22.022, Personalization of mobile equipment
- TR 33.106, Lawful interception requirements
- TR 33.107, Lawful interception architecture and functions
That concludes the list of algorithms that I think would be particularly good to look at, but I would be more than happy to provide a link to BEANO if someone tells me what the link is etc.
If you have written, or otherwise know about, research papers about these algorithms, please let me know! I will provide a link to them from here.
I thank Steve Babbage, Charles Brookson, Daniel Ferguson, Chiara Dotti, Ian Goldberg (who suggested that I create a page like this), Peter Howard, Geir Køien, Jim Reeds, Gert Roelofsen, Greg Rose, Bill Sommerfeld, Marco Tosalli, David Wagner, and others, for useful suggestions.
And now, gentle reader, go forth and study those algorithms!
- Example authentication and key exchange algorithm: MILENAGE .
- Air interface encryption and integrity algorithm: KASUMI . (Here is a note on intellectual property rights on KASUMI ).
Yours, Janos A. Csirik
This page was last edited on 28th August 2003, but pages linked from here might have been edited more recently. Also, these edits must have been minor formatting changes since I stopped maintaining the contents back in 2001. HTML 4.01 .