示例仓库：https://atomgit.com/dijun_520/WebViewSecurityLab
社区引导：框架源码与版本发布见 https://atomgit.com/CPF-RN/ohos_react_native/tree/0.84-main
CPF-RN 鸿蒙社区：https://atomgit.com/CPF-rn

---

一、前言

随着鸿蒙生态的快速扩张，越来越多的业务方希望把既有 React Native 应用低成本地迁移到 HarmonyOS 上。迁移过程中，安全能力往往是绕不开的一环：银行卡号、身份信息、会话 Token 这些敏感数据需要加密存储，设备身份需要可信的密钥对支撑，跨端通信需要可校验的凭证体系。

鸿蒙系统为这些诉求提供了系统级答案：

• HUKS（Universal Keystore Kit）：硬件级密钥管理服务，密钥明文只存在于 TEE/安全环境内，支持 AES-256-GCM 数据加解密、RSA-2048 签名验签、HMAC 摘要；
• asset（Asset Store Kit）：关键资产存储服务，落盘数据由系统级密钥加密，适合托管口令、Token 等敏感字符串。

这些能力都是 ArkTS API，RN 的 JS 层无法直接触达。本文的核心工作，就是封装一个名为 react-native-digital-shield（数字盾） 的 RNOH 三方库，把这三类能力完整桥接给 JS：

能力分组	API	底层子系统
敏感数据加密与密钥托管	encrypt / decrypt / storeSecret / getSecret / removeSecret / hasKey / removeKey	HUKS AES-256-GCM + asset
身份凭证的签发与校验	getDeviceIdentity / issueCredential / verifyCredential	HUKS RSA-2048 + RS256 JWT
跨端身份打通	registerPeer / registerPeerSecret / verifyPeerCredential / listPeers / removePeer	JWK 公钥注册 + HS256 共享密钥

---

二、环境准备

项目	版本
开发工具	DevEco Studio 26.0（内置 SDK：DevEco Studio/sdk）
系统 API	HarmonyOS 7.0.0 / API 26（compatibleSdkVersion: 26.0.0）
React Native	0.84.1
RN 鸿蒙框架	@react-native-oh/react-native-harmony 0.84.5（RNOH）
Node.js	≥ 22.11.0
实测设备	华为（nova 14）

目录结构遵循 RNOH 三方库标准形态（与 CPF-rn 等库的组织一致）：

react-native-digital-shield/
├── src/                     # JS 侧 API 封装（发布到 npm 的部分）
│   ├── NativeDigitalShield.ts
│   ├── digitalShield.ts
│   └── types.ts
├── index.ts
├── harmony/
│   └── digital_shield/      # 鸿蒙侧库工程（产出 .har）
│       └── src/main/ets/
│           ├── DigitalShieldPackage.ets
│           ├── DigitalShieldModule.ets      # TurboModule 实现
│           ├── security/
│           │   ├── ShieldCrypto.ets         # HUKS：AES/RSA/HMAC
│           │   ├── ShieldAsset.ets          # asset：敏感数据托管
│           │   ├── IdentityService.ets      # 设备身份/JWT/跨端
│           │   ├── JwtService.ets
│           │   └── Der.ets                  # RSA 公钥 DER→JWK
│           └── utils/Encoding.ets           # base64url 等编解码
└── example/                 # RN 示例工程（harmony 子工程 + rawfile bundle）

---

三、实现步骤

3.1 定义 TurboModule：ArkTS 侧

DigitalShieldModule.ets 继承 RNOH 的 TurboModule，每个方法都是异步桥接：

export class DigitalShieldModule extends TurboModule {
  static NAME = 'DigitalShield';

  async encrypt(alias: string, plainText: string): Promise<ESObject> {
    await ShieldCrypto.ensureAesKey(alias);          // 首调自动生成密钥
    const encrypted = await ShieldCrypto.aesEncrypt(alias, utf8Encode(plainText));
    return { alias, nonce: bytesToBase64Url(encrypted.nonce),
             ciphertext: bytesToBase64Url(encrypted.cipher),
             algorithm: 'AES-256-GCM' } as ESObject;
  }
  // decrypt / storeSecret / getSecret / getDeviceIdentity / issueCredential ...
}

DigitalShieldPackage.ets 把模块注册进 RNOH 的包体系：

export class DigitalShieldPackage extends RNPackage {
  createTurboModulesFactory(ctx: TurboModuleContext): TurboModulesFactory {
    return new DigitalShieldTurboModulesFactory(ctx);
  }
}

3.2 HUKS：密钥不出安全环境

AES-256-GCM 生成与加密（密钥生成后不可导出，加解密全部在安全环境内完成）：

static async generateAesKey(alias: string): Promise<void> {
  const props: huks.HuksParam[] = [
    { tag: huks.HuksTag.HUKS_TAG_ALGORITHM, value: huks.HuksKeyAlg.HUKS_ALG_AES },
    { tag: huks.HuksTag.HUKS_TAG_KEY_SIZE, value: huks.HuksKeySize.HUKS_AES_KEY_SIZE_256 },
    { tag: huks.HuksTag.HUKS_TAG_PURPOSE,
      value: huks.HuksKeyPurpose.HUKS_KEY_PURPOSE_ENCRYPT
           | huks.HuksKeyPurpose.HUKS_KEY_PURPOSE_DECRYPT },
    { tag: huks.HuksTag.HUKS_TAG_PADDING, value: huks.HuksKeyPadding.HUKS_PADDING_NONE },
    { tag: huks.HuksTag.HUKS_TAG_BLOCK_MODE, value: huks.HuksCipherMode.HUKS_MODE_GCM }
  ];
  await huks.generateKeyItem(alias, { properties: props });
}

RSA-2048 设备身份密钥对同理，purpose 取 SIGN|VERIFY。设备身份 = 随机 UUID deviceId + HUKS 密钥对 + exportKeyItem 导出公钥（私钥永远导不出来），再解析成 Web Crypto 兼容的 JWK——这就是"跨端"的钥匙：任何一台设备/任何语言只要拿到 JWK 都能验签。

3.3 asset：敏感数据托管

static async set(alias: string, value: string): Promise<boolean> {
  const safe = ShieldAsset.safeAlias(alias);        // asset 别名不允许含 '.'
  await ShieldAsset.removeQuiet(safe);              // 覆盖语义
  const attrs: asset.AssetMap = new Map<asset.Tag, asset.Value>();
  attrs.set(asset.Tag.ALIAS, utf8Encode(safe));
  attrs.set(asset.Tag.SECRET, utf8Encode(value));   // asset.Value 只收 boolean|number|Uint8Array
  await asset.add(attrs);
  return true;
}

3.4 cpp 侧 TurboModule 声明（关键的坑，见 3.8）

RNOH 的 TurboModuleFactory 在 cpp 侧查找模块，纯 ArkTS 实现的模块也必须在 app 工程的 PackageProvider.cpp 里声明方法表：

class DigitalShieldTurboModule : public ArkTSTurboModule {
 public:
  DigitalShieldTurboModule(const ArkTSTurboModule::Context ctx, const std::string name)
      : ArkTSTurboModule(ctx, name) {
    methodMap_ = {
        ARK_ASYNC_METHOD_METADATA(encrypt, 2),
        ARK_ASYNC_METHOD_METADATA(decrypt, 3),
        ARK_ASYNC_METHOD_METADATA(storeSecret, 2),
        // ...共 15 个方法
    };
  }
};

JS 侧通过 TurboModuleRegistry.get('DigitalShield') 获取（不能用 NativeModules.DigitalShield，原因见踩坑三）。

3.5 身份凭证：RS256 JWT 签发与校验

issueCredential 用本机 HUKS 私钥对 JWT 签名（RS256），签名走 initSession → finishSession，私钥不出安全环境；verifyCredential 先用本机密钥验签（验签来源: self），再遍历已注册对端（peer:web-admin），同时校验 exp 过期时间。

3.6 跨端身份打通

• JWK 通道：registerPeer(peerName, publicKeyJwk) 把对端公钥导入 HUKS（importKeyItem，SPKI DER 格式，purpose=VERIFY），对端签发的 RS256 JWT 在本机即可验签；
• 共享密钥通道：registerPeerSecret 把对端共享密钥导入 HUKS（HMAC-SHA256），适合 Web/轻量端签发 HS256 JWT 的场景。共享密钥本身也存进 asset 托管，落盘即加密。

3.7 example 工程接入

// entry/src/main/ets/pages/Index.ets
RNApp({
  rnInstanceConfig: {
    enableCAPIArchitecture: true,      // 启用 C-API 渲染架构（踩坑二）
    arkTsComponentNames: [],
    createRNPackages: (ctx) => [new DigitalShieldPackage(ctx)],
  },
  appKey: 'DigitalShieldExample',
  jsBundleProvider: new ResourceJSBundleProvider(
    getContext(this).resourceManager, 'bundle.harmony.js'),
})

JS bundle 用 metro 打包进 rawfile：

cd example
npx react-native bundle-harmony --dev false --entry-file index.js \
  --bundle-output ./harmony/entry/src/main/resources/rawfile/bundle.harmony.js \
  --assets-dest ./harmony/entry/src/main/resources/rawfile

---

3.8 四个真机踩坑（重点！）

坑一：RNOH 0.72.146 的 RNInstanceArkTS 构造崩溃（SIGSEGV）

librnoh_app.so 启动即崩，符号化后是 strlen(NULL)：

#00 strlen+16
#02 basic_string(nullptr_t)        ← std::string(nullptr)！
#03 RNInstanceArkTS::RNInstanceArkTS
#06-08 RNOHAppNapiBridge createRNInstance/onCreateRNInstance

翻 RNInstanceArkTS.h 源码发现，ArkTS 架构分支调用基类时把 hspModuleName 硬编码成了 nullptr：

: RNInstanceInternal(id, contextContainer, std::move(taskExecutor),
                     nullptr,      // nativeResourceManager
                     nullptr),     // ← std::string hspModuleName！C++20 下可编译，运行时 strlen(NULL)

而 C-API 架构分支传的是真实字符串，所以官方示例不崩。修复：entry/oh_modules 中该头文件的 nullptr 改为 ""。

坑二：未启用 C-API 架构时 measureSurface 未实现

修完崩溃后应用秒退，jscrash 显示 Not implemented。原因是 0.72.146 已把 ArkTS 渲染路径边缘化——RNInstanceArkTS::measureSurface 直接 throw std::runtime_error("Not implemented")。解法是在 rnInstanceConfig 里声明 enableCAPIArchitecture: true，走 C-API 渲染。

坑三：JS 侧找不到模块——NativeModules.DigitalShield 是 undefined

界面能起来了，点击按钮日志全是「未找到原生模块 DigitalShield」（下图）。两个叠加原因：

1. RN 0.72 的 legacy NativeModules 没有 TurboModule 回退，必须用 TurboModuleRegistry.get('DigitalShield')；
2. cpp 侧没有声明模块，TurboModuleFactory 找不到 delegate，请求根本到不了 ArkTS（即 3.4 的方法表）。

坑四：asset 别名不允许包含 .

storeSecret('api.token', ...) 报「asset 写入被拒绝」。asset 的别名规则比 HUKS 严格，含 . 直接拒绝写入。库内做 safeAlias（. → _）规整后全链路通。

坑五（附赠）：HUKS GCM 解密必须单独传 AE_TAG

decrypt 报「The parameter does not exist」（下图）。HUKS 的 AES-GCM 加密输出布局是 [密文体 | 16 字节认证标签]，解密时必须把标签拆出来单独作为 HUKS_TAG_AE_TAG 传入、inData 只给密文体——官方示例有写，但报错信息完全看不出来：

{ tag: huks.HuksTag.HUKS_TAG_AE_TAG, value: cipher.slice(cipher.length - 16) }
// finishSession 的 inData = cipher.slice(0, cipher.length - 16)

四、真机效果展示

四个坑修完，编译签名、hdc install -r 安装真机。应用首屏：

设备身份卡片显示 UUID 形态的 deviceId 与 alg: RS256 | kid: ...——首次点击「设备身份」时，库在 HUKS 内自动生成了 RSA-2048 密钥对并导出公钥。

4.1 敏感数据加密与密钥托管

点击「加密 → 解密」：明文「卡号 6222 0000 1234 5678，CVV 123」经 HUKS AES-256-GCM 加密得到密文与 Nonce，解密后完整还原：

「密钥托管」演示 asset 全生命周期：写入 sess_9f8a7b6c5d4e3f2a1b0c → 读取一致 → 删除后读取为 null（已销毁）。

4.2 身份凭证的签发与校验

「签发凭证」产出标准 RS256 JWT（header/payload/signature 三段），有效期显示已修复为可读格式；「校验凭证」输出 校验通过 | 验签来源: self 与完整载荷：

{"iss":"74288c9c-...","sub":"user-1001","iat":1794384002,
 "org":"CPF","exp":1794384602,"jti":"f9b154c08fdb0b17",
 "scene":"digital-shield-demo","role":"admin"}

「解码凭证」按跨平台通用方式拆解 JWT（不验签），header 中可见 kid 即 HUKS 密钥别名：

4.3 跨端身份打通

「注册对端+验签」把本机 JWK 注册为对端 web-admin（模拟另一台设备），再验其签发的凭证：

已注册对端「web-admin」（RS256 公钥 JWK）
对端凭证校验通过 | 验签来源: peer:web-admin
当前对端列表: [{"name":"web-admin","type":"jwk"}]

「注册共享密钥」为对端注册 HMAC-SHA256 密钥（asset 托管），Web 端用同一密钥签发 HS256 JWT 后即可在本端 verifyPeerCredential 校验：

完整运行日志（设备身份 → 加解密 → 托管 → 签发 → 校验 → 解码 → 跨端）：

五、把代码讲透

5.1 TurboModule 为什么要注册两遍

整条链路里最费解的一环。ArkTS 侧 DigitalShieldModule 明明写好了，15 个方法全实现了，JS 里 TurboModuleRegistry.get('DigitalShield') 拿回来的却是 undefined。翻 RNOH 的 cpp 源码才明白：TurboModuleFactory 是 C++ 侧的代码，它只认 cpp 侧 delegate 注册的名字。ArkTS 实现想被找到，得先在 app 工程的 PackageProvider.cpp 里"挂号"：

class DigitalShieldPackage : public Package {
 public:
  std::unique_ptr<TurboModuleFactoryDelegate> createTurboModuleFactoryDelegate() override {
    class Delegate : public TurboModuleFactoryDelegate {
     public:
      SharedTurboModule createTurboModule(Context ctx,
                                          const std::string& name) const override {
        if (name == "DigitalShield") {
          return std::make_shared<DigitalShieldTurboModule>(ctx, name);
        }
        return nullptr;
      }
    };
    return std::make_unique<Delegate>();
  }
};

这个 Package 一行业务逻辑都没有，唯一的作用是返回一个 DigitalShieldTurboModule——而后者也只是个声明壳，方法表写清楚名字和参数个数：

methodMap_ = {
    ARK_ASYNC_METHOD_METADATA(encrypt, 2),
    ARK_ASYNC_METHOD_METADATA(decrypt, 3),
    ARK_ASYNC_METHOD_METADATA(issueCredential, 2),
    // ...共 15 个
};

两个约定值得单独记下来：

第一，方法表的参数个数必须和 ArkTS 实现严格一致。 写错了不是编译报错，是运行时悄悄少传参——这类错不会崩，只会"功能没反应"，排查起来比重编译失败烦得多。

第二，这份声明在 app 工程，不在库里。 路径是 example/harmony/entry/src/main/cpp/PackageProvider.cpp。RNOH 社区示例大多直接给 C++ TurboModule（逻辑全在 cpp，不需要 ArkTS 声明），而 HUKS、asset 这些能力只有 ArkTS API，只能走"ArkTS 实现 + cpp 声明"的组合。官方文档对这条链路写得含糊，我是对着 RNOHCorePackage 的源码把 delegate 模式抠出来的。

JS 侧的取用也有讲究：

const NativeDigitalShield =
  (TurboModuleRegistry.get('DigitalShield') as DigitalShieldNativeModule | null) ??
  (NativeModules.DigitalShield as DigitalShieldNativeModule | undefined);

TurboModuleRegistry.get 走的是 __turboModuleProxy，RN 0.72 的 legacy NativeModules 完全没有 TurboModule 回退——我最初用 NativeModules.DigitalShield，真机上一点按钮就是「未找到原生模块 DigitalShield」。后面的 NativeModules 分支是给新架构和非鸿蒙平台兜底的，主路径必须是 TurboModuleRegistry。

5.2 GCM 的密文布局：一切从那 16 字节说起

aesEncrypt 一次返回 nonce 和 cipher 两段 base64url。cipher 里其实塞了两样东西，解密时必须拆：

// GCM 密文布局：[密文体 | 16 字节 AE_TAG]
const aeadTag = cipher.slice(cipher.length - 16);
const cipherBody = cipher.slice(0, cipher.length - 16);
const props: huks.HuksParam[] = [
  // ...ALGORITHM / KEY_SIZE / PURPOSE / BLOCK_MODE / PADDING / NONCE
  { tag: huks.HuksTag.HUKS_TAG_AE_TAG, value: aeadTag }   // 标签单独传
];
const session = await huks.initSession(alias, { properties: props });
const result = await huks.finishSession(session.handle, { properties: props, inData: cipherBody });

HUKS 的 AES-GCM finishSession 输出布局是 [密文体 | 16 字节认证标签]，加密时标签混在 outData 里一起出来，解密时却要求把标签拆出来单独传 HUKS_TAG_AE_TAG，inData 只给前面的密文体。不拆的话报「The parameter does not exist」——这个报错从头到尾没出现"标签"两个字，我一度以为是 nonce 传错了，来回换三套参数。最后是在 HUKS 官方示例里翻到 AE_TAG 的写法才对上号。

顺带说两个对称性。nonce 是 12 字节随机数，每次加密重新生成，跟着密文一起走（JS 侧保管）；密钥别名就是 alias 本身，首调 ensureAesKey 自动生成——generateKeyItem 之后密钥永远出不了安全环境，JS 层拿到的永远只有密文。这不是设计洁癖，是 HUKS 的强制约束：导出接口对私钥/对称密钥直接拒绝。

5.3 签发凭证：受保护声明不许业务覆盖

issueCredential 的骨架是三步：组 payload → rsaSign → 拼三段。payload 的组装规则值得细看：

payload['iss'] = deviceId;
payload['iat'] = now;
payload['exp'] = now + effectiveExpiresIn;
payload['jti'] = bytesToHex(await ShieldCrypto.randomBytes(8));   // 防重放
const keys: string[] = Object.keys(claims);
for (let i = 0; i < keys.length; i++) {
  const key = keys[i];
  if (key === 'iss' || key === 'iat' || key === 'exp' || key === 'jti') {
    continue; // 受保护声明不允许被业务覆盖
  }
  payload[key] = claims[key];
}

iss/iat/exp/jti 是受保护声明，业务传入的同名声明直接丢弃——凭证的时效和身份不该由调用方说了算。jti 用 8 字节随机数，exp 不传时落到 DEFAULT_EXPIRES_IN_SECONDS。

签名那一步，rsaSign 走 initSession → finishSession，inData 是待签字节，outData 就是 256 字节的 RSA 签名——私钥从头到尾没离开安全环境。header 里的 kid 就是 HUKS 密钥别名，Web 端按 kid 找公钥，和本端验签遍历对端用的是同一份约定。

验签链路按优先级走三步：本机密钥（self）→ RS256 公钥对端 → HS256 共享密钥对端；exp 校验带 60 秒时钟宽容——跨端场景设备时钟不可能严格同步，卡死 1 秒都会误杀合法凭证。返回值里的 verifiedWith 告诉你是谁签的，。

5.4 手写 60 行 DER，不引三方依赖

HUKS exportKeyItem 导出的是 X.509 SPKI 格式的 DER 字节，要变成标准 JWK 必须剥掉 ASN.1 外壳、取出 n 和 e 两个大整数。两条路：引一个 ASN.1 库，或者手写一个只认 RSA SPKI 的解析器。我选了后者：

class DerReader {
  readTag(expected: number): void {
    const tag = this.data[this.pos];
    this.pos += 1;
    if (tag !== expected) {
      throw new Error('DigitalShield DER: 意外的标签 0x' + tag.toString(16));
    }
  }
  readLength(): number { /* 短格式 + 0x80 长格式，十几行 */ }
  readValue(): Uint8Array { /* 按长度切一段 */ }
}

理由很朴素：这是个安全库，多一个依赖就多一份供应链审计的成本；而 RSA SPKI 的结构是固定的（SEQUENCE → SEQUENCE → OID → BIT STRING → 里面的 n、e），60 行代码足够。rsaSpkiFromJwk 反向构造也照着这套 reader 的镜像写——注册对端公钥 importKeyItem 时用。代价也明说：这套代码只认 RSA SPKI，想支持 ECC 得另写分支，对「数字盾」的场景够用了。

5.5 asset 的覆盖语义：removeQuiet 不是洁癖

asset.add 对已存在的别名会拒绝写入（不是覆盖），所以 set 里的顺序必须是先删再写：

private static safeAlias(alias: string): string {
  let out = '';
  for (let i = 0; i < alias.length; i++) {
    const c = alias.charAt(i);
    out += c === '.' ? '_' : c;   // asset 别名不允许含 '.'
  }
  return out;
}

static async set(alias: string, value: string): Promise<boolean> {
  const safe = ShieldAsset.safeAlias(alias);
  await ShieldAsset.removeQuiet(safe);              // 覆盖语义
  // ...asset.add
}

safeAlias 把 . 映射成 _。asset 的别名规则比 HUKS 严格，含 . 直接拒绝，而且报错措辞和权限错误几乎一样——我第一眼完全没想到是别名问题，直到把 alias 一个字符一个字符换着试。统一在库内做映射还有个好处：调用方可以放心用 'api.token' 这种自然命名，set/get/remove 走同一套映射，别名空间不会错位。

覆盖语义对 Token 轮换是刚需：刷新 token 后 storeSecret 同名覆盖，旧密文即刻失效。

六、排障手记：这台机器上比 print 好用的命令

这一轮排查用得最多的不是 IDE 断点，是 hdc。按"症状 → 命令"记录几条高频组合。

应用启动即崩、日志一闪而过。 cppcrash 不在应用日志里，在 faultlogger：

hdc shell hilog -x | grep processdump      # 实时崩溃栈
hdc file recv /data/log/faultlog/faultlogger/xxx.log ./   # 拉完整日志（需权限）

拿到裸地址后用 SDK 自带的 llvm-addr2line 符号化，输入 .so 路径加崩溃偏移，输出直接指到 RNInstanceArkTS 构造函数——那次 SIGSEGV 就是这么定位到 std::string(nullptr) 的。注意无 root 的真机拉 faultlogger 文件会失败，此时从 hilog 的 processdump 输出里抠栈就够用了。

界面点了没反应。 先确认触摸到了谁、按钮在哪：

hdc shell uitest uiInput click 205 1656
hdc shell uitest dumpLayout -p /data/local/tmp/l.json

布局树里的 bounds 是 [x1,y1][x2,y2]，取中点就是点击坐标。本文所有演示截图都是"dumpLayout 算坐标 → uiInput 点击 → snapshot_display 截屏 → file recv 拉回"这条流水线出的。

改了 oh_modules 里的头文件，重编不生效。 本轮最阴的一坑。hvigor 的 ninja 增量按时间戳判断，但打包任务有独立缓存——.so 确实重编了，HAP 里还是旧的。验证方法是把 HAP 解包直接看产物：

unzip entry-default-signed.hap "libs/arm64-v8a/*" -d check
strings check/libs/arm64-v8a/librnoh_app.so | grep DigitalShield

确认 .so 新了但 HAP 旧的，rm 掉 outputs 下的 .hap 再 assembleHap，别信打包任务的"无变化"。另一个相关坑：这个工程里 RNOH 有两份拷贝（根 oh_modules 和 entry/oh_modules），ninja 实际用的是 entry/oh_modules。

260 字符路径。 Windows 上工程路径太长，ninja 直接拒编。把整个 harmony 子目录 robocopy 到 C:/dshb 构建，产物路径一下短了 100 多个字符。代价是要手工维护两边同步，好在只是几行 cp 的事。

npm file: 依赖是快照。 example/node_modules/react-native-digital-shield 是 npm install 时的拷贝，改库源码后必须同步进去再重新 bundle，否则 metro 打的还是旧代码。那次「未找到原生模块」我排查了半天 cpp 注册链路，最后发现 bundle 里压根没有新代码——教训：先验证假设链条的最末端（bundle 里到底有没有这段代码），再往上游走。

hilog 几个实用开关：hilog -r 清缓冲（抓启动崩溃前必做，不然捞到的可能是上一轮的）、hilog -x 一次性转储、grep -E 'processdump|JS_ERROR' 过滤崩溃类。另外 aa force-stop 后再 aa start，比反复杀进程可靠。

七、总结

本文基于 RNOH 0.84、鸿蒙 API26，自研 react-native-digital-shield（数字盾） RN 鸿蒙安全三方库，封装 HUKS 与 Asset 系统能力。库通过 TurboModule 桥接，支持 AES-256-GCM 加密、Asset 敏感资产托管、RSA-JWT 身份凭证签发校验，基于 JWK/HS256 实现跨端身份互通。文中给出标准库目录、核心代码实现，梳理了 TurboModule 双侧注册、GCM 标签拆分、asset 别名限制等真机疑难问题，配套 hdc 排障命令，可直接用于 RN 鸿蒙项目敏感数据安全与跨端身份校验落地。

能力层面，三类安全诉求全部落在系统级安全设施上：加密与托管用 HUKS + asset，密钥明文不出安全环境；设备身份用 HUKS RSA-2048 + JWK，天然跨端互认；凭证体系用标准 JWT，Web/iOS/Android 侧用任意 JWT 库即可互验。

工程层面，RNOH 三方库要打通四个注册点：ArkTS RNPackage、cpp PackageProvider 的 TurboModule 声明、JS TurboModuleRegistry 访问、enableCAPIArchitecture 架构开关——本文把这条踩坑链路完整记录了下来，其中 RNOH 0.72.146 的 std::string(nullptr) 崩溃属于包内缺陷，需要 patch oh_modules 中的 RNInstanceArkTS.h（nullptr → ""）。