Summary
The tegra-se-ecdh hardware crypto driver (registered by the tegra-se-elp platform driver at 3ad0000.se_elp) produces incorrect ECDH shared secrets during BLE LE Secure Connections Out-of-Band (OOB) pairing. This causes SMP authentication failure (error 0x05) without any kernel panic or error log — the pairing simply fails silently.
This is distinct from the known NULL-pointer kernel panic caused by missing ECC curve coefficients in crypto/ecc.c (reported in this thread). In our case the kernel does not crash — the hardware crypto engine completes the ECDH operation but returns an incorrect result, causing the BLE SMP confirm values to not match.
Environment
- Device: Jetson Xavier NX (jetson-xavier-nx-devkit-emmc)
- JetPack: 5.x (L4T R35.6.0)
- Kernel: 5.10.216-l4t-35.6.0
- OS: Yocto Scarthgap with meta-tegra (scarthgap-l4t-r35.x branch)
- BlueZ: 5.72
- BLE Peripheral: nRF54L15 running Zephyr RTOS (nRF Connect SDK v2.9.0)
Reproduction
- Configure a BLE peripheral to advertise with LE Secure Connections OOB data (confirm + random values)
- On the Jetson, register the remote OOB data with BlueZ:
btmgmt --index 0 remote-oob -t 2 -H <confirm> -R <random> <addr> - Initiate pairing:
btmgmt --index 0 pair -c 3 -t 2 <addr> - Pairing fails with:
status 0x05 (Authentication Failed)
The same OOB data and pairing flow succeeds on Android devices and on non-Tegra Linux hosts.
Root Cause
The kernel registers two ECDH implementations:
$ cat /proc/crypto | grep -A3 ecdh
name : ecdh
driver : tegra-se-ecdh
priority : 300
name : ecdh
driver : ecdh-generic
priority : 100
The tegra-se-ecdh driver (priority 300) takes precedence over the software ecdh-generic (priority 100). The hardware driver produces incorrect ECDH results during the BLE SMP key exchange, causing the OOB confirm values to fail verification.
Workaround
Unbinding the Tegra SE ELP driver forces the kernel to fall back to the software ECDH implementation, which works correctly:
echo 3ad0000.se_elp > /sys/bus/platform/drivers/tegra-se-elp/unbind
After unbinding, only the software driver remains:
$ cat /proc/crypto | grep -A3 ecdh
name : ecdh
driver : ecdh-generic
priority : 100
BLE OOB pairing then succeeds with full LE Secure Connections (Mode 3, AUTH + ENCRYPT).
To make this persistent, the unbind can be added to a startup script. Alternatively, a device tree overlay that sets status = "disabled" on the 3ad0000 SE ELP node should prevent the driver from binding at boot.
Questions
- Is this a known issue with the Tegra SE ELP ECDH implementation?
- Is there a fix planned for a future L4T / JetPack release?
- Is there a supported kernel config option or device tree property to disable only the ECDH hardware acceleration while keeping other Tegra SE functions (AES, hash) active?
- Does JetPack 6.x (L4T R36.x, kernel 5.15/6.x) resolve this?
Impact
This affects any application using BLE LE Secure Connections with OOB pairing on Jetson Xavier NX devices (and likely other Tegra platforms with the SE ELP driver). The silent failure (no kernel log, no crash — just auth error) makes it difficult to diagnose. We spent significant time debugging before identifying the hardware crypto driver as the cause.