React Native蓝牙采数上报API场景下的安全实现方案咨询

核心防护围绕两个目标设计：一是蓝牙原始数据从采集到上传API全程不可篡改，二是仅官方发布的合法应用可调用API接口，同时适配后续智能合约校验的需求。

1 数据完整性防护层 #

• 蓝牙设备端原始数据签名：要求采集数据的蓝牙硬件内置非对称密钥对，用私钥对输出的原始数据、采集时间戳做签名，APP端提前预置设备端公钥，拿到蓝牙数据后首先验签，验签不通过的直接丢弃，禁止上传。
• APP端二次签名：验签通过的原始数据，调用原生侧逻辑用存在安全存储区的APP私钥做二次签名，签名内容包含原始数据、设备端签名结果、当前时间戳、单次请求随机数。
• React Native实现方式：用react-native-keychain库对接iOS Keychain、Android Keystore能力，密钥对生成、存储、签名逻辑全部放在原生层实现，JS层仅负责传递原始数据、获取最终签名串，避免密钥、签名逻辑暴露在JS bundle中被逆向破解。

2 应用身份合法性防护层 #

• 运行环境校验：
  • Android端集成SafetyNet Attestation能力，校验应用签名是否为官方签名、设备是否被Root、运行环境是否存在风险，获取Attestation校验票据随接口请求一同上传。
  • iOS端集成DeviceCheck能力，校验应用是否为App Store分发的官方版本、设备是否越狱，获取校验票据随接口请求一同上传。
• 包体防篡改：Android开启V2/V3签名校验，iOS开启官方代码签名校验，打包阶段用react-native-obfuscating-transformer混淆JS bundle代码，避免签名逻辑、安全校验逻辑被逆向修改。
• React Native实现方式：SafetyNet、DeviceCheck的调用逻辑自行编写原生模块桥接给JS层，仅向JS层暴露获取校验票据的方法，校验逻辑全部在原生侧执行。

3 API网关校验层 #

所有请求必须经过统一API网关做三层校验，校验不通过的直接拦截：

• 第一层验数据签名：先校验蓝牙设备端的原始数据签名，确认原始数据未被篡改；再校验APP端的二次签名，确认数据来自官方应用。同时校验请求时间戳，超过5分钟的直接拒绝，校验随机数是否重复出现，避免重放攻击。
• 第二层验运行环境票据：将客户端上传的SafetyNet、DeviceCheck票据分别发送到谷歌、苹果官方接口校验真伪，确认请求来自合法运行的官方应用。
• 第三层做传输链路校验：所有接口强制走HTTPS，开启SSL双向校验，客户端内置服务端证书公钥，避免中间人攻击抓包篡改请求内容。

适配智能合约场景的优化建议 #

API端校验通过的原始数据、设备端签名、APP端签名可同步上传至链上，也可将验签规则写入智能合约，由合约对传入的同批次数据做二次校验，确保链上链下数据一致性。

内容的提问来源于stack exchange，提问作者Applecakeman