Android应用间安全通信：证书存储与NDK跨应用通信方案咨询

一、mTLS证书的安全存储方案 #

完全可以借助Android系统的安全机制来存储mTLS所需的证书和密钥，核心依赖Android Keystore系统，结合Key Attestation能进一步强化安全性：

• Android Keystore核心用法：
  你可以在Keystore中生成或导入密钥对与证书，这些密钥会被存储在设备的安全硬件（如TEE/SE）中，无法导出到应用进程空间，从根源上避免证书被恶意提取。Java层可通过KeyStore类操作，Native层也能借助OpenSSL的ENGINE接口调用Keystore（NDK原生支持）。
• Key Attestation的作用：
  它能证明你的密钥是在Android安全环境中生成的，而非伪造。生成密钥时开启attestation选项，系统会返回包含硬件信息、密钥用途的证书链，通信双方可验证该链确认对方身份合法性，防范中间人攻击。
• 结合本地套接字的mTLS实现：
  两端从Keystore取出各自的证书和私钥，在本地套接字基础上建立TLS连接（Java层用SSLSocket，Native层用OpenSSL的SSL上下文），整个通信通道的加密与身份验证都基于安全存储的证书，无需明文保存任何敏感信息。

二、标准APP与NDK/.so的替代通信方案 #

既然纯NDK环境下无法用AIDL实现客户端绑定服务，推荐以下几种可行方案：

• Unix域套接字（复用跨应用通信通道）：
  这是最直接的方案，Native层可直接调用Linux的socket API创建Unix域套接字，Java层用LocalSocket类对接。你可以把跨应用通信和Native层通信复用同一个套接字，自定义协议格式（比如用protobuf序列化数据），同时结合前面的mTLS加密，兼顾安全性与兼容性。
• Java层作为中间桥接：
  让APP B的Java层做中转：APP A通过普通Binder/AIDL绑定APP B的Service，APP B的Java层再通过JNI调用.so中的方法。这种方式完全兼容NDK，不需要Native层处理服务绑定，只需编写JNI接口映射业务逻辑即可，实现成本低，适配大多数场景。
• 共享内存（Ashmem）：
  如果需要传输大数据（比如多媒体数据），可以用Android的Ashmem共享内存。APP A和B通过Binder传递共享内存的文件描述符，Native层直接映射内存区域读写，配合信号量（Java层用Semaphore，Native层用sem_t）做同步。注意要设置严格权限，确保只有指定进程能访问共享内存。
• 管道（Pipe）：
  Native层可创建匿名管道或命名管道，Java层通过ParcelFileDescriptor操作管道的读写端。管道实现简单，适合小数据双向通信，但效率略低于套接字。

额外注意事项 #

跨应用通信时一定要做好权限控制：比如给APP B的Service设置自定义权限，或者在连接时验证对方的包名签名，确保只有APP A能发起通信，避免被恶意进程利用。

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