第29章蓝牙车钥匙实战

课程目录第29章蓝牙车钥匙实战

蓝牙车钥匙实战：Digital Key规范、安全认证、近场解锁、远程控制

车钥匙这个事儿，说实话，我入行那会儿还是传统的RFID钥匙。后来蓝牙车钥匙慢慢普及，再到现在的Digital Key规范，变化真的很大。今天咱们就聊聊这个实战课题——怎么用Kotlin在Android上实现一套靠谱的蓝牙车钥匙。

嗯，先给你看个整体架构图，心里有个谱。

Digital Key 规范到底是什么？

Digital Key 说白了就是一套标准。它定义了手机怎么跟车通信、怎么认证、怎么控制。目前主流的是 CCC（Car Connectivity Consortium）规范，版本已经到 3.0 了。

我记得刚接触这个规范时，光看文档就花了两周。但核心就三点：

密钥管理：密钥存在手机的安全区域（TEE 或 SE），不能随便读取
通信协议：基于 BLE GATT，有特定的服务和特征值
安全认证：双向认证，防止中间人攻击

核心要点：Digital Key 不是简单的蓝牙连接，它是一整套安全体系。你的 App 只是前端，真正的密钥操作在安全芯片里完成。

安全认证——这个坑我踩过

安全认证是车钥匙的命门。我参与过一个项目，初期没做好认证，结果测试时用一台手机就能解锁所有车……嗯，那场面挺尴尬的。

标准的认证流程是这样的：

设备发现：手机扫描到车辆的 BLE 广播
连接建立：建立 GATT 连接
挑战-响应：车端发送随机数，手机用私钥签名
密钥验证：车端用公钥验证签名
会话密钥：生成临时会话密钥，后续通信加密

代码实现上，核心是签名验证部分。我给你看个简化版：

// 安全认证 - 挑战响应
class DigitalKeyAuthenticator(private val keyStore: KeyStore) {

    fun handleChallenge(challenge: ByteArray): ByteArray? {
        // 从安全存储中获取私钥
        val privateKey = keyStore.getKey("digital_key", null) as? PrivateKey
            ?: return null

        // 签名挑战数据
        val signature = Signature.getInstance("SHA256withECDSA")
        signature.initSign(privateKey)
        signature.update(challenge)
        return signature.sign()
    }

    fun verifyResponse(publicKey: PublicKey, challenge: ByteArray, 
                       response: ByteArray): Boolean {
        val signature = Signature.getInstance("SHA256withECDSA")
        signature.initVerify(publicKey)
        signature.update(challenge)
        return signature.verify(response)
    }
}

注意：私钥绝对不能出现在 Java/Kotlin 堆内存中。上面代码只是演示逻辑，实际项目中要用 Android KeyStore 或安全芯片的 API 来操作。

近场解锁——RSSI 的玄学

近场解锁，就是靠近车门自动解锁。原理很简单：检测 BLE 信号强度（RSSI），当手机足够近时触发解锁。

但 RSSI 这东西，说实话不太靠谱。我在测试时发现，同一个位置，手机横着拿和竖着拿，RSSI 能差 10 个 dBm。后来我加了个滤波算法：

// RSSI 滑动平均滤波
class RssiFilter(private val windowSize: Int = 5) {
    private val buffer = mutableListOf<Int>()

    fun filter(rssi: Int): Int {
        buffer.add(rssi)
        if (buffer.size > windowSize) {
            buffer.removeAt(0)
        }
        // 去掉最大最小值，取平均
        val sorted = buffer.sorted()
        val trimmed = sorted.drop(1).dropLast(1)
        return if (trimmed.isEmpty()) rssi else trimmed.average().toInt()
    }
}

// 解锁逻辑
fun checkUnlockCondition(filteredRssi: Int) {
    // 阈值一般设在 -50dBm 到 -60dBm 之间
    if (filteredRssi > -55) {
        // 触发解锁
        sendUnlockCommand()
    }
}

另外，近场解锁还有个关键点——防误触。你想想看，如果车停在路边，行人路过时不小心解锁了，那多危险。所以一般会加双重判断：RSSI 阈值 + 加速度计检测（判断用户是否在走向车辆）。

远程控制——云端中转

远程控制跟近场不一样。近场是手机直接连车，远程是手机通过云端给车发指令。

流程大概是：

手机 App 发送指令到云端（HTTPS）
云端验证用户身份和权限
云端通过车联网（4G/5G）转发指令到车辆
车辆执行指令并返回结果

这里要注意的是指令的幂等性。我遇到过一个问题：用户点了两次解锁，结果云端发了两次指令，车端执行了两次解锁操作，虽然最终状态是对的，但中间有个短暂的状态不一致。

解决方案很简单——加个指令序列号：

data class RemoteCommand(
    val commandId: String,      // 唯一ID
    val commandType: CommandType, // LOCK, UNLOCK, START_ENGINE
    val timestamp: Long,
    val signature: ByteArray     // 防篡改签名
)

// 车端去重
class CommandDeduplicator {
    private val executedCommands = mutableSetOf<String>()

    fun shouldExecute(command: RemoteCommand): Boolean {
        return executedCommands.add(command.commandId)
    }
}

个人经验：远程控制的延迟是个大问题。从手机点击到车辆响应，理想情况 1-2 秒，但实际可能 5 秒以上。我建议在 UI 上做乐观更新——点击后立即显示「已发送」，而不是等车辆确认。

实战中的几个坑

最后分享几个我踩过的坑，你遇到了可以少走弯路：

蓝牙重连：手机离开车辆再回来，蓝牙重连有时会失败。建议加个重试机制，最多重试 3 次，每次间隔 2 秒。
多设备冲突：如果家里两个人都有手机钥匙，同时靠近车辆怎么办？规范里一般用优先级机制，或者让车辆同时处理多个连接。
电量问题：蓝牙一直扫描很耗电。建议用 Android 的 BLE 扫描回调 + 前台服务，别用后台扫描。
密钥过期：Digital Key 有有效期，过期后要重新从云端获取。这个逻辑一定要处理好，不然用户到了车跟前才发现钥匙失效了。

好了，蓝牙车钥匙这块内容不少，但核心就是安全认证 + 近场/远程控制。你先把规范吃透，再动手写代码，会顺畅很多。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

蓝牙车钥匙实战：Digital Key规范、安全认证、近场解锁、远程控制

Digital Key 规范到底是什么？

安全认证——这个坑我踩过

近场解锁——RSSI 的玄学

远程控制——云端中转

实战中的几个坑