本文旨在深入探讨华为鸿蒙HarmonyOS Next系统(截止目前API12)的技术细节,基于实际开发实践进行总结。主要作为技术分享与交流载体,难免错漏,欢迎各位同仁提出宝贵意见和问题,以便共同进步。本文为原创内容,任何形式的转载必须注明出处及原作者。
在当今数字化金融时代,便捷性与安全性成为了金融支付领域的两大关键需求。随着移动支付的普及,无密码支付方式逐渐兴起,但同时也带来了更高的安全风险。在华为鸿蒙HarmonyOS Next系统中,我们可以借助Device Certificate Kit等强大的安全工具,为金融支付场景构建坚固的安全防护体系。
一、场景描述
金融支付类应用在无密码支付场景下,面临着诸多安全挑战。用户无需输入密码即可完成支付操作,这就要求系统必须能够精准识别支付请求是否来自合法用户的真实设备,防止恶意XX者伪造设备或劫持通信进行非法支付。例如,在用户使用手机进行快捷支付时,如何确保只有用户本人授权的设备才能发起支付请求,并且在支付过程中保证交易数据的机密性、完整性和不可抵赖性,是我们需要重点解决的问题。
二、架构设计
为了实现无密码支付的安全防护,我们以Device Certificate Kit为核心,联合Crypto Architecture Kit和Universal Keystore Kit设计了一套完善的支付认证流程。
- Device Certificate Kit
- 负责设备证书的全生命周期管理,包括证书的生成、存储、验证等。在设备初始化阶段,为设备生成唯一的证书,该证书将作为设备在支付场景中的身份标识。在支付过程中,通过验证设备证书来确保设备的真实性。
- Crypto Architecture Kit
- 提供强大的加密算法支持,用于数据加密、签名验证等操作。在支付请求中,利用其加密算法对支付数据进行加密,确保数据在传输过程中的机密性。同时,通过对签名的验证,确保支付请求的完整性和真实性。
- Universal Keystore Kit
- 用于安全地存储设备证书和相关密钥。它提供了一个安全的密钥存储环境,防止密钥被非法获取。在支付认证过程中,与Device Certificate Kit协同工作,确保证书和密钥的安全使用。
三、实现步骤
- 生成并管理设备证书,用于身份验证
- 设备在首次使用金融支付应用时,通过Universal Keystore Kit生成公私钥对。示例代码如下:
- 生成的公钥将用于生成设备证书,证书中包含设备的相关信息(如设备序列号、应用标识等),并由权威机构(或企业内部CA)进行签名。设备将证书存储在本地,同时将私钥安全地存储在Universal Keystore Kit中。
- 通过设备真实性证明确保请求来自真实设备
- 当发起支付请求时,设备首先向支付服务器发送设备证书。支付服务器使用Device Certificate Kit验证证书的有效性,包括检查证书链、证书有效期等。示例代码如下:
import { cert } from '@kit.DeviceCertificateKit';
import { BusinessError } from '@kit.BasicServicesKit';
import { util } from '@kit.ArkTS';
// 假设这是设备证书数据(实际应用中需从设备获取)
let deviceCertData = '-----BEGIN CERTIFICATE-----\n' +
'MIIBHTCBwwICA+gwCgYIKoZIzj0EAwIwGjEYMBYGA1UEAwwPRXhhbXBsZSBSb\n' +
'290IENBMB4XDTIzMDkwNTAyNDgyMloXDTI2MDUzMTAyNDgyMlowGjEYMBYGA1\n' +
'UEAwwPRXhhbXBsZSBSb290IENBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE\n' +
'HjG74yMIueO7z3T+dyuEIrhxTg2fqgeNB3SGfsIXlsiUfLTatUsU0i/sePnrKglj\n' +
'2H8Abbx9PK0tsW/VgqwDIDAKBggqhkjOPQQDAgNJADBGAiEApVZno/Z7WyDc/mu\n' +
'RN1y57uaYMjrgnvp/AMdE8qmFiDwCIQCrIYdHVO1awaPgcdALZY+uLQi6mEs/oMJ\n' +
'LUcmaag3EQw==\n' +
'-----END CERTIFICATE-----\n';
let textEncoder = new util.TextEncoder();
let encodingBlob: cert.EncodingBlob = {
data: textEncoder.encodeInto(deviceCertData),
encodingFormat: cert.EncodingFormat.FORMAT_PEM
};
let x509Cert: cert.X509Cert = {} as cert.X509Cert;
try {
x509Cert = await cert.createX509Cert(encodingBlob);
} catch (err) {
let e: BusinessError = err as BusinessError;
console.error(`createX509Cert failed, errCode:${err.code}, errMsg:${err.message}`);
}
// 证书链校验数据(假设,实际需根据真实情况配置)
const param: cert.CertChainValidationParameters = {
date: '20231212080000Z',
trustAnchors: [{
CAPubKey: new Uint8Array([0x30, 0x2a, 0x30, 0x05, 0x06, 0x03, 0x2b, 0x65, 0x70,
0x03, 0x21, 0x00, 0xbb, 0x16, 0x9d, 0x8f, 0x5c, 0x30, 0xd0, 0xba, 0x8f, 0x37, 0x6e,
0x33, 0xaf, 0x6f, 0x23, 0x71, 0x23, 0xa5, 0x49, 0x60, 0x1e, 0xd1, 0x07, 0x4b, 0xc9,
0x11, 0x7e, 0x66, 0x01, 0xba, 0x92, 0x52]),
CASubject: new Uint8Array([0x30, 0x5a, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55,
0x04, 0x06, 0x13, 0x02, 0x45, 0x4e, 0x31, 0x10, 0x30, 0x0e, 0x06, 0x03, 0x55, 0x04,
0x08, 0x13, 0x07, 0x45, 0x6e, 0x67, 0x6c, 0x61, 0x6e, 0x64, 0x31, 0x0f, 0x30, 0x0d,
0x06, 0x03, 0x55, 0x04, 0x07, 0x13, 0x06, 0x4c, 0x6f, 0x6e, 0x64, 0x6f, 0x6e, 0x31,
0x0c, 0x30, 0x0a, 0x06, 0x03, 0x55, 0x04, 0x0a, 0x13, 0x03, 0x74, 0x73, 0x31, 0x31,
0x0c, 0x30, 0x0a, 0x06, 0x03, 0x55, 0x04, 0x0b, 0x13, 0x03, 0x74, 0x73, 0x31, 0x31,
0x0c, 0x30, 0x0a, 0x06, 0x03, 0x55, 0x04, 0x03, 0x13, 0x03, 0x74, 0x73, 0x31])
}]
};
try {
const validationRes = await x509Cert.validate(param);
console.log('X509CertChain validate success');
} catch (err) {
console.error('X509CertChain validate failed');
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 接着,服务器可以进一步验证证书中的设备信息,如设备序列号是否与系统中注册的一致,确保设备的真实性。
- 利用证书和私钥对支付请求进行签名
- 设备在发送支付请求前,使用存储在Universal Keystore Kit中的私钥对支付请求数据进行签名。首先获取私钥,示例代码如下:
- 然后使用私钥对支付请求数据进行签名,假设支付请求数据为
paymentData
:
- 签名后的支付请求连同设备证书一起发送给支付服务器。支付服务器收到请求后,使用Device Certificate Kit获取证书中的公钥,然后使用公钥对签名进行验证,确保支付请求在传输过程中未被篡改。
四、技术亮点
- Device Certificate Kit和随机数生成器的协同应用,确保签名唯一性和不可预测性
- 在签名过程中,结合Crypto Architecture Kit中的安全随机数生成器生成随机数。这个随机数与支付请求数据一起进行签名,使得每次签名都具有唯一性和不可预测性。例如:
- 这样,即使XX者获取了部分签名信息,也无法伪造有效的签名,因为随机数的存在使得签名结果难以预测。
- 无密码支付场景中的防重放XX设计
- 为了防止重放XX,支付服务器在验证签名成功后,会记录支付请求的相关信息(如签名、时间戳等)。当收到新的支付请求时,首先检查是否为重放请求。例如,服务器可以维护一个最近收到的签名列表,在一定时间内,如果收到相同的签名,则认为是重放XX,拒绝该请求。同时,结合时间戳的验证,确保支付请求是在合理的时间范围内发送的,避免XX者利用过期的签名进行重放XX。
五、示例代码
- 设备真实性证明核心代码(上述已部分展示,这里补充完整流程)
import { cert } from '@kit.DeviceCertificateKit';
import { BusinessError } from '@kit.BasicServicesKit';
// 接收到设备发送的证书链后进行验证
async function verifyDeviceCertChain(certChain: cert.X509CertChain) {
// 证书链校验数据(假设,实际需根据真实情况配置)
const param: cert.CertChainValidationParameters = {
date: '20231212080000Z',
trustAnchors: [{
CAPubKey: new Uint8Array([0x30, 0x2a, 0x30, 0x05, 0x06, 0x03, 0x2b, 0x65, 0x70,
0x03, 0x21, 0x00, 0xbb, 0x16, 0x9d, 0x8f, 0x5c, 0x30, 0xd0, 0xba, 0x8f, 0x37, 0x6e,
0x33, 0xaf, 0x6f, 0x23, 0x71, 0x23, 0xa5, 0x49, 0x60, 0x1e, 0xd1, 0x07, 0x4b, 0xc9,
0x11, 0x7e, 0x66, 0x01, 0xba, 0x92, 0x52]),
CASubject: new Uint8Array([0x30, 0x5a, 0x31, 0x0b, 0x30, 0x09, 0x06, 0x03, 0x55,
0x04, 0x06, 0x13, 0x02, 0x45, 0x4e, 0x31, 0x10, 0x30, 0x0e, 0x06, 0x03, 0x55, 0x04,
0x08, 0x13, 0x07, 0x45, 0x6e, 0x67, 0x6c, 0x61, 0x6e, 0x64, 0x31, 0x0f, 0x30, 0x0d,
0x06, 0x03, 0x55, 0x04, 0x07, 0x13, 0x06, 0x4c, 0x6f, 0x6e, 0x64, 0x6f, 0x6e, 0x31,
0x0c, 0x30, 0x0a, 0x06, 0x03, 0x55, 0x04, 0x0a, 0x13, 0x03, 0x74, 0x73, 0x31, 0x31,
0x0c, 0x30, 0x0a, 0x06, 0x03, 0x55, 0x04, 0x0b, 0x13, 0x03, 0x74, 0x73, 0x31, 0x31,
0x0c, 0x30, 0x0a, 0x06, 0x03, 0x55, 0x04, 0x03, 0x13, 0x03, 0x74, 0x73, 0x31])
}]
};
try {
const validationRes = await certChain.validate(param);
console.log('X509CertChain validate success');
return true;
} catch (err) {
console.error('X509CertChain validate failed');
return false;
}
}
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 签名生成与校验核心代码
- 支付请求验证核心代码(包含防重放XX检查)
通过以上基于Device Certificate Kit的无密码支付认证设计,我们为金融支付场景构建了一个全面而强大的安全防护体系。在实际应用中,我们可以根据具体业务需求和安全标准,进一步优化和完善该体系,确保金融支付的安全与便捷。希望这篇文章能为从事鸿蒙金融支付应用开发的小伙伴们提供一些有益的参考和启发。如果在实现过程中遇到问题,不要着急,仔细分析,参考官方相关文档和示例代码,相信一定能够找到解决方案。加油!
及时雨,说的就是这篇
作者辛苦