Security/mechanisms.html at main · jybae1226/Security · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
<!DOCTYPE html>
<html lang="en">
<style>
  .hero {
    padding-bottom: 0rem !important;
  }
</style>
<head>
  <meta charset="UTF-8" />
  <title>Security Mechanisms – 4G and 5G</title>
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <link rel="stylesheet" href="style.css" />
</head>
<body>
  <header>
    <div class="nav-inner">
      <div class="logo">4G / 5G Security</div>
      <nav>
        <ul>
          <li><a href="index.html">Introduction</a></li>
          <li><a href="mechanisms.html" class="active">Security Mechanisms</a></li>
          <li><a href="attacks.html">Attacks &amp; Feasibility</a></li>
          <li><a href="opinions.html">Opinion &amp; Conclusion</a></li>
          <li><a href="references.html">References</a></li>
        </ul>
      </nav>
    </div>
  </header>

  <main>
    <section class="hero">
      <h1>2. Security Architecture &amp; Mechanisms</h1>
      <p>
        This page explains how 4G and 5G protect subscribers and network resources through
        authentication, key management, and confidentiality and integrity protection. It first
        describes the main security mechanisms in 4G (LTE), then presents new or strengthened
        mechanisms in 5G, and finally highlights core concepts that remain common across both
        generations.
      </p>

      <h4>2.1 Security Mechanisms in 4G (LTE)</h4>

      <div style="text-align:center; margin: 20px 0;">
        <img src="images/security/Overview of the security architecture(4G).png" alt="Overview of the security architecture (4G)" style="max-width: 60%; border-radius: 10px;">
        <p style="font-size: 0.8rem; color:#9ca3af; margin-top: 5px;">
          Figure: Overview of the security architecture (4G LTE)
        </p>
      </div>

      <h5>2.1.1 EPS-AKA: Authentication and Key Agreement</h5>
      <p>
        EPS-AKA (Evolved Packet System Authentication and Key Agreement) is the primary
        authentication and key establishment protocol in 4G/LTE. It provides mutual authentication
        between the User Equipment (UE) and the core network and establishes fresh keys that are
        later used to protect NAS signalling and radio traffic within the Evolved Packet System.
      </p>

      <div style="text-align:center; margin: 20px 0;">
        <img src="images/security/EPS AKA authentication .png" alt="EPS AKA authentication " style="max-width: 50%; border-radius: 10px;">
        <p style="font-size: 0.8rem; color:#9ca3af; margin-top: 5px;">
          Figure: EPS AKA authentication
        </p>
      </div>

      <h6>Basic roles</h6>
      <ul>
        <li><strong>UE:</strong> the user’s device and USIM, which stores a long-term secret key and subscriber identity.</li>
        <li><strong>Home Subscriber Server (HSS):</strong> core database that holds subscriber profiles and the long-term keys.</li>
        <li><strong>Serving network:</strong> the visited or serving PLMN currently providing EPS service to the UE.</li>
      </ul>

      <h6>How it works</h6>
      <ul>
        <li>The serving network requests one or more authentication vectors from the HSS for the target subscriber.</li>
        <li>
          The HSS, using the long-term key shared with the USIM, generates a random challenge (RAND),
          an expected response (XRES), a cipher key (CK), an integrity key (IK), and an
          authentication token (AUTN).
        </li>
        <li>The serving network sends RAND and AUTN to the UE as an authentication request.</li>
        <li>The USIM verifies AUTN to authenticate the network and to ensure the challenge is fresh, preventing replay attacks.</li>
        <li>If verification succeeds, the USIM computes the response RES and returns it to the serving network.</li>
        <li>The serving network compares RES with XRES; if they match, the UE is authenticated.</li>
        <li>
          From CK and IK, both sides derive the EPS security master key K<sub>ASME</sub>, which will be
          further expanded into keys for NAS and radio protection.
        </li>
      </ul>

      <h6>Why it matters</h6>
      <p>
        EPS-AKA ensures that only legitimate subscribers attach to the EPS and that the network is
        authentic in the eyes of the UE. It also ensures that session keys are freshly derived each
        time, without exposing the long-term secret. However, the procedure can still be abused by
        adversaries that repeatedly trigger authentication or exploit weaknesses in how and when
        authentication is initiated.
      </p>

      <h5>2.1.2 Radio Interface Security: NAS and RRC Ciphering and Integrity</h5>
      <p>
        In 4G, signalling and user data over the radio interface are protected at two logical layers:
      </p>
      <ul>
        <li>
          <strong>Non-Access Stratum (NAS):</strong> signalling between the UE and the MME in the core network,
          used for procedures such as attach, detach, and tracking area updates.
        </li>
        <li>
          <strong>Radio Resource Control (RRC):</strong> signalling between the UE and the eNodeB, used to configure
          radio bearers, perform handovers, and manage radio connections.
        </li>
      </ul>
      <p>
        For both NAS and RRC, LTE supports ciphering (confidentiality protection) and integrity
        protection (message authentication and anti-tampering).
      </p>

      <h6>How it works</h6>
      <ul>
        <li>After EPS-AKA, the UE and the core share K<sub>ASME</sub> as the EPS master key.</li>
        <li>
          From K<sub>ASME</sub>, the network derives NAS keys (K<sub>NASenc</sub>, K<sub>NASint</sub>). Once
          the UE is connected to an eNodeB, K<sub>ASME</sub> is also used to derive K<sub>eNB</sub>, which is then
          expanded into RRC and user-plane keys (K<sub>RRCenc</sub>, K<sub>RRCint</sub>, K<sub>UPenc</sub>, etc.).
        </li>
        <li>
          Standardized algorithms (for example, AES-, SNOW 3G-, and ZUC-based schemes) encrypt user data and signalling so
          that passive eavesdroppers cannot read the traffic.
        </li>
        <li>
          Integrity algorithms compute a Message Authentication Code (MAC) over protected signalling messages,
          allowing the receiver to detect modification or forgery.
        </li>
      </ul>

      <h6>Why it matters</h6>
      <p>
        Radio interface security protects against attackers who try to listen in or inject messages
        over the air. Without it, the confidentiality and correctness of signalling and user-plane
        data could not be guaranteed. In practice, however, messages sent before security activation
        or misconfigurations have enabled concrete attacks. Crucially, although LTE defines user-plane
        integrity protection algorithms in the standard, their use is optional and not enabled in most
        commercial deployments. In contrast, 5G maintains a similar optional integrity‐protection mechanism
        for the user plane but promotes a more consistent security framework across NAS, RRC, and UP.
      </p>

      <h5>2.1.3 Network Domain Security (NDS/IPsec) in the Core</h5>
      <p>
        Inside and between operator networks, communication between core elements such as MME, SGW,
        PGW, and HSS runs over IP infrastructure. Network Domain Security (NDS) defines how operators
        should protect these internal and inter-operator links using IPsec tunnels and related
        mechanisms.
      </p>

      <h6>How it works</h6>
      <ul>
        <li>
          Security gateways or firewalls at the edge of protected domains establish IPsec Security
          Associations (SAs) using the Internet Key Exchange (IKE) protocol.
        </li>
        <li>
          Once SAs are in place, IPsec in Encapsulating Security Payload (ESP) mode provides
          encryption and integrity protection for IP packets that traverse the secured links.
        </li>
        <li>
          Security policies define which IP flows (for example, signalling between MMEs and HSS
          or between core sites) must be carried inside IPsec tunnels.
        </li>
      </ul>

      <h6>Why it matters</h6>
      <p>
        NDS/IPsec prevents unauthorized parties on the operator’s backbone or at peering points from
        observing or tampering with core signalling. However, failures in policy configuration,
        missing protection on some interfaces, or weak perimeter controls can still create exploitable
        gaps, especially in roaming or multi-operator scenarios.
      </p>

      <h4>2.2 Security Mechanisms in 5G</h4>

      <div style="text-align:center; margin: 20px 0;">
        <img src="images/security/Overview of the security architecture(5G).png" alt="Overview of the security architecture (5G)" style="max-width: 60%; border-radius: 10px;">
        <p style="font-size: 0.8rem; color:#9ca3af; margin-top: 5px;">
          Figure: Overview of the security architecture (5G)
        </p>
      </div>

      <h5>2.2.1 5G-AKA and EAP-AKA'</h5>
      <p>
        5G introduces an enhanced authentication framework with two main options for primary
        authentication: 5G-AKA and EAP-AKA'. Both are based on the same long-term key material
        stored in the USIM but improve how keys are bound to serving networks and how roaming
        scenarios are handled compared with LTE.
      </p>

      <div style="text-align:center; margin: 20px 0;">
        <img src="images/security/Authentication procedure for 5G AKA.png" alt="Authentication procedure for 5G AKA" style="max-width: 60%; border-radius: 10px;">
        <p style="font-size: 0.8rem; color:#9ca3af; margin-top: 5px;">
          Figure: Authentication procedure for 5G AKA
        </p>
      </div>

      <div style="text-align:center; margin: 20px 0;">
        <img src="images/security/Authentication procedure for EAP-AKA'.png" alt="Authentication procedure for EAP-AKA'" style="max-width: 60%; border-radius: 10px;">
        <p style="font-size: 0.8rem; color:#9ca3af; margin-top: 5px;">
          Figure: Authentication procedure for EAP-AKA'
        </p>
      </div>

      <h6>Key concepts</h6>
      <ul>
        <li>
          <strong>EAP (Extensible Authentication Protocol):</strong> a generic method for running
          authentication protocols in a flexible way, used in many access technologies.
        </li>
        <li>
          <strong>EAP-AKA' (EAP-AKA Prime):</strong> an EAP method that extends AKA and adds additional protections
          against certain known vulnerabilities, specifically binding the keys to the serving network name.
        </li>
      </ul>

      <h6>How it works</h6>
      <ul>
        <li>The UE and the home network still share a long-term key stored in the USIM.</li>
        <li>
          An authentication procedure is run, either as native 5G-AKA or as EAP-AKA′ carried in NAS messages
          between UE and AMF.
        </li>
        <li>
          The home network explicitly participates in deciding whether authentication was successful and
          which serving network is authorized to use the resulting security context.
        </li>
        <li>
          The procedure yields a key K<sub>AUSF</sub>, from which K<sub>SEAF</sub> is derived. K<sub>SEAF</sub> is then used to derive K<sub>AMF</sub>, which in turn generates K<sub>gNB</sub> to establish specific keys for NAS, RRC, and user-plane protection.
        </li>
      </ul>

      <h6>Why it matters</h6>
      <p>
        5G-AKA and EAP-AKA′ address several design limitations of EPS-AKA, particularly in roaming
        environments and in binding security contexts to serving networks. They also integrate more
        naturally with other EAP-based systems that may share the same authentication infrastructure.
        As in LTE, correct implementation and configuration remain essential for real security.
      </p>

      <h5>2.2.2 Subscriber Identity Protection: SUPI and SUCI</h5>
      <p>
        To mitigate long-standing privacy issues with IMSI exposure, 5G introduces a stronger identity
        protection scheme based on distinguishing between a permanent identifier and a concealed one:
      </p>
      <ul>
        <li><strong>SUPI (Subscription Permanent Identifier):</strong> the true subscriber identity stored in the USIM and home network.</li>
        <li><strong>SUCI (Subscription Concealed Identifier):</strong> a privacy-preserving identifier obtained by encrypting the SUPI with the home network’s public key.</li>
      </ul>

      <h6>How it works</h6>
      <ul>
        <li>The home network publishes a public key that UEs use to conceal their SUPI.</li>
        <li>
          Before initial registration, the USIM computes the SUCI from the SUPI using this public key,
          and the SUCI is sent over the radio interface instead of the clear-text SUPI.
        </li>
        <li>Only the home network, which holds the corresponding private key, can recover the SUPI from the SUCI.</li>
        <li>
          After registration, temporary identifiers (such as 5G-GUTI) are used to further reduce exposure
          of long-term identifiers in normal operation.
        </li>
      </ul>

      <h6>Why it matters</h6>
      <p>
        By encrypting the permanent identifier, SUCI makes it significantly harder for passive observers
        to track subscribers using long-lived identifiers. Active attacks with fake base stations are not
        fully eliminated, but the attack surface for large-scale identity collection is greatly reduced.
      </p>

      <h5>2.2.3 Service-Based Architecture (SBA) Security and SEPP</h5>
      <p>
        The 5G Core (5GC) is organized as a Service-Based Architecture (SBA), in which core functions
        offer services to each other via HTTP/2 and JSON APIs on Service-Based Interfaces (SBI). To
        secure this environment, 5G combines telecom-specific rules with standard IT security
        mechanisms such as TLS, mutual authentication, and fine-grained authorization. For inter-operator
        traffic, 5G introduces the Security Edge Protection Proxy (SEPP).
      </p>

      <h6>Key concepts</h6>
      <ul>
        <li><strong>TLS (Transport Layer Security):</strong> provides confidentiality and integrity for TCP connections on SBI.</li>
        <li>
          <strong>SEPP:</strong> a special network function at the edge of each PLMN that protects signalling on the N32
          interface between different operators’ 5G cores by adding application-layer integrity and
          confidentiality where needed.
        </li>
      </ul>

      <h6>How it works</h6>
      <ul>
        <li>
          Each Network Function (NF) obtains a certificate and uses it to authenticate itself when
          establishing TLS-protected SBI connections.
        </li>
        <li>
          Access control is enforced so that only authorized NFs can invoke specific APIs, often
          using tokens and policies managed by functions like the NRF.
        </li>
        <li>
          When signalling crosses operator boundaries, SEPPs on both sides apply signing and selective
          encryption of message fields so that intermediate networks cannot read or alter sensitive data.
        </li>
      </ul>

      <h6>Why it matters</h6>
      <p>
        SBA security and SEPP are essential for protecting 5G’s more open, API-driven core. They reduce
        the risk that compromised or rogue elements can misuse core APIs or intercept roaming traffic,
        but they also bring typical web-security challenges such as certificate management and API
        hardening into the telecom domain.
      </p>

      <h4>2.3 Security Mechanisms Common to Both 4G and 5G</h4>

      <h5>2.3.1 Hierarchical Key Management</h5>
      <p>
        Both 4G and 5G rely on a layered key hierarchy. At the root, a long-term key is stored in
        the USIM and in the home network. Each authentication run derives an intermediate master key
        (K<sub>ASME</sub> in LTE, K<sub>SEAF</sub> in 5G). From that, distinct keys are derived for NAS,
        RRC, and user-plane protection. In 5G, this hierarchy is deeper (involving K<sub>AMF</sub> and K<sub>gNB</sub>)
        to better support service based architecture and radio separation.
      </p>

      <div style="text-align:center; margin: 20px 0;">
        <img src="images/security/Key hierarchy generation in 5GS.png" alt="Key hierarchy generation in 5GS" style="max-width: 60%; border-radius: 10px;">
        <p style="font-size: 0.8rem; color:#9ca3af; margin-top: 5px;">
          Figure: Key hierarchy generation in 5GS
        </p>
      </div>

      <p>
        This design limits the impact of key compromise: exposure of one radio connection key does not
        directly reveal the master key or the long-term secret. It also enables efficient handover and
        mobility, since new keys can be derived as the UE moves without repeating the full authentication
        with the home network every time.
      </p>

      <h5>2.3.2 Use of Standardized Cryptographic Algorithms</h5>
      <p>
        Both generations use a small set of standardized, publicly reviewed cryptographic algorithms
        for encryption and integrity protection. These include AES-based, SNOW 3G–based, and ZUC-based ciphers, and
        MAC algorithms designed specifically for 3GPP systems. In real deployments, most security
        issues have arisen from protocol design choices, implementation bugs, or misconfiguration,
        rather than catastrophic failures of these primitives.
      </p>
      <p>
        As a result, secure operation of 4G and 5G depends not only on choosing strong algorithms, but
        also on correctly implementing key management, enforcing integrity protection where required,
        and maintaining robust operational practices around both radio and core network elements.
      </p>
    </section>
  </main>

  <footer>
    <p class="muted">
      &copy; 2025 JongYeon Bae — Security in 4G / 5G Mobile Networks.
    </p>
  </footer>
</body>
</html>