您的位置:  首页 > 技术杂谈 > 正文

隐私计算从AI到BI:隐语SCQL数据分析引擎上线

2023-04-03 18:00 https://my.oschina.net/u/5915128/blog/8604523 隐语SecretFlow 次阅读 条评论

「隐语开源社区开放日」活动于3月29日顺利举办。此次,隐语开源社区携手中国信通院云计算与大数据研究所、深圳国家金融科技测评中心、机器之心、隐私计算联盟开源工作组以及开源中国,现场开源隐语SCQL多方安全数据分析引擎,这是业内首个将 SQL 做到多方安全计算(MPC)技术的数据分析系统,提供工业级的多方安全联合分析功能,目前已在隐语社区开源面向全球开发者免费开放,也广邀行业、企业、高校、科研的隐私计算开发者与使用者,开展了一场平等双向的开放交流。

浙江大学求是讲席教授、ACM/IEEE Fellow任奎为活动致辞,以数据要素为切入点,强调当前隐私安全是责任也是核心竞争力,隐私计算作为此间的核心技术之一,其开源是必要趋势、也是技术产业化加速的重要推动力。点击查看回放及全文

蚂蚁集团副总裁兼首席技术安全、北京大学客座教授韦韬以《数据要素大潮的技术挑战》为题进行了演讲。拆解分析了数据要素密态发展三个阶段所面临的不同挑战,在此过程中,方法体系、平台框架、技术标准等方面都面临全新变革。“目前,我们密态时代处于计算密态化和大数据密态化中间,计算密态化中的安全挑战依然是行业中非常需要重视的问题;未来大数据密态化之时,核心则要拓展技术应用深度,才足以面对数据要素全面密态化的挑战。”点击查看回放及全文

隐语框架负责人王磊对隐语SCQL多方安全数据分析引擎技术进行了详解。这是业内首个将SQL 基于多方安全计算(MPC)技术,并具有相对完整能力的数据分析系统,该系统提供工业级的多方安全联合分析功能。讲到:“在实际场景中,BI的应用面更广。对于大部分数字化转型起步较晚、正在进程中的企业,更多是通过一些规则、数据分析、人工分析的方式进行数据处理。数据要素市场化是要赋能行业应用和实体经济、是要驱动经济的整体发展。所以,BI数据分析将会逐渐变得越来越重要,隐私计算技术整体也会从顶层的企业逐步向下渗透。”点击查看回放及全文

但是,BI的隐私计算面临着巨大的挑战,主要有如下几点:

第一,高应用性。刚步入数字化转型或者正在数字化转型进程中的企业,整体技术能力有限,高应用性对于他们来说就格外重要。SQL是平常使用最多的数据分析语言,使用上手门槛相对较低,但这项技术本身是非常复杂的,MPC(多方安全计算)技术也是非常复杂的。那么,使用SQL语言完成MPC(多方安全计算)并保证正确运行,则无论站在技术难度的角度,还是站在工作量的角度来讲,都是一个巨大的工程。

第二,即时性。SQL数据分析采用交互的方式,与AI建模不同,虽然需要调参,但本身交互没有那么强。但是SQL分析则需要频繁交互,此时对整体的响应速度和时间需求则更高,需要整个分析过程中都能够及时响应,如此对整体性能的要求也会非常高。

第三,安全性。多方安全计算需要保证中间结果没有任何信息泄露,而数据分析又需要看到每次交互的结果,并且需要通过频繁交互的结果调整下一个环节。两者之间天然存在矛盾。同时,SQL的灵活性非常高,如何保证基于多方安全计算的SQL分析整体的安全性也是巨大的挑战。隐语在这些方面提出了一些新思路,进行一些尝试和探索,也取得了一些成果,但是距离真正解决这些问题还有很长的路要走。

核心发布:隐语SCQL多方安全数据分析引擎

从技术上来看,隐语基于MPC技术内核的底层抽象SPU设备,创新实现了一种多方安全数据分析系统SCQL。SCQL支持类 SQL 的查询语言,它继承了 SQL作为常用数据分析语言的普及性、易学性和高成熟度,同时还拓展了标准 SQL 的语义,可以描述基于多个数据参与方的安全数据分析任务。

如图是隐语SCQL的架构示意,它是一种多方合作语言,大致分成两个部分:上部称之为SCDB,构建了一个SCQL数据库,可以认为部分程度延续了一个传统SQL数据库的样式。对于用户来说,可以直接发起一条传统SQL请求,请求首先会经过Parser,转为抽象的语法树,再通过Planner成为Logical plan。这两个模块我们只做了少量的改动,基本也是基于开源技术。

最大的挑战在Logical plan到Execution Graph的过程,传输过程实际是一个优化的过程,原本他们之间的差异不大,但是在隐私计算场景,他们之间的差异就会变的非常大。Translator实际是进行多约束条件下的最优协议选择,这件事的本质是无论AI还是BI,隐语的整体设计理念是明密文混合,即在保证安全性的前提下,如能明文计算则尽量不进行密文计算,因为密文成本相对较高。在整个计算当中有安全性的约束,同时会有数据类型、数据来源,还有数据状态,数据状态还会随着计算过程不断发生迁移和改变,再加之每一个协议适用的模式是不同的。我们会根据所有这些约束,最终选择一个最优协议出来,这就是Translator的本质。

那么怎样理解最优协议?如上图举例,此处有四种Group By,这四种Group By是为了适应不同场景。第一种是明文Group By,当密态计算时,Group Key以及聚合表达式处于单边,直接调用即可,一个典型的明文计算场景,无需密态计算性能很好;第二种是当Group Key与聚合表达式分散在两边,但聚合函数是求和,此时可以使用同态求和Group By来实现,只需将聚合列进行同态加密后传输至Group Key列,就可以进行聚合计算,性能也相对不错;第三种是Vertical Group By,此时Key处于多方,这件事情变的更复杂,隐语提供了新的、非常高效的、非常巧妙的算法,可以将分布在多方的Group Key进行高效的合并;最后,如果所有以上优化都无法进行,也就是纯密态Group By,此时会以满足安全性为前提,进而选择一个性能最好的协议。

Translator进行优化后,就会下发至下部的计算引擎,如图展示三个party构成,具体情况中两方或三方,则与采用的协议有关。计算引擎会先将DB的数据读出并进行计算,图中右下是SCQL计算引擎的架构,其中包含很多算子实现,也是明密文的混合,明文计算直接使用Arrow进行计算,密文使用隐语已经开源的SPU,如果大家对隐语有了解,就知道两个密态计算引擎完成这个计算。

Translator在进行协议转换时会执行CCL检查,其本质上是数据拥有者可以对数据做约束定义,Translator转换时就根据约束执行检查,如果SCQL不满足安全约束条件,则会被禁止运行。

左侧是目前业内常见的多方安全分析保障模型,如前文所讲SQL是非常灵活的,解决安全性的问题无外乎两种方式,一个是事前审核,二是事后审计,事后审计很好理解,所有的执行都需要存证。事前审核现在更多是通过人工,本质把安全性责任完全抛给了用户。

假设Party1写一段SQL,此时因参与方是三方,所以Party2和Party3用户都需要审核SQL,确认没有问题再执行。这就产生两个问题:第一,对于审核者来说工作量非常大,因为SQL是频繁交互的,且难免在审核中存在疏忽误判;第二,还是与SQL的交互式相关,每一个都需要多方审核,用户的操作体验较差。

而CCL的作用如上图右,在事前审核之前,数据拥有方设置一个针对数据的CCL,是一次性的设置动作,此后用户每次提交SQL时,都需先经CCL检查,确认通过才会执行下一步,否则被禁止不能执行。接下来可以进行事前审查,即可运行至多方数据分析引擎中。

既然有CCL的安全性检查,为什么需要事前审核这个模块呢?因为,此处需要强调CCL不等于安全。与ACL相类似,不满足CCL约束一定不安全,但是满足CCL约束也不一定安全,所以CCL只是提供了辅助的工具。

CCL描述是一个三元组,数据拥有者对某一列进行约束,针对某个参与方进行约束。如Alice与Bob进行数据分析合作,有三列数据,设置CCL针对salary一列要求Bob参与者只有使用了聚合函数之后才可以看到。如此,Bob必须对salary列进行聚合之后才可以看到结果且只能看到一个统计结果,不允许看到明晰列数据,这就是CCL约束。

王磊也提到,此次SCQL发布的功能为Preview版本,虽然目前这些能力尚不完备,但Preview版本已经能够满足很多的场景,并举了几个例子:

  1. 第一是营销场景,提供输出到文件的功能,仔细看即PSI求交。
  2. 第二是用户画像,通过使用Group By,我可以对2做统计,同时还支持Y条件,基于Y条件可以做跨表数据比较,以满足用户画像场景需求。
  3. 第三是在线策略,此前我们分享过保险的场景应用,这当中就是在线线上实施施略。为什么是在线策略?如图绿色可以看到,其顾虑是某一个ID,即在这一场景当中,要查询某一个人骗保概率以及骗保可能性,类似于风控中判断这个人的风险,只针对这一个人,所以是单独的查询条件。

据悉,隐语SCQL计划会分别在6月、9月、12月开源更多能力。具体发版内容则将基于社区对Preview版本的反馈建议,酌情调整优先级。

Intel产品安全和保障部高级总监郭伟,在现场介绍了英特尔QAT解决方案,他提到:“在处理整数矩阵式计算时,将这些任务转移到QAT专用处理芯片上,可以极大地减轻CPU的负担,加快在AI算法和隐语计算中的处理速度。”接着详细展开了业界三种实现加速的方式,第一种是基于同态加密,第二种是基于TEE技术和可信计算环境,第三种是基于软件的形式。点击查看回放及全文

来自蚂蚁集团的高级技术专家祝森林,在现场介绍了分布式计算系统和隐私计算的背景,分享基于Ray框架的隐私计算案例,如何解决跨机构调度、通信和执行安全的问题。讲解了互联互通中的两种模式:黑盒和白盒,并探讨Rayfed在未来互联互通中的应用。他期望在Ray内核方面持续增强,输出一个稳定的计算底座,提高与各种计算硬件的集成应用性和性能,普惠到其它的隐私计算框架和联邦学习框架中。点击查看回放及全文

浙江大学百人计划研究员张秉晟,介绍了安全多方计算的分类、定义,详述了安全多方技术中安全假设、安全保障、性能在理想世界和现实范式的制约。分享了一些常见协议的安全风险:TextbookRSA、基于盲签名的keyword PIR/PSI协议,以及恶意敌手与1-bit泄露安全模型。最后提到了他目前正在做的一个项目“恶意安全高效协议”,后续会将成果贡献到隐语中来。点击查看回放及全文

中国信通院云计算与大数据研究所高级业务主管袁博现场分析了隐私计算互联互通壁垒过高的原因,并分享了探索过程中,建设思路的升级变化,即当前的思路更多时候从底层落地向顶层标准化做推动,进而在具体工作开展层面,从黑盒互联互通、白盒互联互通的分类层层递进,简要介绍了ECDH-PSI 算法开放协议的共建工作。分享最后,袁博也于现场总结概览了自2021年起进行的相关标准的制定及标准整体框架的构建工作。点击查看回放及全文

中银金科的算法工程师石新蕾,讲述了中银金科隐私计算团队在2022年隐私计算保护大赛中,基于多方安全计算三方纵向联合建模的赛题背景中,选择使用隐语框架的解题思路,解决方案及实战成果。主要看中隐语的MPC能力、明密文混合编程以及优势结构解,开发应用友好、安装部署方便等能力。最后讲到金融业隐私计算开源应用的现状:技术成熟度不足、内部数据治理复杂、开源知识产权风险、开源软件安全管理风险。点击查看回放及全文

厦门掌讯CTO王艺团在现场介绍道,本次分享的内容核心更侧重于“探索”, 基于丰富的行业场景经验,所以对于数据流通和数据安全之间的平衡需求深有体会,也一直在探索相关的方案。回顾这当中的探索过程,艺团也讲起:“此前在区块链、联邦学习方向进行的尝试,偏向某种特定应用方案,而不是一种通用方案。直到接触了隐私计算和隐语框架。”此次艺团在现场分享中,就聚焦「区域跨行账户风险联防联控 」场景,核心分享了开户核验、存量账户排查、区域态势感知、疑似电诈风险等应用中的开发探索经验。点击查看回放及全文

此外,来自北京邮电大学、厦门大学、浙江大学、厦门掌讯、Intel的社区之星也受邀来到开放日,任奎、深圳国家金融科技测评中心董事长钟剑以及韦韬,为这些高校、企业isv用户、行业企业的社区开放共建力量代表进行现场表彰。最后,期待更多开发者加入到隐语开源社区的共建,共同推动隐私计算行业的发展,打造出一个充满活力的开源社区!


隐语官网: https://www.secretflow.org.cn

隐语社区:https://gitee.com/secretflow

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接