free5GC AUSF uses non-constant-time authentication comparisons and logs XRES* in 5G-AKA

EAP-AKA': AT_MAC, XMAC, XRES, and RES

In EapAuthComfirmRequestProcedure(), the AUSF computes the expected MAC and compares it with the received AT_MAC using bytes.Equal():

K_autStr := ausfCurrentContext.K_aut
K_aut, _ := hex.DecodeString(K_autStr)
XMAC := CalculateAtMAC(K_aut, decodeEapAkaPrimePkt.MACInput)
MAC := decodeEapAkaPrimePkt.Attributes[ausf_context.AT_MAC_ATTRIBUTE].Value
XRES := ausfCurrentContext.XRES
RES := hex.EncodeToString(decodeEapAkaPrimePkt.Attributes[ausf_context.AT_RES_ATTRIBUTE].Value)

if !bytes.Equal(MAC, XMAC) {
    eapOK = false
    eapErrStr = "EAP-AKA' integrity check fail"
} else if XRES == RES {
    logger.AuthELog.Infoln("Correct RES value, EAP-AKA' auth succeed")
    // ...
}

bytes.Equal() is not specified as a constant-time cryptographic comparison. The subsequent XRES == RES string comparison is also not constant-time. The correct primitive for comparing authentication tags and secret response values in Go is crypto/subtle.ConstantTimeCompare, after validating and normalizing input length and encoding.

The EAP-AKA' case is harder to exploit remotely than the 5G-AKA case because the XRES == RES comparison is reached only if AT_MAC is valid. Producing a valid AT_MAC requires session-specific K_aut.

Evidence

Static evidence

Static analysis confirmed:

• strings.EqualFold(updateConfirmationData.ResStar, ausfCurrentContext.XresStar) in the 5G-AKA confirmation path.
• logger.Auth5gAkaLog.Infof("res*: %x\nXres*: %x\n", ...) immediately before the comparison.
• bytes.Equal(MAC, XMAC) in the EAP-AKA' confirmation path.
• XRES == RES in the EAP-AKA' confirmation path.
• crypto/subtle is absent from the AUSF authentication processor code.

Internal evidence:

hallazgos/finding10-hres-timing/evidencia/20260526-090151-static-analysis/
hallazgos/finding11-eap-mac-timing/evidencia/20260526-094642-static-analysis/

5G-AKA timing and logging evidence

A timing PoC sent 500 iterations per condition over loopback HTTP/SBI:

Condition A: mismatch near the start
Condition B: mismatch in the middle
Condition C: mismatch near the end
Condition D: full match

The comparator-position signal was not distinguishable from HTTP noise:

Delta C-A: approximately -1.5 us
2-sigma noise threshold: approximately 557 us
Result: SIGNAL NOT CLEAR

This is consistent with the expected signal-to-noise ratio: the comparator-level timing difference is in the nanosecond range, while the HTTP/SBI path adds hundreds of microseconds of variance.

The same lab run confirmed that AUSF logs include XresStar in plaintext at INFO level. This does not require statistical inference.

Internal evidence:

hallazgos/finding10-hres-timing/evidencia/20260526-093558-timing-poc/

EAP-AKA' timing evidence

A timing PoC sent 500 iterations per condition against the EAP-AKA' confirmation path:

A: first MAC byte incorrect
B: first 8 MAC bytes correct
C: MAC correct, XRES incorrect
D: MAC correct, XRES correct

Observed medians were all around 464-467 us, and the HTTP-level timing signal was not detectable:

A: 466.6 us
B: 466.5 us
C: 464.2 us
D: 464.2 us
Delta D-A: approximately -2.4 us
2-sigma noise threshold: approximately 716 us
Result: SIGNAL NOT CLEAR

This confirms the expected practical limitation of a remote HTTP timing attack.

Internal evidence:

hallazgos/finding11-eap-mac-timing/evidencia/20260526-103822-timing-poc/

Local CPU benchmark for bytes.Equal()

A direct Go microbenchmark without HTTP overhead measured bytes.Equal() for 16-byte values. The raw benchmark data showed a monotonic increase as more leading bytes matched. The median delta from N=0 matching bytes to N=15 matching bytes was roughly 0.31 ns, or more than 20%.

This confirms that the local comparator is not position-independent at CPU level, even though the signal is too small to exploit remotely over HTTP in normal conditions.

Internal evidence:

hallazgos/finding11-eap-mac-timing/evidencia/20260526-104842-cpu-benchmark/

Uprobe path confirmation

Linux uprobes on the live AUSF process confirmed that requests reach the relevant comparison paths:

• MAC comparison path is hit for both failing and successful EAP-AKA' attempts.
• XRES comparison path is hit only when MAC verification passes.

Internal evidence:

hallazgos/finding11-eap-mac-timing/evidencia/20260526-053510-ebpf-uprobe/

Impact

There are two impact classes.

Sensitive value in logs

The 5G-AKA path logs XRES*, the expected response value, at INFO level. In deployments where AUSF logs are collected centrally or are readable by lower-privileged operators, infrastructure agents, compromised containers, or log-processing systems, this exposes authentication material that should remain internal to the authentication procedure.

The exact exploitability depends on whether the attacker can correlate log access with an active authentication context and submit the confirmation before the context is consumed or failed. Regardless, writing XRES* to application logs is an unsafe handling of authentication material.

Timing side channel / cryptographic hardening issue

The non-constant-time comparisons are real code issues and should be fixed, but we did not demonstrate a practical remote timing oracle over HTTP/SBI. The measured comparator signal is too small relative to HTTP noise in the lab.

The risk is higher in environments where an attacker has a lower-noise measurement point, local co-residency, kernel tracing capabilities, or another side channel that can observe the comparison more directly.

Suggested remediation

1. Remove XRES*, RES*, XRES, RES, K_aut, AT_MAC, and derived authentication material from INFO logs. If logging is necessary, log only metadata such as the authentication context ID, SUPI/SUCI in redacted form, result, and failure class.

2. Replace strings.EqualFold() and string == comparisons for authentication values with constant-time comparisons.

3. Normalize encodings before comparison. For hex-encoded values, decode both inputs first, validate expected lengths, and then compare fixed-size byte slices.

Example for 5G-AKA:

resStar, err1 := hex.DecodeString(updateConfirmationData.ResStar)
xresStar, err2 := hex.DecodeString(ausfCurrentContext.XresStar)

if err1 == nil && err2 == nil &&
    len(resStar) == len(xresStar) &&
    subtle.ConstantTimeCompare(resStar, xresStar) == 1 {
    // success
} else {
    // failure
}

Example for EAP-AKA' MAC:

if len(MAC) != len(XMAC) || subtle.ConstantTimeCompare(MAC, XMAC) != 1 {
    eapOK = false
    eapErrStr = "EAP-AKA' integrity check fail"
}

Example for EAP-AKA' XRES:

res, err1 := hex.DecodeString(RES)
xres, err2 := hex.DecodeString(XRES)

if err1 == nil && err2 == nil &&
    len(res) == len(xres) &&
    subtle.ConstantTimeCompare(res, xres) == 1 {
    // success
}

4. Add unit tests that ensure authentication values are not written to logs.

5. Consider avoiding a second UDM notification call in the 5G-AKA failure path if the first failure notification already reports the result. In the lab, failure performed two UDM calls while success performed one; this creates a coarse success/failure timing difference, although that result is already visible through the API response.

Prior art / non-duplication note

Known recent free5GC AUSF issues such as CVE-2026-33063 concern different failure modes and code paths. This report concerns cryptographic comparison and logging behavior in internal/sbi/processor/ue_authentication.go.