Project

General

Profile

A52 Withdrawal » History » Version 6

admin, 02/19/2016 10:52 PM
add link to 2003 paper

1 1 admin
[[PageOutline]]
2
= Withdrawal of A5/2 algorithim support =
3
4
After several attacks have been published on breaking the A5/2 encryption algorithm, the specification bodies (ETSI, 3GPP)
5 5 admin
and the operator industry (GSMA) have started to phase out A5/2.  This has been a lengthy process, taking some four years
6
from attack publication to all GSM operators having fixed their networks.
7 1 admin
8 5 admin
Four years for incident response is completely unacceptable and a ridiculous time to mitigate such a severe threat against
9
the confidentiality of personal communication.
10 1 admin
11 5 admin
As there seems no public document describing this lengthy procedure in detail, the page in this wiki was created. It also
12
touches aspects that are not strictly A5/2 related but related to introducing the A5/3 and A5/4 algorithms.
13
14 1 admin
Most of the information has been recovered from the published [http://www.3gpp.org/ftp/Specs/html-info/Meetings-S3.htm 3GPP SA3 WG meeting reports]
15
16 5 admin
As can be seen from the records below, the security working groups in the 3GPP and to a less extent in the GSMA are doing
17
what they can.  But the operator and manufacturer industry simply has no intention to provide timely incident response
18
and to pro-actively improve security of their mobile networks.
19
20 1 admin
== Timeline ==
21
22 6 admin
=== August 2003: Crypto 2003: E. Barkan, E. Biham, and N. Keller: Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communication ===
23
24
http://www.ma.huji.ac.il/~nkeller/biham_gsm.pdf
25
26 1 admin
=== November 2004: 3GPP SA3 Meeting 36 ===
27
28
From the official [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_36_Shenzhen/Report/Draft_Rep_v004_SA3_36.pdf report]:
29
30
''TD S3-041028 Vodafone comments to S3-040955: Proposed CR to 43.020: Clarifying the support of algorithms
31
within mobile stations (Rel-6). This was introduced by Vodafone and comprised an update to TD S3-040955. It was
32
reported that phasing out A5/2 was acceptable for the GSMA Board. The effect on other operators who implement
33
only A5/2 (if any) was unknown, as they do not participate in the GSM/3GPP standardisation bodies). The CR was
34
revised in TD S3-041075, which was approved.''
35
36 2 admin
=== April 2006: GSMA Industry Initiative to Withdraw A5/2 Briefing Paper ===
37 1 admin
38 2 admin
The paper can be found [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Docs/S3-060541.zip here]
39
40
41
=== July 2006: 3GPP SA3 Meeting 44 ===
42
43 1 admin
From the official [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Report/S3-060772.zip report]:
44
45
{{{
46
Charles Brookson gave a review of GSMA Security Group activities. Progress was being made on the 2006 work items:
47
-	Withdrawal of A5/2 from GSM handsets and networks
48
}}}
49
50
''It was noted that some manufacturers are reluctant to remove A5/2 from their mobiles as some operators were still using it. The answer was that work is still ongoing to convince operators, mainly from North America, that A5/2 should be removed.''
51
52 2 admin
This means that even by mid-2006, 3 years after the attack was published, A5/2 was still actively used by operators even in the 1st world!
53
54
=== September 2006: Withdrawal of A5/2 from Handsets deadline ===
55
56
The GSMA SG statement regarding the deadline for withdrawal of A5/2 from handsets can be found the 3GPP TSG SA WG3 meeting 45:
57
[http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_45_Ashburn/Docs/S3-060751.zip Withdrawal of A5/2 from Handsets Deadline]
58
59
In this document, the GSMA SG 
60
61
''The successful withdrawal of A5/2 requires terminal manufacturers to remove it from, or disable it in, emerging GSM enabled devices.''
62
63
''The risk of operators continuing to demand A5/2 device support stems from the possibility that some operators may not upgrade their networks to support stronger algorithms in a timely manner. The emergence of devices without A5/2 support will mean that encryption will not be possible on networks that have not upgraded their BSS infrastructure to support A5/1 and/or A5/3. However, because of the nature of the attack, and the fact that A5/2 does not offer a higher level of protection than A5/0, it is deemed preferable that these networks run with no encryption rather than use the compromised A5/2 protocol. Therefore, there is no valid reason why operators would continue to insist on A5/2 support in devices - even those that use the algorithm - and that is the key message that GSMA is promoting to its network operator members.''
64
65
This is very interesting, as it explicitly states no encryption is not considered as a problem in case operators did not yet upgrade to A5/1, but new non-A5/2 capable devices are used on their network.
66
67
''GSMA and device manufacturer representatives at a meeting in London on 25th July at which support was pledged for the withdrawal of A5/2 by end of this year''
68
69
''In GSM Phase 1, terminals were only mandated to support A5/1 and A5/0 (unciphered mode). Therefore in order to support GSM Phase 1 mobiles, A5/2 networks have always had to allow terminals to connect using unciphered mode (A5/0).''
70
71
As we can see, some GSMA members apparently prefer to show their customers that their call is not encrypted while they are too lazy to upgrade their networks:
72
''There were also concerns that non-encrypted calls could give rise to customers being shown non-ciphering indicators on some terminals, causing them alarm. However, operators can turn off this feature using a configuration bit on the SIM/USIM.''
73
74
==== Include testing for A5/2 removal in certification ====
75
76
''The GSM Association’s Security Group (GSMA SG) fully supports and endorses the work item proposed within GCF to develop test cases to verify the removal of A5/2.''
77
78
=== October 2006: 3GPP SA WG3 Meeting 45 ===
79
80
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_45_Ashburn/Report/Draft_Rep_v004_SA3_45.zip]
81
82
Change Requests (S3-060790, S3-060791, S3060792) regarding the removal of A5/2 from the specification have been agreed and send to SA.
83
84
=== February 2007: 3GPP SA WG3 Meeting 46 ===
85
86
From the [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_46_Beijing/Report/Draft_Rep_v003_SA3_46.zip]:
87
88
''5.4 GSMA [...] There is still workin ongoing on the removal of A5/2 from mobiles and, indeed, from the networks. First it would appear to convince operators to remove it first.''
89
90
=== May 2007: 3GPP SA WG3 Meeting 47 ===
91
92
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_47_Tallinn/Report/S3_47_Draft_Rep_v008.zip]
93
94
''A5/3 Support ([http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_47_Tallinn/Docs/S3-070437.zip S3‑070437] Liaison Statement (from GSMA SG): BSS vendor support for A5/3): The level of support for A5/3, (or the lack of it), was discussed and we approved the attached LS for input to SA WG3. The concern is that A5/3 is not widely supported by BSS vendors and the LS asks SA WG3 to review and update the specifications to ensure a clear deadline for A5/3 support in infrastructure is identified and it also asks SA WG3 represented BSS suppliers to respond to GSMA regarding their current/planned support for A5/3.''
95
96
While A5/3 is not required to phase out A5/2, this shows the lack of interest in the industry to improve the system security.
97
98
==== GSMA SG Liaison Statement about vendor support for A5/3 ====
99
From that Liaison statement:
100
101
''SA3 will be aware that the A5/3 specification was first published in May 2002 and initial targets were that the algorithm should be supported in handsets and network infrastructure by end October 2004.''
102
103
''The GSM Association’s Security Group (GSMA SG) discussed the level of support for A5/3 at its meeting on 14th and 15th May and we are gravely concerned that there is virtually no support for A5/3 5 years after the algorithm was published. This is despite the fact that an absolute deadline was agreed within 3GPP that Rel-6 compliant handsets are mandated to support A5/3.''
104
105
''GSMA SG is seriously concerned that if A5/1 was to succumb to sustained attack no backup algorithm has been widely deployed in handsets and infrastructure and this would have the effect of leaving the industry and mobile users exposed to security threats for an extended period.''
106
107
=== July 2007: 3GPP SA WG3 Meeting 48 ===
108
109
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_48_Montreal/Report/S3_48_Draft_Rep_v008.zip]
110
111
From the GSMA Liaison report:
112
''A5/2 removal has now been issued with closure report within the GSMA. Very good progress is being made with operators changing over to A5/1 in their networks. Similarly, mobiles without A5/2 are emerging and the testing regimes have been modified to support this. An internal closure report is available to GSMA members.''
113
114
So it seems, in July 2007, ''only'' four years after a serious attack has been disclosed, the problem was fixed ;)
115 1 admin
116 3 admin
''[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_48_Montreal/Docs/S3-070540.zip S3-070540]: GERAN access security review update ... Concerning A5/1 it was suggested that it is not breakable for the moment''
117
118
A number of change requests regarding ''Prohibiting A5/2 in mobile stations and other clarifications regarding A5 algorithm support'' were made and approved.
119
120
=== 3GPP SA WG3 Meeting 49 ===
121
122
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_49_Munich/Report/S3_49_Draft_Rep_v010.doc]
123
124
From the GSMA SG Liaison:
125
''In January 2007 a group of self styled “security enthusiasts” established the “A5 Cracking Project”, with the goal of designing and building affordable equipment that can crack A5/1. The project seeks to build on previously announced theoretical attacks against A5/1, and also aims to exploit the academic attack against A5/2 that was published in 2003 and that led to the industry decision to withdraw the algorithm.''
126
127
''The backers of the project have publicly called for volunteers to contribute to the work by contributing expertise, information and money. The project is described in more detail at http://wiki.thc.org/cracking_a5, and consists of a number of phases. The first is to understand the status of various A5 hacking initiatives, the second is to crack A5/2 on a practical level, the third is to launch a practical attack against A5/1 using previously published academic papers, and the final phase will seek to identify new ways of attacking A5/1. ''
128
129
''A second, related initiative called the GSM Software Project has also been launched.  The goal of this project is to develop a GSM scanner for under US$1,000.  The introduction and use of femtocells has made this a more likely possibility.''
130
131
''Both projects are supported by The Hackers Choice, which in its own words is “a non-commercial group of computer experts focusing on practical and theoretical computer security … the group fosters independent research not driven by commercial interests and paradigms”.''
132
133
''GSMA has carried out an analysis of the claims, and will be producing internal briefing documents. We have received favourable replies on upgrading to A5/3 both in the infrastructure and mobiles, and are following up the details''
134
135
=== February 2008: 3GPP TSG SA WG3 Meeting 50 ===
136
137
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_50_Sanya/Report/S3-080302%20SA3%2350_Draft_Rep_v002.zip]
138
139
From the GSMA SG:
140
''A demonstrated attack on A5/1 is awaited perhaps in March at some hacker conference. GSMA has produced guiding papers for operators if need should be.''
141
142
''SS7 protection is going to be discussed in the fore coming meeting of the GSMA group on roaming and interworking (IREG). TCAPsec and TCAP Handshake are the two candidate solutions, if they choose to do something.''
143
144
=== January 2009: 3GPP TSG SA WG3 Meeting 54 ===
145
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_54_Florence/Report/SA3%2354_final_meeting_report_v002.doc]
146
147
''Recent joint meetings with the Mobile Manufacturers (EICTA) had discussed forthcoming tests to check A5/3 functions''
148
149 4 admin
So in 2009 they are ''discussing'' how to test A5/3 which was first specified in 2002 ?
150
151
=== May 2009: 3GPP TSG SA3 WG Meeting 55 ===
152 1 admin
153 4 admin
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_55_Shanghai/Report/FINALMeetingReport_SA3_55_v003.doc]
154
155
''
156 5 admin
A new series of work items had been started for the next period. If anyone was interested in working on these topics then they would be welcome: Software Only Infrastructure Algorithm Updates - Mandate capability to support security algorithms without need to replace hardware.''
157 4 admin
158
Mh, in 2009 they ''start to think'' about mandating the software-updateability of ciphering algorithms in network equipment ;)
159
 
160
S3-091123 and S3-090829 are discussed, regarding 128bit encryption on GSM + GPRS as well as A5/4 key management
161
162
=== July 2009: 3GPP TSG SA3 WG Meeting 56 ===
163
164
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_56_Seattle/Report/finalMeetingReport_SA3_56.doc]
165
166
More discussion of Kc128 derivation from UMTS AKA (S3-091520, S3-091521) as well as the A5/4 and GEA4 specification (S3-091312)
167
168
=== November 2009: 3GPP TSG SA3 WG Meeting 57 ===
169
170
From the GSMA Liaison report:
171
172
''SG is looking at work items including the withdrawal of COMP128-1, something which is still causing issues for many operators after 12 years since it was broken.''
173
174
12 years after it has been broken, the GSMA still has not officially withdrawn it?
175
176
Seven years after A5/3 has been specified:
177
''Successful tests were made on A5/3 enabled BTS equipment in Switzerland, with 10 handsets from 7 manufacturers being tested on a live network.''
178
179
''We also discussed the need for a CERT-like warning scheme for the mobile industry''
180
181
''The meeting considered the need to ensure that future infrastructure algorithm updates will be exclusively software based''
182
183 3 admin
184 1 admin
== Miscellaneous ==
185
186
=== The GSMA IR.21 roaming database ===
187
188
The GSMA is maintaining a database of GSM roaming operators called IR.21.  It contains information about
189
the various GSM operators world wide.
190
191
The structure of the information is described in 
192
[http://www.algerietelecom.dz/veilletech/bulletin67/pdf/mobile7.pdf GSM Association Roaming Database, Structure and Updating Procedures].
193
194
Interesting bits of information are:
195
 * Which ciphering algorithms are in use (this should tell us where A5/2 is still in use!)
196
 * Whether or not ''Authentication performed for roaming subscribers at the commencement of GSM Service''
197
 * Whether or not ''Authentication performed for roaming subscribers in case of GPRS''
198
199
Having access to this database (which is available to all 700+ full GSMA members) would give real insight in
200
the reality of GSM network security!
201
202
=== GSMA PRD SG.15 ===
203
204
the [GSMA_Security_Group] has a document called SG.15 which describes best common practises regarding the use
205
of GSM security features.
206
207
Unfortunately we don't have access to that document..
208
209
=== Operators reluctant to phase out A5/2 ===
210
211
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Report/S3-060772.zip 3GPP SA3 Meeting Report 44] (July 2006) states:
212
213
''It was noted that some manufacturers are reluctant to remove A5/2 from their mobiles as some operators were still using it. The answer was that work is still ongoing to convince operators, mainly from North America, that A5/2 should be removed. ''
214
215
Interestingly, not the 3rd world countries were reluctant to switch to A5/1, but American operators ;)
Add picture from clipboard (Maximum size: 48.8 MB)