“可用不可见”的隐私计算是数据安全合规流通的关键技术支撑。经过多年发展,隐私计算技术可用性增强,产品数量、类型、应用场景增多。

隐私计算当前引起了广泛关注,但作为新兴技术和早期产业,当前各类产品差异较大、质量参差不齐、鱼龙混杂,因此完善隐私计算产品规范显得尤为重要。共性的评估体系能够有效促进厂商之间有序发展,建立行业的技术门槛,提升供应商服务能力,并能帮助用户理解技术特点与能力,便于用户选型。

由于隐私计算技术和工程化发展还在突飞猛进发展,本文将结合实际情况,简要介绍现阶段中国信通院云大所关于隐私计算产品性能测试的一种初步探索方案。

1.测试总体介绍

该性能测试的总体思路是:如何利用给定资源和条件,安全、准确、高效完成特定计算任务。

目的是:在特定硬件资源、特定数据集、特定算法要求和特定结果要求条件下,模拟实际需求场景,测试不同产品安全性、准确性、耗时3类维度指标。基于以上思路目的,为测试条件一致,该测试设定了各方面的固定变量。

固定变量模拟了实际场景、具体需求和给定资源,例如:固定的数据方数量、固定的硬件资源(设定上限)、数据集大小、算法要求、输出结果要求、安全性要求(设定下限,包含通信安全、身份认证、结果安全、密码安全、算法安全、各类算法密钥长度要求等)、准确性要求(设定下限)、避免预处理(例如公开数据集需要现场随机抽取维度,若采用生成三元组方案,三元组生成时间也需计入任务耗时等等)、任务起始状态一致(数据已准备未读取)、任务结束状态一致(计算结果已生成)等等。

与此同时,以下原因也会导致结果不同,体现了各实现方案安全和性能侧重点不同以及工程化的差异,例如:未用满硬件资源,实际方案超过安全性和准确性最低门槛要求,计算方数量与数据方不一致(少部分部署方案计算方大于或小于数据方数量),技术方案拓扑结构不同(有无协调方等),采用密码学算法不同(需要经过审核),工程化优化(并行优化、分布式处理等)等等。

测试采用固定硬件资源,6台服务器,详见下图所示。

测试针对不同算法场景设置了不同的数据集,详见下图所示。

2.安全性测试介绍

隐私计算产品应满足协调方安全、通信信道安全、身份认证、计算结果安全、安全参数、密码安全等通用安全要求以及针对每项被测算法的专项安全性要求。例如安全参数测试中,对于每种密码学算法,产品也应满足该项算法层面的安全要求,对对称密码学算法SM4、AES等和非对称密码学算法SM2、RSA等各类常见密码学算法提出了最低密钥长度要求,如RSA秘钥长度应至少为2048,从而保证在产品的使用过程中,在当前安全强度下用户数据隐私不会被泄露。

安全评估方法包括专家评审、一致性检验等,需要对产品的相关发表论文、参考文献、设计文档、算法说明进行评审,并对隐私计算产品的核心代码、关键日志、抓包报文等内容进行交叉核验,确认产品的实际方案与评审内容一致。

在多方安全计算测试中,应保证计算过程中没有泄露用户输入数据,没有暴露各数据方本地的中间数据,没有暴露全局的中间数据。联邦学习测试中也要对各数据方本地的梯度等进行保护,不能暴露。

鉴于隐私计算产品的协议多样性与复杂性,本测试基于现有的密码学分析和计算分析手段对安全强度进行评估,任何新发表的攻击手段或者诸如量子计算的计算手段都可能影响安全强度,建议关注后量子密码等算法的研究与标准化过程。另外需要注意的是,隐私计算产品通常会使用多种密码学服务(密钥生成,完整性保护,安全性保护等)和多种密码学算法。一般情况下,隐私计算产品的安全强度由使用的最弱的密码学算法决定。实际使用过程中,安全强度还会被算法的具体实现方式和功能模块之间的交互影响。总而言之,对于密码算法的选择和使用,应当相当谨慎以保护整个隐私计算产品的安全性。

3.准确性测试介绍

隐私计算产品在某些特定算法中会舍弃或丢失部分精度,这导致了其最终的计算结果与明文直接计算存在一定程度的偏差,小范围内的偏差在实际应用中是可以被接受的。因此,针对各种不同的算法,应设置不同的准确性要求,计算结果满足该要求则表示其他成绩有效。

在基础运算、联合统计、特征工程(WOE、IV值计算)场景中,使用隐私计算产品得到结果和明文本地计算结果的相对误差进行核验,相对误差应保持在规定范围内;在隐匿查询、安全求交和联合预测场景中,隐私计算产品得到结果和明文本地计算结果应保持一致;在联合建模场景中,使用同样的数据集样本、输入特征、训练参数,分别使用隐私计算产品和传统机器学习程序进行建模训练。核验隐私计算产品训练得到模型的评价指标和明文基准模型的评价指标是否保持规定的误差范围内。

4.算法耗时测试介绍

面向不同场景只有在满足安全性、准确性要求前提下的计算耗时才具备有效性。基于多方安全计算和基于联邦学习的隐私计算产品在覆盖的场景范围和安全性要求上略有差异。

(1) 基础运算

场景举例:需要了解一批用户的总资产,进行多家银行多个数据方的联合加法计算。

测试简介:以两方为例,每个数据方各拥有1列1千万行的随机浮点数,分别做1千万次的安全计算,求:

1) 按行计算两个数的求和结果,批量输出结果;

2) 按行计算两个数的乘积结果,批量输出结果;

3) 按行计算两个数的大于运算结果,批量输出true or false。

(2) 联合统计

场景举例:两家银行不暴露原始数据基础上找到资产最高客户。

测试简介:以两数据方为例,每个数据方各拥有1列1千万行的随机浮点数,求:

1) 计算融合数据集的最大值,输出结果;

2) 计算融合数据集的方差,输出结果;

3) 计算融合数据集的中位数,输出结果。

此处不是1千万个数据方求最大值,而是结合实际应用场景,进行两个数据方求最大值,支持本地处理过程。以两方求最大值为例,支持本地求出最大值,再进行一次两方安全计算,得出融合数据集最大值,所有过程均计入计算耗时。

(3) 隐匿查询

场景举例:在联合用户画像等场景中,保护本机构的查询信息,数据服务方提供匹配查询结果却无法获知具体对应哪个查询对象,查询方也无法知晓数据服务方除了匹配命中内容以外的其余信息。

测试简介:隐匿查询采用亿级的数据集。考虑实际需求场景,平衡效率和安全,分别设置了百级不可区分度查询,和百万级不可区分度查询。

(4) 安全求交

场景举例:营销场景中,在保证本机构和外部数据方的数据安全前提下,得到本机构从与外部数据方共有的用户群,实现目标客群筛选。

测试简介:考虑实际场景需求,分别设置了平衡场景和非平衡场景。以两个数据方举例

1)平衡场景:数据方A、数据方B的数据总量均为一亿行,两方数据的相交率为50%,进行安全求交。

2)两方非平衡场景:数据方A数据总量为一亿行、数据方B的数据总量为十万行,两方数据的相交率为50%,进行安全求交。

(5) 特征工程

场景举例:通过特征工程、联合建模、联合预测等计算,在构建联合风控模型场景中,打通本机构数据与外部数据,在原始数据不出域基础上共建信贷风控模型,提升个人信贷业务和小微信贷业务的风控精准度和效率。

测试简介:采用epsilon数据集,数据集已完成归一化、标准化。40万行样本作为训练集,10万行样本作为测试集。原始数据集包含2000维特征,为防止测试前提前优化,随机抽取900维特征用于计算。各家在测试前不知晓最终用的特征。

两个数据方时,每个数据方都持有450个特征,只有一个数据方持有标签信息,采用等宽分箱,计算每个特征的WOE、IV值。

(6) 联合建模

测试简介:采用epsilon数据集,数据集已完成归一化、标准化。40万行样本作为训练集,10万行样本作为测试集。原始数据集包含2000维特征,为防止测试前提前优化,随机抽取900维特征用于计算。各家在测试前不知晓最终用的特征。

两个数据方时,每个数据方都持有450个特征,只有一个数据方持有标签信息,不同测试中分别考察两个数据方和三个数据方的逻辑回归、XGBoost等联合建模场景。

(7) 联合预测

测试简介:使用联合建模中创建的模型对10万行样本进行离线批量预测,同测试中分别考察两个数据方和三个数据方的逻辑回归、XGBoost等联合预测场景。

5.问题及展望

隐私计算产品性能仍需提升。在技术特点上,隐私计算相关的密码学技术有“牺牲性能换来安全”的特点,这使其在计算效率上存在先天劣势,虽然算法、算力、硬件的优化在促进隐私计算性能不断提升,但由于其加密机理复杂、交互次数多,但当应用逐步向更大数据规模、更多数据方、更复杂场景推广时,性能不足仍将成为关键阻碍。

隐私计算产品安全边界和等级有待形成共识。隐私计算产品安全边界和等级的界定需要考虑不同行业、不同技术的区别,也要平衡实际应用中准确性和计算效率的要求,因此作为一项保护数据隐私的新技术,因技术复杂,市场尚不成熟,隐私计算产品的安全边界和安全等级有待深入研究讨论形成对安全等级统一划分的共识。

隐私计算产品方案差异较大,互联互通面临阻碍。隐私计算存在多种不同的技术路径,技术路径之间的差异明显,同一技术路径下不同产品的实现也相互独立,数据资源的互相互通只能基于不同的技术平台分块实现,增加了应用侧的使用成本。作为数据合规流通的关键技术手段,隐私计算技术打造的产品和平台下一步有广泛互联互通的趋势。因此隐私计算跨平台互联互通的技术规范和评估方法也是下一步要关注的重点。

当前隐私计算技术和工程化发展仍在突飞猛进,本次结合实际场景对当前阶段特定条件下的产品级性能表现进行了初步探索,未来中国信通院仍将继续凝聚各方力量,完善测试方法和测试手段,升级完善隐私计算相关规范标准,共同促进隐私计算行业发展。

声明:本文来自云计算与大数据研究所,版权归作者所有。文章内容仅代表作者独立观点,不代表士冗科技立场,转载目的在于传递更多信息。如有侵权,请联系 service@expshell.com。