Project

General

Profile

A52 Withdrawal » History » Version 4

admin, 02/19/2016 10:52 PM
update up to meeting 57

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
and the operator industry (GSMA) have started to phase out A5/2.
6
7
As there seems no public document describing this procedure in detail, the page in this wiki was created.
8
9
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]
10
11
== Timeline ==
12
13
=== November 2004: 3GPP SA3 Meeting 36 ===
14
15
From the official [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_36_Shenzhen/Report/Draft_Rep_v004_SA3_36.pdf report]:
16
17
''TD S3-041028 Vodafone comments to S3-040955: Proposed CR to 43.020: Clarifying the support of algorithms
18
within mobile stations (Rel-6). This was introduced by Vodafone and comprised an update to TD S3-040955. It was
19
reported that phasing out A5/2 was acceptable for the GSMA Board. The effect on other operators who implement
20
only A5/2 (if any) was unknown, as they do not participate in the GSM/3GPP standardisation bodies). The CR was
21
revised in TD S3-041075, which was approved.''
22
23 2 admin
=== April 2006: GSMA Industry Initiative to Withdraw A5/2 Briefing Paper ===
24 1 admin
25 2 admin
The paper can be found [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Docs/S3-060541.zip here]
26
27
28
=== July 2006: 3GPP SA3 Meeting 44 ===
29
30 1 admin
From the official [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Report/S3-060772.zip report]:
31
32
{{{
33
Charles Brookson gave a review of GSMA Security Group activities. Progress was being made on the 2006 work items:
34
-	Withdrawal of A5/2 from GSM handsets and networks
35
}}}
36
37
''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.''
38
39 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!
40
41
=== September 2006: Withdrawal of A5/2 from Handsets deadline ===
42
43
The GSMA SG statement regarding the deadline for withdrawal of A5/2 from handsets can be found the 3GPP TSG SA WG3 meeting 45:
44
[http://www.3gpp.org/ftp/tsg_sa/wg3_security/TSGS3_45_Ashburn/Docs/S3-060751.zip Withdrawal of A5/2 from Handsets Deadline]
45
46
In this document, the GSMA SG 
47
48
''The successful withdrawal of A5/2 requires terminal manufacturers to remove it from, or disable it in, emerging GSM enabled devices.''
49
50
''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.''
51
52
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.
53
54
''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''
55
56
''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).''
57
58
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:
59
''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.''
60
61
==== Include testing for A5/2 removal in certification ====
62
63
''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.''
64
65
=== October 2006: 3GPP SA WG3 Meeting 45 ===
66
67
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_45_Ashburn/Report/Draft_Rep_v004_SA3_45.zip]
68
69
Change Requests (S3-060790, S3-060791, S3060792) regarding the removal of A5/2 from the specification have been agreed and send to SA.
70
71
=== February 2007: 3GPP SA WG3 Meeting 46 ===
72
73
From the [http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_46_Beijing/Report/Draft_Rep_v003_SA3_46.zip]:
74
75
''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.''
76
77
=== May 2007: 3GPP SA WG3 Meeting 47 ===
78
79
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_47_Tallinn/Report/S3_47_Draft_Rep_v008.zip]
80
81
''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.''
82
83
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.
84
85
==== GSMA SG Liaison Statement about vendor support for A5/3 ====
86
From that Liaison statement:
87
88
''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.''
89
90
''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.''
91
92
''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.''
93
94
=== July 2007: 3GPP SA WG3 Meeting 48 ===
95
96
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_48_Montreal/Report/S3_48_Draft_Rep_v008.zip]
97
98
From the GSMA Liaison report:
99
''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.''
100
101
So it seems, in July 2007, ''only'' four years after a serious attack has been disclosed, the problem was fixed ;)
102 1 admin
103 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''
104
105
A number of change requests regarding ''Prohibiting A5/2 in mobile stations and other clarifications regarding A5 algorithm support'' were made and approved.
106
107
=== 3GPP SA WG3 Meeting 49 ===
108
109
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_49_Munich/Report/S3_49_Draft_Rep_v010.doc]
110
111
From the GSMA SG Liaison:
112
''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.''
113
114
''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. ''
115
116
''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.''
117
118
''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”.''
119
120
''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''
121
122
=== February 2008: 3GPP TSG SA WG3 Meeting 50 ===
123
124
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_50_Sanya/Report/S3-080302%20SA3%2350_Draft_Rep_v002.zip]
125
126
From the GSMA SG:
127
''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.''
128
129
''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.''
130
131
=== January 2009: 3GPP TSG SA WG3 Meeting 54 ===
132
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_54_Florence/Report/SA3%2354_final_meeting_report_v002.doc]
133
134
''Recent joint meetings with the Mobile Manufacturers (EICTA) had discussed forthcoming tests to check A5/3 functions''
135
136
So in 2009 they are ''discussing'' how to test A5/3 which was first specified in 2002 ?
137
138 4 admin
=== May 2009: 3GPP TSG SA3 WG Meeting 55 ===
139
140
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_55_Shanghai/Report/FINALMeetingReport_SA3_55_v003.doc]
141
142
''
143
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:
144
 * Software Only Infrastructure Algorithm Updates - Mandate capability to support security algorithms without need to replace hardware.''
145
146
Mh, in 2009 they ''start to think'' about mandating the software-updateability of ciphering algorithms in network equipment ;)
147
 
148
S3-091123 and S3-090829 are discussed, regarding 128bit encryption on GSM + GPRS as well as A5/4 key management
149
150
=== July 2009: 3GPP TSG SA3 WG Meeting 56 ===
151
152
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_56_Seattle/Report/finalMeetingReport_SA3_56.doc]
153
154
More discussion of Kc128 derivation from UMTS AKA (S3-091520, S3-091521) as well as the A5/4 and GEA4 specification (S3-091312)
155
156
=== November 2009: 3GPP TSG SA3 WG Meeting 57 ===
157
158
From the GSMA Liaison report:
159
160
''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.''
161
162
12 years after it has been broken, the GSMA still has not officially withdrawn it?
163
164
Seven years after A5/3 has been specified:
165
''Successful tests were made on A5/3 enabled BTS equipment in Switzerland, with 10 handsets from 7 manufacturers being tested on a live network.''
166
167
''We also discussed the need for a CERT-like warning scheme for the mobile industry''
168
169
''The meeting considered the need to ensure that future infrastructure algorithm updates will be exclusively software based''
170
171 3 admin
172 1 admin
== Miscellaneous ==
173
174
=== The GSMA IR.21 roaming database ===
175
176
The GSMA is maintaining a database of GSM roaming operators called IR.21.  It contains information about
177
the various GSM operators world wide.
178
179
The structure of the information is described in 
180
[http://www.algerietelecom.dz/veilletech/bulletin67/pdf/mobile7.pdf GSM Association Roaming Database, Structure and Updating Procedures].
181
182
Interesting bits of information are:
183
 * Which ciphering algorithms are in use (this should tell us where A5/2 is still in use!)
184
 * Whether or not ''Authentication performed for roaming subscribers at the commencement of GSM Service''
185
 * Whether or not ''Authentication performed for roaming subscribers in case of GPRS''
186
187
Having access to this database (which is available to all 700+ full GSMA members) would give real insight in
188
the reality of GSM network security!
189
190
=== GSMA PRD SG.15 ===
191
192
the [GSMA_Security_Group] has a document called SG.15 which describes best common practises regarding the use
193
of GSM security features.
194
195
Unfortunately we don't have access to that document..
196
197
=== Operators reluctant to phase out A5/2 ===
198
199
[http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_44_Tallinn/Report/S3-060772.zip 3GPP SA3 Meeting Report 44] (July 2006) states:
200
201
''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. ''
202
203
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)