CN114090638A - 基于隐私保护的联合数据查询方法及装置 - Google Patents
基于隐私保护的联合数据查询方法及装置 Download PDFInfo
- Publication number
- CN114090638A CN114090638A CN202210068068.8A CN202210068068A CN114090638A CN 114090638 A CN114090638 A CN 114090638A CN 202210068068 A CN202210068068 A CN 202210068068A CN 114090638 A CN114090638 A CN 114090638A
- Authority
- CN
- China
- Prior art keywords
- index
- data
- ciphertext
- attribute
- row
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2282—Tablespace storage structures; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
本说明书实施例提供一种基于隐私保护的数据查询方法及装置,在对由第三方对多个数据方的数据构成的联合数据表处理过程中,需要基于数据表若干属性列的排序获取相关数据的情况下,在联合数据表按照属性列的属性值排序时,针对联合数据表乱序后的乱序数据表引入行标识,并通过行标识建立索引。行标识由第三方确定,且在索引表中以密文形式存在,而候选行的行标识可以被恢复为明文,从而既加快密态查询效率,又能确保联合数据表中的密态数据***露。
Description
技术领域
本说明书一个或多个实施例涉及计算机技术领域,尤其涉及基于隐私保护的联合数据查询方法及装置。
背景技术
在大数据背景下,常常需要将不同数据方的业务数据进行综合处理。例如,在对用户信息进行分析场景中, 数据方1持有用户的身高、体重等各身体状态数据,数据方2持有用户的工资数据,数据方3持有用户的借贷数据。在对多方数据进行联合处理的过程中,数据隐私的保护和安全性成为值得关注的问题。
联合数据处理可以通过多方安全计算(MPC)等方式实现。多方安全计算可以在各个数据方不向其他数据方泄露本地数据的情况下,联合处理相关数据,实现某些业务目的。特别地,在各个数据方的数据交互不足以保证数据安全或者设备性能不能满足数据处理时效等情况下,可以借助可信第三方实现数据的安全联合处理。在第三方的参与下,为了保障数据安全,各个数据方向第三方提供本地数据通常进行加密处理,第三方得到的数据通常为密文数据。在密文数据需要反复使用的情况下,例如查询使用等,第三方可以对各个数据方的数据构建密文数据库。在数据库查询场景下,尤其是查询范围、排名等查询场景下,如何避免通过数据库索引等泄露数据隐私,在数据安全中十分重要。
发明内容
本说明书一个或多个实施例描述了一种基于隐私保护的数据查询方法及装置,用以解决背景技术提到的一个或多个问题。
根据第一方面,提供一种基于隐私保护的联合数据查询方法,用于第三方从多个数据方的联合数据表中安全查询目标数据,所述联合数据表为基于多个数据方关于若干个业务主体的联合属性数据安全建立的属性密文数据表,所述方法由所述第三方执行,包括:基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点,其中,与第一属性列对应的各个索引点是按照所述第一属性列的属性值排序而建立索引的数据分割点,所述查询目标包括在所述第一属性列上的查询值;获取与所述若干关联索引点对应的各个行标识各自的编码密文,各个行的行标识预先针对所述联合数据表乱序得到的乱序数据表按行编码确定;将相应的编码密文恢复明文行标识,从而从所述乱序数据表中确定候选行;针对各个候选行各自在所述第一属性列的属性值的密文与查询目标的密文进行比较,从而从各个候选行中确定最终的目标行,以获取所述目标行中的目标数据。
在一个实施例中,所述第三方具有可信密态计算架构,所述可信密态计算架构包括多个节点,各个节点之间通过多方安全计算处理所述联合数据表相关的业务。
在一个进一步的实施例中,所述联合数据表在所述第三方以分量密文的形式存储,单个节点针对所述联合数据表中的单个元素存储相应的单个分量密文,所述查询目标经由查询方拆分为各个分量,并由各个节点各自持有单个分量的分量密文。
在一个实施例中,所述第三方中的单个节点在可信执行环境中实现。
在一个实施例中,所述基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点包括:将所述查询值的密文依次与所述第一属性列对应的各个索引点进行大小比较;在比较结果为所述查询值与相邻两个索引点的大小相反的情况下,将该相邻两个索引点确定为所述查询目标的关联索引点。
在一个实施例中,所述基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点包括:将所述查询值的密文依次与所述第一属性列对应的各个索引点进行大小比较;在比较结果为所述查询值小于全部索引点/全部最大索引点的情况下,将最小索引点/最大索引点确定为所述查询目标的关联索引点。
在一个实施例中,针对所述第一属性列,按照以下方式确定各个索引点:从所述乱序数据表中提取所述第一属性列的各个属性值密文,与相应行标识的编码密文构成第一索引表,单个行标识的编码密文基于对该单个行标识按照预定方式加密得到;对所述第一索引表乱序后按照所述第一属性列的属性值大小进行排序;基于排序结果,按照预定属性值分割条件确定各个索引点。
在一个实施例中,所述第一属性列对应的多个索引点为所述第一属性列的各个一级索引点,单个一级索引点对应多个二级索引点,各个二级索引点将该单个一级索引点对应的行数据分割为多个二级索引属性值范围;所述基于查询目标的密文与第一属性列对应的各个索引点密文的对比,得到所述查询目标的若干关联索引点包括:将所述查询目标的密文与所述第一属性列的各个一级索引点密文进行对比,得到与所述查询目标相关联的若干一级索引点;基于所述查询目标的密文与所述若干一级索引点对应的二级索引点密文的对比,从各个二级索引点中确定所述查询目标的若干关联索引点。
在一个实施例中,所述查询目标还包括第二属性列上的查询值,所述将相应的编码密文恢复明文行标识,从而从所述乱序数据表中获取相应的各个候选行还包括:根据所述若干关联索引点对应的编码密文恢复的明文行标识得到第一明文行标识集;检测第一明文行标识集和第二明文行标识集的交集,得到若干共有行标识,其中,所述第二明文行标识集包括基于与所述查询目标在所述第二属性列相关联的各个索引点确定的各个明文行标识,所述查询目标在所述第二属性列相关联的各个索引点基于所述查询目标的密文与所述第二属性列对应的多个索引点密文的对比确定;将所述乱序数据表中与各个共有行标识分别对应的各个行确定为候选行。
在一个实施例中,所述明文行标识的编码密文在满足以下中的一项时被更新并用于重新建立索引:预定时刻到达;第三方***空闲;被恢复的明文行标识条数达到预定条数阈值。
根据第二方面,提供一种基于隐私保护的联合数据查询装置,用于第三方从多个数据方的联合数据表中安全查询目标数据,所述联合数据表为基于多个数据方关于若干个业务主体的联合属性数据安全建立的属性密文数据表,所述装置设于所述第三方,包括:
索引单元,配置为基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点,其中,与第一属性列对应的各个索引点是按照所述第一属性列的属性值排序而建立索引的数据分割点,所述查询目标包括在所述第一属性列上的查询值;
行识别单元,配置为获取与所述若干关联索引点对应的各个行标识各自的编码密文,以及,将相应的编码密文恢复明文行标识,从而从预先针对所述联合数据表乱序得到的乱序数据表中获取相应的各个候选行,其中,各个行的行标识针对所述乱序数据表按行编码确定;
目标确定单元,配置为针对各个候选行各自在所述第一属性列的属性值的密文与查询目标的密文进行比较,从而从各个候选行中确定最终的目标行,以获取所述目标行中的目标数据。
根据第三方面,提供了一种计算设备,包括存储器和处理器,其特征在于,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现第一方面的方法。
通过本说明书实施例提供的方法和装置,在对由第三方对多个数据方的数据构成的联合数据表处理过程中,需要基于数据表若干属性列的排序获取相关数据的情况下,在联合数据表按照属性列的属性值排序时,针对联合数据表乱序后的乱序数据表引入行标识,通过行标识建立索引。行标识由第三方确定,并在索引表中以密文形式存在,而候选行的行标识可以被恢复为明文,从而既加快密态查询效率,又能确保联合数据表中的密态数据***露。
附图说明
为了更清楚地说明本发明实施例的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它的附图。
图1示出可信密态计算的一个具体实施架构示意图;
图2示出根据一个实施例的第三方对联合数据表在密态下建立索引的流程示意图;
图3示出根据一个具体例子的第三方对联合数据表在密态下按照单个属性列建立索引的示意图;
图4示出根据一个实施例的基于隐私保护的数据查询流程示意图;
图5示出根据一个实施例的基于隐私保护的数据查询装置的示意性框图。
具体实施方式
下面结合附图,对本说明书提供的技术方案进行描述。
首先描述提出本说明书的技术构思所基于的业务场景。
在多个数据方的数据进行联合处理过程中,常常存在联合存储、查询的业务场景。例如,在对用户信息进行分析场景中,数据方1持有用户的身高、体重等各身体状态属性的属性值,数据方2持有用户的工资属性的属性值(具体的工资数额),数据方3持有用户的借贷属性的属性值(具体的借贷数额)。数据方1或数据方3查询工资处于前N位的用户的工资总和,或者,数据方1查询工资处于前N位的用户的借贷情况,或者,查询身高处于前M位的用户的工资总和与体重处于前M位的用户的工资总和的大小等查询需求等等业务情形。
单个数据方持有的数据具有局限性(不够全面),而各个数据方相互不想泄露本地数据。在各个数据方的数据交互不足以保证数据安全或者设备性能不能满足数据处理时效等情况下,可以借助第三方实现数据的安全联合处理。在由第三方辅助进行数据联合场景的情况下,各数据方可以预先将所持有的数据发送至第三方,第三方基于各个数据方所发送的数据,进行联合排序。当第三方针对某个数据方或其他业务方发送的业务处理请求(如查询请求)需要从联合数据中获取相应数据进行后续业务处理时,可以基于相应的排序结果得到数据查询结果。
本说明书的技术方案基于第三方采用可信密态计算(TrustEd CryptographicComputing,简称TECC)架构构建数据库的场景提出。可信密态计算是一种安全高效的密态计算方法,能够为多个数据方计算一个共同的结果,而***露任何一方的数据。图1示出了可信密态计算的一个实施架构。如图1所示,第三方可以采用多个节点(如节点A、节点B、节点C等)联合计算。多个节点通过多方安全计算(MPC)可以构建一个可信密态计算的框架。也就是说,第三方的各个节点之间相互***露数据,以安全的方式完成各种数据处理。例如,建立综合的密文数据库,并基于密文数据库获取数据进行各种业务处理。
在图1中,第三方的节点数量、数据方数量均为示例性描述,实践中可以根据实际情形确定。其中,各个数据方可以处于公网的网络环境,而第三方的各个节点可以处于某个特定的网络环境。图1中示出的高速网可以是能够高速计算、通信的网络。高速计算通常通过设备的中央处理器决定,而高速通信可以通过提高通信能力(如量子通信等)或者减少通信网关数量(如处于同一个局域网内)等方式实现。如此,多个节点经由特定网络与公网隔开,同时又可以与公网中的设备交互。具体地,与公网设备(如图1示出的各个数据方)通过接收或发送数据产生交互,而在数据处理过程中,在“特定网络”内部,由各个节点设备之间经由MPC实现。TECC的实现方可以称为服务方或第三方(以下统称为服务方),用于为各个数据方之间的联合数据处理提供服务。
如图1所示,为了避免任一个节点获知数据方的数据,单个数据方可以在将本地数据提供给TECC架构前,将本地数据拆分为多个分量,例如,数据方1可以将本地数据U拆分为U1、U2、U3的和,U1、U2、U3分别为数据U的3个分量。单个数据方可以将拆分后的多个分量的密文分别发送给各个节点。这样,对于每个来自数据方的数据来说,各个节点均持有其一个分量,只有获得多个节点上的全部分量才可以还原出相应数据。
第三方的各个节点对于接收到的数据进行多方安全计算(MPC),也就是彼此***露本地数据的情况下,得到相应的处理结果。MPC的方式例如可以是秘密分享、同态加密、混淆电路等等。在TECC中,为了进一步确保安全性和计算性能,各个节点可以处在一个可以高速运算及通信的高速网(如局域网)内,整个计算过程与公网的交互极少,从而可信密态计算可以在安全性和计算性能之间进行平衡,达到具有较理想的状态。
在一个可选的实现方式中,还可以在单个数据方和各个节点之间分别建立安全信道来增加数据安全。其中,安全信道的建立方式可以通过约定的协议、密钥、专用通信接口等中的至少一项实现,在此不再赘述。在另一个可选的实现方式中,为了更好地平衡安全性和计算性能,可信密态计算的各个节点均基于可信执行环境TEE(Trusted ExecutionEnvironment)构建。TEE是计算平台上由软硬件方法构建的一个安全区域,可保证在安全区域内加载的代码和数据在机密性和完整性方面得到保护。通过TEE技术能够确保参与者的数据只在TEE中存在,TEE的宿主、拥有者等都无法获取数据明文(在TEE不被攻破的情况)。另一方面,每个TEE 从始至终都只接触过数据分量,也就说,即便攻击者攻破一个TEE,并窃取或修改它,也不能获得有效信息。
为了***露数据隐私,各个数据方发送至第三方的数据可以是密文形式。各个数据方的数据密文可以预先上传至第三方,因此第三方可以预先对密文数据进行排序和建立索引。第三方的各个节点联合建立的联合数据表形如表1所示。这里说联合数据表是因为该数据库表是由多个数据方的数据联合建立的。另外,根据前文的描述,多个数据方向第三方提供的数据为密文形式,因此联合数据库也可以称为密文数据表。
表1 联合数据表示意
属性项1 | 属性项2 | 属性项3 | 属性项4 | …… | 属性项V |
属性值密文11 | 属性值密文12 | 属性值密文13 | 属性值密文14 | …… | 属性值密文1V |
…… | …… | …… | …… | …… | …… |
属性值密文N1 | 属性值密文N2 | 属性值密文N3 | 属性值密文N4 | …… | 属性值密文NV |
其中,构建如表1所示的联合数据表时,多个数据方的数据之间需要对齐。各个数据方可以约定数据对齐规则。一方面,按行对齐,即各行对应的目标对象一致,例如第一行均对应目标对象1(如用户1)、第二行均对应目标对象2(如用户2)……第N行均对应目标对象N。另一方面,进行列队齐,即各个目标对象按照属性项的预设顺序排列数据,如第一列均对应属性项1、第二列均对应属性项2……第V列均对应属性项V,等等。各个数据方可以按照对齐规则将本地的属性值发送至第三方。实践中,目标对象可以是用户、物品、服务项等等。在一个实施例中,目标对象可以不出现在联合数据表中,也就是说,各个数据方仅约定目标对象的对齐规则,而不发送目标对象的标识(如表1所示的情形)。在另一个实施例中,单个目标对象可以通过预定目标标识(如用户名、商品编号等等)描述,各个数据方可以将目标对象密文统一后发送至第三方,此时,目标对象标识密文可以作为联合数据表中的一个属性列看待。
在第三方为TECC形式的架构的情况下,联合数据表可以以安全形式存储于多个节点。例如,单个节点持有联合数据表的一个分片,当各个节点的联合数据表按照元素对应相加的情况下,可合成一个完整的联合数据表。单个节点持有的联合数据表分片中,单个元素以数据方的随机拆分分量作为分量密文,或者以预定加密方式(如哈希加密等)对随机拆分分量加密得到的密文。
本领域技术人员可以理解,在数据查询过程中,排序和建立索引是重要步骤。第三方对各个数据方所发送的数据进行联合排序时,常规技术可以采用基于类似保序加密方式的排序方式。该排序方式中,第三方获得各数据方上传的属性值密文,以获得待排序的表格,该表格中用户标识和各属性项的属性值是密文的(例如,表格中一行存储一个用户针对多个属性项的属性值密文,一列存储各用户针对一个属性项的属性值密文),但是各行、各列之间的顺序关系是明确的(有利于初始的数据对齐),例如第一行对应用户1、第二行对应用户2等。后续的,第三方按照一个或多个属性项进行排序,从而建立索引。
排序可以按行进行,也可以按列进行。为了描述方面,在本说明书中以按行进行为例进行说明,但不排除按列排序的情形。所谓按行排序,是指一行的数据是固定的,对该行整体在列上的位置进行排列。通常,按行排序的情况下,数据库中每行对应一条业务数据,每列对应各条业务数据中的某个数据项。例如,在前文的例子中,一行对应一个用户,一列对应一个业务属性。按行排序针对用户排序,排序依据可以是一个或多个业务属性,单个用户的排序改变时,整行数据的排序一起改变。在按行排序的情况下,可以根据某一列或多个列的数据建立索引。
常规技术中,建立索引点的方法例如有分桶、快排截断等。其中,分桶方式下可以选定分桶点(即桶的分割点,例如身高150cm、160cm等),并将这些桶的分割点作为索引点。分桶点具体可以按历史经验选,也可以“先求出最大值和最小值,然后将它们之间的范围等分”,基于待排序的列元素(属性密文)与这些分桶点的比较,可以各个元素确认属于哪一个桶。该方式下需要所有业务主体的标识与分割点比,可能会泄露业务属性的属性值分布,另外,在某个分割区间(对应一个分割步长的范围)业务主体数量较多的情况下,可能导致检索效率较低。快排截断可以采用递归的方式,如果某一个分段少于特定的阈值(比如元素数量少于1000)则停止递归,得到的所有分割点作为索引点。该方式下分割点的具体排名是泄露的,并且如果在多个列都建立索引,会得到每一个属性项在这些列上的大概排名。
根据一个具体场景,例如数据方1向第三方查询月工资为1万的用户的借贷情况,数据方1可以将查询目标的数据标识(如月工资数额U=1万)拆分为多个分量,并将各个分量(如U1、U2、U3)通过安全信道分别发送至各个节点。可选地,数据方1可以通过安全方式向第三方各个节点分别发送U的各个分量的密文,第三方的各个节点分别接收各个分量的密文,并联合利用各个分量在密文数据库中进行查询,从而反馈查询结果。作为示例,前文的业务场景下,在数据方1查询工资处于前N位的用户的借贷情况,或者,查询身高处于前M位的用户的工资总和与体重处于前M位的用户的工资总和的大小等查询需求的情况下,需要服务方对密文数据库中的数据通过多方安全计算进行联合排序,进而基于相应的排序结果得到数据查询结果。各个节点通过多方安全计算向该单个参与者反馈查询结果。
在其他业务场景中,数据方还可以向第三方发送其他业务处理请求,例如,用工资最低的用户近三年的信贷情况预测其违约风险,等等。可以理解,这种需要在第三方继续进行后续业务处理的情况下,第三方可以不反馈相应数据,而继续在本地局域网范围内进行相应数据处理。
在各种数据查询场景中,难免遇到涉及多个业务项(例如前文例子中的多个属性项)的数据查询。例如,数据方1查询工资处于前N位的用户的借贷情况,或者,查询身高处于前M位的用户的工资总和与体重处于前M位的用户的工资总和的大小,等等。第三方在使用上述排序方式对数据建立索引的过程中,可能会导致查询表格中的数据时,各行在排序列上的顺序关系暴露的情况。例如:查询目标属性项包括用户的体重属性项和工资属性项,第三方分别针对表格中体重属性项和工资属性项的属性值密文进行排序后,第三方的单个节点可能会得到形如体重第5名的人同时工资是第1名的隐私信息。这种不是很直观的信息的泄露仍然不利于隐私数据保护。
为此,本说明书对此提供一种基于隐私保护的联合数据查询的技术方案。该技术方案适用于多个数据方的数据被第三方对相应密文数据库安全持有,且由第三方根据业务需求从中安全获取目标数据的场景。该技术方案基于对多个数据方的联合数据预先排序的排序结果建立索引,避免第三方的单个节点根据排序结果推测隐私数据。本说明书的技术问题基于第三方为TECC架构提出,但实际应用不限于第三方为TECC架构,第三方也可以为单个设备或其他安全形式,本说明书对此不做限定。
下面首先描述第三方对联合数据表排序建立索引的过程。
图2示出根据一个实施例的由第三方执行的建立索引表的流程。值得说明的是,在第三方为一个设备的情况下,该流程为该第三方的单个设备完成,在第三方为类似于TECC的集群形式时,该流程可以由相应集群以多方安全计算方式完成。
如图2所示,该由第三方执行的建立索引表的流程可以包括:步骤201,对联合数据表进行乱序,得到乱序数据表;步骤202,为乱序数据表按行进行明文编码,使得每行数据对应一个明文的行标识;步骤203,用第一属性列与明文编码的行标识的编码密文构建第一索引表;步骤204,对第一索引表按照第一属性列排序,从而得到第一属性列对应的各个索引点。
首先,在步骤201中,对联合数据表进行乱序,得到乱序数据表。其中,联合数据表由第三方根据多个数据方的数据联合建立,在此不再赘述。
对联合数据表进行乱序,即打乱表格中行的前后顺序关系。在对密文数据表构建索引过程中,乱序和排序通常是配合使用的。在排序之前进行一次乱序,这样,可以使得排序时,数据表中前后行的位置不能追踪,避免了数据表中各行在排序列上的顺序关系(例如处于第一属性项排序列第a位的目标对象,即为处于第二属性项排序列第b位的目标对象)的暴露。
乱序可以是预定方式进行的,也可以是随机的,即一行业务数据在乱序后排在第几行是随机的。如图3所示,在乱序表格中的每一行,目标对象及其对应的各属性项的属性值密文之间的对应关系未改变,而行的排列顺序发生改变。特别地,在TECC架构下,乱序可以以多方安全计算方式进行。例如对某一行调到哪一行进行安全同步。
接着,通过步骤202,为乱序数据表按行进行明文编码,使得每行数据对应一个明文的行标识。其中,行标识可以是按照预定方式生成的,用于识别相应行的标识。其可以由数字、字母、符号等中的至少一个组成,例如图3中各行依次编码为0、1、2、3……。通过单个行标识,能定位到其所标识的一行数据。在后续处理过程中,单个行标识和其对应的行之间的对应关系不变,不管数据表如何乱序,仍能根据单个行标识找到其初始标识的一行数据。图3中用数据表301表示添加明文行标识的乱序数据表。值得说明的是,在本说明书的技术构思下,表301是构建各列索引的依据,在根据当前的行标识构建的索引的有效使用过程中,表301可以是一直存在的查询依据。实际场景中可以将表301作为对各属性列建立索引的基础表格,如称为建立索引的母表。
然后,根据步骤203,用第一属性列与各个行标识的密文构建第一索引表。由于明文编码的行标识与行数据紧密结合,因此,直接使用明文的行标识进行索引,可能泄露数据隐私。为此,在后续索引过程中,可以使用行标识的密文建立相关表格。行标识的密文可以是使用预定加密方式对行标识进行加密得到,也可以是通过随机分量形式拆分的分量分别存储在各个节点进行加密。这样,第三方的任意设备不能直接单独从本地持有的数据反推明文行标识。
在本说明书的实施例中,在查询数据是哪一行的情况下,通常是按照列建立相关索引的,例如,查询工资排名前100的用户,则按照“工资”对应的属性项的列进行排序查询。因此,可以将可能被作为索引的列(如记为第一属性列)抽取出来,与行标识的密文一起构建相应的索引表,如这里称为第一索引表。
参考图3所示,假设标识列为0、1、2、3……,相应的密文记为E0、E1、E2、E3……,建立索引的属性列为C1属性列,则可以将C1列的各个属性值密文和行标识的密文列提取出来,形成第一索引表。这样,排序所针对的表格体量大大减小。
如果还需要对第二列,如C2属性列建立索引,则可以将C2列的各个属性值密文和行标识的密文列提取出来,形成第二索引表。以此类推,针对各个属性列都可以建立相应的索引表。
进一步地,在步骤204中,对第一索引表按照第一属性列排序,从而得到第一属性列对应的各个索引点,为联合数据表按照第一属性列建立索引。
这里的排序,通常按照属性值大小进行。例如在C1列为工资的情况下,按照工资由高到低或由低到高的顺序进行排名,在C1列为体重数据的情况下,按照体重高低排序。这里的排序方式可以是分桶、快排截断等,在此不再赘述。排序后,所得到的目标排序表格中,各行以目标属性项对应的属性值从大到小(或者从小到大)的顺序排序。例如:目标排序表格中,目标属性项对应的最大的属性值密文所在行,位于第1行;目标属性项对应的次大的属性值密文所在行,位于第2行,以此类推,目标属性项对应的最小的属性值密文所在行,位于第N行。其中,对属性值排序过程中,属性值是密文的情况下,按照加密规则安全比较各个属性值的大小,在此不再赘述。为了进行排序,可以由第三方获取属性值密文的大小比较结果,如通过安全比较,在第三行的属性值比第二行的属性值大的情况下,可以由各个节点均将第三行与第二行调换顺序。
索引点可以理解为为了方便查询而确定的数据分割点。两个相邻索引点可以限定一个属性值范围。例如,对用户的身高建立索引,可以每10 厘米确定一个索引点,则在查询给定身高(如161厘米至168厘米)的用户数据时,可以将给定身高值(如165)与各个索引点比较,或者给定身高范围的端点与各个索引点比较,从而快速获得较小范围的候选数据。
索引点通常与属性列对应的属性取值相关,其可以预先给定,也可以根据目标对象的数量划分。例如,在工资属性列,给定索引点的情况下,给定的索引点例如为2000元、5000元、1万元、3万元等等,分割出的属性值范围如为0至2000元(不含)、2000元(含)至5000元(不含)、5000元(含)至1万元(不含)、1万元(含)至3万元(不含)、3万元(含)以上。则可以将工资属性列的属性值与给定的索引点进行比较,从而确定相应行属于被哪个或哪些索引点分割出的范围。这种情况下,每个索引点对应的数据条数可以不相等。
再例如,按照目标对象的数量划分,按照每1000人建立一个索引点,则10万个人可建立100个索引点,各个索引点如基于排序结果的第1000个人对应的工资额、第2000个人对应的工资额、第3000个人对应的工资额……等确定。每个索引点可以分割出1000个人。索引点可以是相应排名对应的工资额,也可以是基于该工资额确定的可以和下一个工资额区分开来的其他数值。举例而言,可以将第1000个人对应的工资额作为一个索引点,分割出0至该工资额(含)的1000条数据,也可以将第1001个人的工资额作为一个索引点,分割出0至该工资额(不含)的1000条数据,还可以取第1000个人对应的工资额与第1001个人的工资额之间的一个数值(如均值)作为一个索引点……
值得说明的是,各个索引点实际上将数据分为多个数据范围,例如两个相邻索引点之间的若干条数据是一个数据范围(如工资2000元至5000元的范围)。其中,根据一个实施例,单个属性列的索引点可以不含端点,而只包含将数据分割开的中间分割点,这样,索引点的数量比其将数据分隔开的属性值范围数量少1。根据另一个实施例,单个属性列的索引点也可以包含一个端点,这样,索引点的数量与将数据分隔开的范围数量一致。此时,可选地,每个索引点可以对应一个与比其小或比其大的相邻索引点构成的属性值范围。根据再一个实施例,单个属性列的索引点也可以包含两个端点,这样,索引点的数量比其将数据分隔开的属性值范围数量多1。可选地,可以通过两两相邻索引点来描述属性值范围。
根据本说明书的一个可能的设计,还可以按照各个索引点对相应的若干条数据进行分割,得到各个检索子表。分割方法如前段的描述。图3中示出了单个索引点对应着单个索引子表的示例。在一个可选的实施例中,单个索引子表中的数据可以按照相应索引的属性列中属性值的大小进行排列。如图3中按照属性列C1的第一索引点对应着第一子表,其中包含若干条通过大小顺序排列的行标识密文。在另一个可选的实施例中,第一子表中的数据可以是按照索引点进行分割后再次乱序的数据。
根据一个可能的设计,将前文描述的各个子表看作一级索引,相应索引点看作一级索引点,则还可以针对各个子表各自构建二级索引。如图3所示,二级索引可以通过二级索引点将数据分割开。二级索引点的确定方式与一级索引点类似,并将以及索引下的子表以更细粒度分割。可以理解的是,一级索引的各个索引子表建立在对目标属性列排序的基础上,因此,可以直接按照排序结果建立二级索引。例如,一级索引的一个子表对应1000个用户,二级索引的一个索引点对应200个用户,则可以将一级索引点对应的1000个属性值密文,按顺序每200个属性值密文建立一个索引点。
通常,二级索引可以在一级索引数据量较大的情况下,进一步缩小数据范围,从而加速数据查询过程。在可选的实施例中,还可以建立三级及以上级数的索引,以进一步加快数据查询速度。
图2、图3以不同形式示出了基于单个属性列构建索引的过程,在实践中,还可以针对多个属性列按照相似的方式构建索引。例如,除了工资属性列,还可以对年龄属性列、身高属性列等中的至少一列,各自重复步骤203和步骤204,确定相应的索引点,构建相应的检索表。其中,图3中,多个属性列对应的索引表均可以依据数据表301进行构建。
基于以上索引构建过程,第三方可以预先对一个属性列或多个属性列建立索引。在具体业务处理过程中,可能产生这样或那样需要基于排序的数据的业务场景。例如需要当前业务处理过程需要工资属性项的处于前10位的工资总和,或者体重排名前10的用户的年收入等等。这些业务场景可能是由单个数据方或者被允许使用联合数据的其他业务方发起的查询请求,也可能是第三方在处理其他业务时需要获取相应业务数据。在进行数据查询时,第三方可以根据查询需求,按照相应索引进行查询。
图4示出了根据一个实施例的基于隐私保护的联合数据查询流程。该流程可以基于图2、图3等方式建立的索引,从联合数据表中查询数据。具体地,第三方可以执行以下步骤:步骤401,基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点,其中,与第一属性列对应的各个索引点是按照第一属性列的属性值排序而建立索引的数据分割点,查询目标包括在第一属性列上的查询值;步骤402,获取与若干关联索引点对应的各个行标识各自的编码密文,各个行的行标识预先针对联合数据表乱序得到的乱序数据表按行编码确定;步骤403,将相应的编码密文恢复明文行标识,从而从乱序数据表中确定候选行;步骤404,针对各个候选行各自在第一属性列的属性值的密文与查询目标的密文进行比较,从而从各个候选行中确定最终的目标行,以获取目标行中的目标数据。
在步骤401中,基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点。查询目标可以对应一个精准数值,也可以对应一个查询范围。第一属性列可以是联合数据表中的任一个属性列,这里是查询的目标列。例如,查询体重为200斤的用户的工资,则查询目标对应一个精准值200斤,对应第一属性列为体重属性列。再例如,筛选工作年限为10至20年的员工,查询目标对应的是范围10-20年,第一属性列为工龄属性列;筛选年龄为35至45岁的员工,查询目标对应的是范围35至45岁,第一属性列为年龄属性列。这里,查询目标是密文形式,查询目标的密文可以基于数据方或其他业务方的查询请求确定,也可以基于第三方当前处理的业务的中间结果确定。
其中,查询目标的密文基于数据方或其他业务方(也可以统称查询方)的查询请求确定的情况下,查询方可以将查询目标(如要查询的属性列的属性值)按照第三方架构的需求转化为相应的密文发送至第三方。例如TECC架构下,查询方可以将要查询目标对应的值随机拆分为多个分量,每个分量发送至第三方的一个节点,从而要查询的属性列的值对于第三方的各个节点而言,是保密的(每个节点仅获取一个分量)。这些分量可以称为分量密文。比如,数据方1要查询体重为200斤的用户的工资,可以将体重属性200斤的属性值密文发送至第三方。
在查询目标的密文基于第三方当前处理的业务的中间结果确定的情况下,第三方在处理基于数据方或其他业务方请求的其他业务时,可以得到相应的中间结果作为查询目标。可以理解的是,为了保护数据隐私,第三方在进行数据处理过程中可以采用密文形式。则作为中间结果的查询目标也是密文形式。此时,相应的中间结果就是查询目标的密文。举例而言,第三方当前所处理的业务是统计三高患者的收入状况,则中间结果可以是三高患者的初始发病年龄集中在40至50岁,接下来要通过查询联合数据表统计年龄在40至50岁的人群收入状况,等等。
同样,针对查询目标的查询结果也可以直接作为中间结果进行后续业务处理。例如,对近五年退休的人员中养老金花费排名前5的花费项目进行统计。则第三方首先可能先要根据各个用户的年龄值,查询出近五年退休的人员的行数据作为中间结果,然后将这些行中养老金花费在各个支出项目属性项上的支出金额之和进行统计。
由于索引点是基于排序的,且各个索引点可以分割出相应属性列的各个属性值范围,因此通过查询目标的密文与索引点的密文的比对,可以确定查询目标对应的第一属性列中,与查询目标相关联的索引点,作为关联索引点。其中,在第三方采用分量密文的情况下,查询目标和索引点均采用分量形式存储在第三方,第三方可以通过安全比较等方式比较两个密文的大小。查询目标和索引点的密文比较结果可以以明文方式确定,以根据业务需求确定查询目标落入的属性值范围。查询目标落入的属性值范围可以由关联索引点分割出来。
可以理解的是,关联索引点的确定方式与索引点对属性值的分割方式、查询目标的形式相关。例如,第一属性列对应的单个索引点作为中间分隔点将第一属性列的属性值分隔为多个属性值范围的情况下,可以将查询值的密文依次与第一属性列对应的各个索引点进行大小比较,然后根据大小比较结果,将查询值所在的属性值范围对应的索引点确定为查询目标的关联索引点。例如,在查询值大于第一索引点而小于第二索引点的情况下,可以将相邻的第一索引点和第二索引点确定为关联索引点。如果比较结果为查询值小于最小索引点,可以将最小索引点确定为查询目标的关联索引点,或者比较结果为查询值大于最大索引点,还可以将最大索引点确定为查询目标的关联索引点。在其他情况下,还可以通过其他方式确定关联索引点,在此不再穷举。
在一个可选的实现方式中,在第三方预先建立了多级索引的情况下,可以先将查询目标的密文与一级索引的索引点密文对比,确定与查询目标相关联的一级索引,如得到相应的一级索引位置或者索引子表,然后将查询目标的密文与该相关联的一级索引对应的二级索引的索引点密文对比,得到与查询目标相关联的二级索引。以此类推,直至对比到末级索引(如二级索引)的索引点密文,将末级索引点确定为查询目标的关联索引点。这样可以一步一步缩小索引的候选行范围,减少后续数据处理量。
然后,在步骤402中,获取与若干关联索引点对应的各个行标识各自的编码密文。可以理解,关联索引点可以分割出包含查询查询目标在内的多个属性值对应的行。在索引构建过程中,各个属性值行还对应有针对乱序数据表按行编码得到的行标识,该行标识在索引表中以编码密文形式出现。因此,可以获取各个行分别对应的编码密文。
接着,通过步骤403,将相应的编码密文恢复明文行标识,从而从乱序数据表中确定候选行。可以理解,为了得到相关行密文数据表中相关行中的数据,可以由第三方将编码密文恢复成明文标识。例如在TECC架构下,通过随机分量方式存储在各个节点的编码密文,可以通过各个节点相互公开本地分量而得到行标识的明文数据。
在第三方建立索引过程中,提取索引表之前有一个添加行标识的乱序数据表,如图3中的表301,记录有明文行标识与乱序数据表中的各行数据的关系,因此,通过查询目标对应的明文行标识,可以获取相应行即候选行的数据。
在第三方预先建立了多列索引且当前查询为多列联合条件的查询(如查询年龄在30至45岁且体重高于150斤的用户的健康状况)的情况下,可以在第一属性列的索引中确定第一索引范围(如年龄在30至45岁)对应的关联索引点(如40岁、50岁),以及相应的行(如年龄属性值在30至40岁及40岁至50岁的行),并根据第一索引范围相应各行的编码密文恢复的明文行标识得到第一明文行标识集,在第二属性列的索引中确定第二索引范围(如体重在150斤以上)对应的关联索引点(如150斤),以及相应的候选行(如体重属性值在150斤以上的行),并根据第二索引范围相应各行的编码密文恢复的明文行标识得到第二明文行标识集。然后检测第一明文行标识集和第二明文行标识集的交集,得到若干共有行标识的明文数据。进一步地可以将乱序数据表(如图3中的表301)中与各个共有行标识对应的行确定为候选行。
在步骤404,针对各个候选行各自在第一属性列的属性值的密文与查询目标的密文进行比较,从而从各个候选行中确定最终的目标行,以获取目标行中的目标数据。可以理解,候选行基于查询目标密文与相对较少数量的索引点的比较,得到的候选行可以大大缩小目标行的查找范围。然而,实践中,还需要将查询目标的密文与候选行在第一属性列的属性值的密文进一步进行比较,以筛选出目标行。
查询目标的密文与候选行在第一属性列的属性值的密文的比较也可以包括值对值的比较、值对范围、范围对范围的比较中的至少一项。其中,值对值的比较可以是两个值是否相同的比较,值对范围的比较可以是值和范围的两端点的比较,范围对范围的比较可以是两范围的端点交叉比较,在此不再赘述。
作为示例,假设查询目标为工资在5000元至6000元的用户数据,则候选行可以是基于工资属性列的索引点确定的若干行,如工资为5000元至1万元的行。将单个候选行的工资属性值与查询目标的范围5000元至6000元的密文进行比较,则可以得到工资属性值落入5000元至6000元的候选行作为目标行,并获取目标行的密文数据。在一些实施例中,满足查询条件的目标行数量还可能为0。其中,在TECC架构下,密文数值的比较可以采用安全比较,在此不做赘述。
第三方可以获取目标行的密文数据后,该密文数据可以作为查询结果反馈至查询方,也可以作为当前业务的中间结果进行后续处理。例如,将工资在5000至6000的用户作为中间结果,对其年龄进行平均或确定数据图表,等等。
作为一个示例,假设当前业务处理过程需要年龄35至45岁的员工的处于前10位的工资均值,相应的,使用的排序数据为按年龄属性列排序的数据。假设按照年龄属性列的排序数据中,单个索引点对应10岁的年龄段。第三方可以通索引点密文与35的对比,确定大于35的第一个索引点为40,大于45的第一个索引点为50,则可以获取40索引点(对应31至40岁数据)以及50索引点(对应41至50岁数据)两个索引块的行标识的编码密文。这里,如果第三方还对年龄属性列建立有二级索引,第三方还可以进一步根据二级索引缩小范围,在此不再赘述。之后,第三方可以将相应的编码密文转换成明文,并确定明文的行标识,从而从乱序数据表中获取相应行作为候选行,如有1万条数据。然后,第三方可以将1万条候选行数据中年龄属性列的属性值,与35、45两个范围端点的数值密文进行比较,对于大于35、小于或等于45的年龄区间的候选行,确定为目标行。之后,可以将各个目标行在工资属性列的属性值密文(中间结果)以安全的密态方式求均值(后续业务处理)。
以上建立及使用索引的方法在使用的时候,会恢复某一列索引下的若干编码密文为明文。如果恢复的所有MID都来自一个列的索引下面,则不会相关信息泄露;如果使用了多列索引,且不同的列索引下面的行标识编码有相同的,就会得到相应行标识在多个列上的大概排名,比如体重排名在3000-4000的人当中有一个人的工资排名是5000-6000。这样的单个信息看起来不会有很大的问题,但是为了如果攻击者通过对大量这种信息进行分析,则可能获得更多的内容。
在TECC架构的数据查询场景下,涉及明文的恢复、范围的确定等,单个节点也可能获取一些信息。当查询次数足够多的情况下,单个节点获得的信息足够多,则单个节点被攻击者攻破的情况下,也存在数据泄露风险。
为此,在可能的设计中,可以控制恢复成明文行标识的数量。在恢复成明文的行标识的数量足够少的情况下,将所有的索引重建。例如只使用一个列相关的索引时,不需要索引重建;一旦使用超过一个列的索引时,就基于预定条件进行索引重建。在实践中可选的实现方式下,可以记录曾经恢复成明文的行标识的数量,达到预定条数阈值后就对索引进行重建。在其他可选的实现方式下,由于索引重建的过程可以异步由第三方单独完成,不需要在查询请求到来时完成,因此第三方也可以定时(如间隔1天)或在***空闲时进行索引重建。 另外,第三方还可以在本地***空闲时重建,在此不做限定。
回顾以上过程,本说明书实施例提供的方法,在对由第三方对多个数据方的数据构成的联合数据表处理过程中,需要基于数据表若干属性列的排序获取相关数据的情况下,在联合数据表按照属性列的属性值排序时,针对联合数据表乱序后的乱序数据表引入行标识,通过行标识建立索引。行标识由第三方确定,并在索引表中以密文形式存在,而候选行的行标识可以被恢复为明文,从而既加快密态查询效率,又能确保联合数据表中的密态数据***露。
特别地,在第三方为可信密态计算的情况下,即使一个节点被攻击,也能确保联合数据表中的数据安全。此时,在数据查询涉及多个属性列的情况下,为了避免恢复成明文的行标识泄露不同属性列之间的对应关系,还可以按照预定更新规则更新行标识,以及用更新后的行标识建立新的索引,从而在第三方加强数据的隐私保护。
根据另一方面的实施例,还提供一种基于隐私保护的数据查询装置。其中,该装置可以设于处理多个数据方的联合数据业务的第三方。特别地,在第三方为TECC架构的情况下,TECC架构中的各个节点分别设置有基于隐私保护的数据查询装置,这些装置通过多方安全计算,相互配合完成联合数据表中的数据查询。
如图5所示,基于隐私保护的数据查询装置500包括:索引单元501,配置为基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点,其中,与第一属性列对应的各个索引点是按照第一属性列的属性值排序而建立索引的数据分割点,查询目标包括在第一属性列上的查询值;行识别单元502,配置为获取与若干关联索引点对应的各个行标识各自的编码密文,以及,将相应的编码密文恢复明文行标识,从而从预先针对联合数据表乱序得到的乱序数据表中获取相应的各个候选行,其中,各个行的行标识针对乱序数据表按行编码确定;目标确定单元503,配置为针对各个候选行各自在第一属性列的属性值的密文与查询目标的密文进行比较,从而从各个候选行中确定最终的目标行,以获取目标行中的目标数据。
在一个实施例中,第三方具有可信密态计算架构,可信密态计算架构包括多个节点,各个节点均设有装置,各个装置之间通过多方安全计算处理联合数据表相关的业务。
在一个进一步的实施例中,单个装置针对联合数据表中的单个元素存储相应的单个分量密文,查询目标经由查询方拆分为各个分量,并由各个节点中的装置各自持有单个分量的分量密文。
根据一个可能的设计,装置500还包括索引构建单元(未示出),配置为针对第一属性列按照以下方式确定各个索引点:
从乱序数据表中提取第一属性列的各个属性值密文,与相应行标识的编码密文构成第一索引表,单个行标识的编码密文基于对该单个行标识按照预定方式加密得到;
对第一索引表乱序后按照第一属性列的属性值大小进行排序;
基于排序结果,按照预定属性值分割方式确定各个索引点。
在一个实施例中,索引构建单元还配置为,在满足以下中的一项时更新明文行标识的编码密文并重新建立索引:预定时刻到达;第三方***空闲;被恢复的明文行标识条数达到预定条数阈值。
在一个可选的实现方式中,第一属性列对应的多个索引点为第一属性列的各个一级索引点,单个一级索引点对应多个二级索引点,各个二级索引点将该单个一级索引点对应的行数据分割为多个二级索引属性值范围;索引单元501进一步配置为:
将查询目标的密文与第一属性列的各个一级索引点密文进行对比,得到与查询目标相关联的若干一级索引点;
基于查询目标的密文与若干一级索引点对应的二级索引点密文的对比,从各个二级索引点中确定查询目标的若干关联索引点。
根据一个实施例,查询目标还包括第二属性列上的查询值,行识别单元502进一步配置为:
根据若干关联索引点对应的编码密文恢复的明文行标识得到第一明文行标识集;
检测第一明文行标识集和第二明文行标识集的交集,得到若干共有行标识,其中,第二明文行标识集包括基于与查询目标在第二属性列相关联的各个索引点确定的各个明文行标识,查询目标在第二属性列相关联的各个索引点基于查询目标的密文与第二属性列对应的多个索引点密文的对比确定;
将乱序数据表中与各个共有行标识分别对应的各个行确定为候选行。
值得说明的是,图5所示的装置500与图4描述的方法相对应,图4的方法实施例中的相应描述同样适用于装置500,在此不再赘述。
根据另一方面的实施例,还提供一种计算机可读存储介质,其上存储有计算机程序,当所述计算机程序在计算机中执行时,令计算机执行结合图2、图4等所描述的方法。
根据再一方面的实施例,还提供一种计算设备,包括存储器和处理器,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现结合图2、图4等所描述的方法。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本说明书实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
以上所描述的具体实施方式,对本说明书的技术构思的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上描述仅为本说明书的技术构思的具体实施方式而已,并不用于限定本说明书的技术构思的保护范围,凡在本说明书实施例的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本说明书的技术构思的保护范围之内。
Claims (18)
1.一种基于隐私保护的联合数据查询方法,用于第三方从多个数据方的联合数据表中安全查询目标数据,所述联合数据表为基于多个数据方关于若干个业务主体的联合属性数据安全建立的属性密文数据表,所述方法由所述第三方执行,包括:
基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点,其中,与第一属性列对应的各个索引点是按照所述第一属性列的属性值排序而建立索引的数据分割点,所述查询目标包括在所述第一属性列上的查询值;
获取与所述若干关联索引点对应的各个行标识各自的编码密文,各个行的行标识预先针对所述联合数据表乱序得到的乱序数据表按行编码确定;
将相应的编码密文恢复明文行标识,从而从所述乱序数据表中确定候选行;
针对各个候选行各自在所述第一属性列的属性值的密文与查询目标的密文进行比较,从而从各个候选行中确定最终的目标行,以获取所述目标行中的目标数据。
2.根据权利要求1所述的方法,其中,所述第三方具有可信密态计算架构,所述可信密态计算架构包括多个节点,各个节点之间通过多方安全计算处理所述联合数据表相关的业务。
3.根据权利要求2所述的方法,其中,所述联合数据表在所述第三方以分量密文的形式存储,单个节点针对所述联合数据表中的单个元素存储相应的单个分量密文,所述查询目标经由查询方拆分为各个分量,并由各个节点各自持有单个分量的分量密文。
4.根据权利要求2或3所述的方法,其中,所述第三方中的单个节点在可信执行环境中实现。
5.根据权利要求1所述的方法,其中,所述基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点包括:
将所述查询值的密文依次与所述第一属性列对应的各个索引点进行大小比较;
在比较结果为所述查询值与相邻两个索引点的大小相反的情况下,将该相邻两个索引点确定为所述查询目标的关联索引点。
6.根据权利要求1所述的方法,其中,所述基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点包括:
将所述查询值的密文依次与所述第一属性列对应的各个索引点进行大小比较;
在比较结果为所述查询值小于全部索引点/全部最大索引点的情况下,将最小索引点/最大索引点确定为所述查询目标的关联索引点。
7.根据权利要求1所述的方法,其中,针对所述第一属性列,按照以下方式确定各个索引点:
从所述乱序数据表中提取所述第一属性列的各个属性值密文,与相应行标识的编码密文构成第一索引表,单个行标识的编码密文基于对该单个行标识按照预定方式加密得到;
对所述第一索引表乱序后按照所述第一属性列的属性值大小进行排序;
基于排序结果,按照预定属性值分割条件确定各个索引点。
8.根据权利要求1所述的方法,其中,所述第一属性列对应的多个索引点为所述第一属性列的各个一级索引点,单个一级索引点对应多个二级索引点,各个二级索引点将该单个一级索引点对应的行数据分割为多个二级索引属性值范围;所述基于查询目标的密文与第一属性列对应的各个索引点密文的对比,得到所述查询目标的若干关联索引点包括:
将所述查询目标的密文与所述第一属性列的各个一级索引点密文进行对比,得到与所述查询目标相关联的若干一级索引点;
基于所述查询目标的密文与所述若干一级索引点对应的二级索引点密文的对比,从各个二级索引点中确定所述查询目标的若干关联索引点。
9.根据权利要求1所述的方法,其中,所述查询目标还包括第二属性列上的查询值,所述将相应的编码密文恢复明文行标识,从而从所述乱序数据表中获取相应的各个候选行还包括:
根据所述若干关联索引点对应的编码密文恢复的明文行标识得到第一明文行标识集;
检测第一明文行标识集和第二明文行标识集的交集,得到若干共有行标识,其中,所述第二明文行标识集包括基于与所述查询目标在所述第二属性列相关联的各个索引点确定的各个明文行标识,所述查询目标在所述第二属性列相关联的各个索引点基于所述查询目标的密文与所述第二属性列对应的多个索引点密文的对比确定;
将所述乱序数据表中与各个共有行标识分别对应的各个行确定为候选行。
10.根据权利要求1所述的方法,其中,所述明文行标识的编码密文在满足以下中的一项时被更新并用于重新建立索引:
预定时刻到达;
第三方***空闲;
被恢复的明文行标识条数达到预定条数阈值。
11.一种基于隐私保护的联合数据查询装置,用于第三方从多个数据方的联合数据表中安全查询目标数据,所述联合数据表为基于多个数据方关于若干个业务主体的联合属性数据安全建立的属性密文数据表,所述装置设于所述第三方,包括:
索引单元,配置为基于查询目标的密文与第一属性列对应的多个索引点密文的对比,得到所述查询目标的若干关联索引点,其中,与第一属性列对应的各个索引点是按照所述第一属性列的属性值排序而建立索引的数据分割点,所述查询目标包括在所述第一属性列上的查询值;
行识别单元,配置为获取与所述若干关联索引点对应的各个行标识各自的编码密文,以及,将相应的编码密文恢复明文行标识,从而从预先针对所述联合数据表乱序得到的乱序数据表中获取相应的各个候选行,其中,各个行的行标识针对所述乱序数据表按行编码确定;
目标确定单元,配置为针对各个候选行各自在所述第一属性列的属性值的密文与查询目标的密文进行比较,从而从各个候选行中确定最终的目标行,以获取所述目标行中的目标数据。
12.根据权利要求11所述的装置,其中,所述第三方具有可信密态计算架构,所述可信密态计算架构包括多个节点,各个节点均设有所述装置,各个所述装置之间通过多方安全计算处理所述联合数据表相关的业务。
13.根据权利要求12所述的装置,其中,单个装置针对所述联合数据表中的单个元素存储相应的单个分量密文,所述查询目标经由查询方拆分为各个分量,并由各个节点中的所述装置各自持有单个分量的分量密文。
14.根据权利要求11所述的装置,其中,所述装置还包括索引构建单元,配置为针对所述第一属性列按照以下方式确定各个索引点:
从所述乱序数据表中提取所述第一属性列的各个属性值密文,与相应行标识的编码密文构成第一索引表,单个行标识的编码密文基于对该单个行标识按照预定方式加密得到;
对所述第一索引表乱序后按照所述第一属性列的属性值大小进行排序;
基于排序结果,按照预定属性值分割方式确定各个索引点。
15.根据权利要求11所述的装置,其中,所述第一属性列对应的多个索引点为所述第一属性列的各个一级索引点,单个一级索引点对应多个二级索引点,各个二级索引点将该单个一级索引点对应的行数据分割为多个二级索引属性值范围;所述索引单元进一步配置为:
将所述查询目标的密文与所述第一属性列的各个一级索引点密文进行对比,得到与所述查询目标相关联的若干一级索引点;
基于所述查询目标的密文与所述若干一级索引点对应的二级索引点密文的对比,从各个二级索引点中确定所述查询目标的若干关联索引点。
16.根据权利要求11所述的装置,其中,所述查询目标还包括第二属性列上的查询值,所述行识别单元进一步配置为:
根据所述若干关联索引点对应的编码密文恢复的明文行标识得到第一明文行标识集;
检测第一明文行标识集和第二明文行标识集的交集,得到若干共有行标识,其中,所述第二明文行标识集包括基于与所述查询目标在所述第二属性列相关联的各个索引点确定的各个明文行标识,所述查询目标在所述第二属性列相关联的各个索引点基于所述查询目标的密文与所述第二属性列对应的多个索引点密文的对比确定;
将所述乱序数据表中与各个共有行标识分别对应的各个行确定为候选行。
17.根据权利要求14所述的装置,其中,所述索引构建单元还配置为,在满足以下中的一项时更新所述明文行标识的编码密文并重新建立索引:
预定时刻到达;
第三方***空闲;
被恢复的明文行标识条数达到预定条数阈值。
18.一种计算设备,包括存储器和处理器,其特征在于,所述存储器中存储有可执行代码,所述处理器执行所述可执行代码时,实现权利要求1-10中任一项所述的方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210068068.8A CN114090638B (zh) | 2022-01-20 | 2022-01-20 | 基于隐私保护的联合数据查询方法及装置 |
PCT/CN2023/070474 WO2023138379A1 (zh) | 2022-01-20 | 2023-01-04 | 基于隐私保护的联合数据查询方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210068068.8A CN114090638B (zh) | 2022-01-20 | 2022-01-20 | 基于隐私保护的联合数据查询方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114090638A true CN114090638A (zh) | 2022-02-25 |
CN114090638B CN114090638B (zh) | 2022-04-22 |
Family
ID=80308954
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210068068.8A Active CN114090638B (zh) | 2022-01-20 | 2022-01-20 | 基于隐私保护的联合数据查询方法及装置 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN114090638B (zh) |
WO (1) | WO2023138379A1 (zh) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114726514A (zh) * | 2022-03-21 | 2022-07-08 | 支付宝(杭州)信息技术有限公司 | 数据的处理方法和装置 |
CN114726511A (zh) * | 2022-03-08 | 2022-07-08 | 支付宝(杭州)信息技术有限公司 | 数据处理方法和装置 |
CN115168409A (zh) * | 2022-09-05 | 2022-10-11 | 金蝶软件(中国)有限公司 | 数据库分表的数据查询方法、装置和计算机设备 |
CN115239486A (zh) * | 2022-09-20 | 2022-10-25 | 华控清交信息科技(北京)有限公司 | 一种联合数据统计方法、装置、***和可读存储介质 |
CN115587382A (zh) * | 2022-12-14 | 2023-01-10 | 富算科技(上海)有限公司 | 全密态数据处理方法、装置、设备、介质 |
CN115587233A (zh) * | 2022-10-11 | 2023-01-10 | 华能信息技术有限公司 | 一种数据标识及目录管理方法及*** |
CN115688167A (zh) * | 2022-10-13 | 2023-02-03 | 北京沃东天骏信息技术有限公司 | 匿踪查询方法、装置和***及存储介质 |
CN116166693A (zh) * | 2023-04-21 | 2023-05-26 | 支付宝(杭州)信息技术有限公司 | 一种基于密态范围索引的数据查询方法、装置以及设备 |
WO2023138379A1 (zh) * | 2022-01-20 | 2023-07-27 | 支付宝(杭州)信息技术有限公司 | 基于隐私保护的联合数据查询方法及装置 |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116886447B (zh) * | 2023-09-07 | 2024-02-13 | 中国电子科技集团公司第十五研究所 | 一种精简编解码的加密传输方法及装置 |
CN117077209B (zh) * | 2023-10-16 | 2024-02-23 | 云阵(杭州)互联网技术有限公司 | 大规模数据匿踪查询方法 |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090041253A1 (en) * | 2007-08-08 | 2009-02-12 | International Business Machines Corporation | System and method for privacy preserving query verification |
CN103049473A (zh) * | 2012-10-15 | 2013-04-17 | 新浪技术(中国)有限公司 | 一种数据查询方法及装置 |
CN103345526A (zh) * | 2013-07-22 | 2013-10-09 | 武汉大学 | 一种云环境下高效的隐私保护密文查询方法 |
CN103593476A (zh) * | 2013-11-28 | 2014-02-19 | 中国科学院信息工程研究所 | 一种面向云存储的多关键词明密文检索方法和*** |
CN106850187A (zh) * | 2017-01-13 | 2017-06-13 | 温州大学瓯江学院 | 一种隐私字符信息加密查询方法及*** |
CN111597548A (zh) * | 2020-07-17 | 2020-08-28 | 支付宝(杭州)信息技术有限公司 | 实现隐私保护的数据处理方法及装置 |
CN111914264A (zh) * | 2019-05-08 | 2020-11-10 | 华控清交信息科技(北京)有限公司 | 索引创建方法及装置、数据验证方法及装置 |
CN111935141A (zh) * | 2020-08-10 | 2020-11-13 | 合肥工业大学 | 一种针对密态数据的单次不经意抗链接的查询***与方法 |
CN112860738A (zh) * | 2021-04-23 | 2021-05-28 | 支付宝(杭州)信息技术有限公司 | 针对多方安全数据库的查询优化方法、装置和*** |
US20210350014A1 (en) * | 2020-05-05 | 2021-11-11 | Google Llc | Encrypted Search over Encrypted Data with Reduced Volume Leakage |
CN113672949A (zh) * | 2021-07-27 | 2021-11-19 | 美库尔商务信息咨询(上海)有限公司 | 用于广告多方隐私保护的数据传输方法及*** |
CN113886887A (zh) * | 2021-10-25 | 2022-01-04 | 支付宝(杭州)信息技术有限公司 | 基于多方安全计算的数据查询方法及装置 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10097522B2 (en) * | 2015-05-21 | 2018-10-09 | Nili Philipp | Encrypted query-based access to data |
US10885216B2 (en) * | 2018-01-18 | 2021-01-05 | Sap Se | Secure substring search to filter encrypted data |
CN111737751B (zh) * | 2020-07-17 | 2020-11-17 | 支付宝(杭州)信息技术有限公司 | 实现隐私保护的分布式数据处理的方法及装置 |
CN113868295A (zh) * | 2021-09-18 | 2021-12-31 | 支付宝(杭州)信息技术有限公司 | 数据查询方法、装置及多方安全数据库 |
CN114090638B (zh) * | 2022-01-20 | 2022-04-22 | 支付宝(杭州)信息技术有限公司 | 基于隐私保护的联合数据查询方法及装置 |
-
2022
- 2022-01-20 CN CN202210068068.8A patent/CN114090638B/zh active Active
-
2023
- 2023-01-04 WO PCT/CN2023/070474 patent/WO2023138379A1/zh unknown
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090041253A1 (en) * | 2007-08-08 | 2009-02-12 | International Business Machines Corporation | System and method for privacy preserving query verification |
CN103049473A (zh) * | 2012-10-15 | 2013-04-17 | 新浪技术(中国)有限公司 | 一种数据查询方法及装置 |
CN103345526A (zh) * | 2013-07-22 | 2013-10-09 | 武汉大学 | 一种云环境下高效的隐私保护密文查询方法 |
CN103593476A (zh) * | 2013-11-28 | 2014-02-19 | 中国科学院信息工程研究所 | 一种面向云存储的多关键词明密文检索方法和*** |
CN106850187A (zh) * | 2017-01-13 | 2017-06-13 | 温州大学瓯江学院 | 一种隐私字符信息加密查询方法及*** |
CN111914264A (zh) * | 2019-05-08 | 2020-11-10 | 华控清交信息科技(北京)有限公司 | 索引创建方法及装置、数据验证方法及装置 |
US20210350014A1 (en) * | 2020-05-05 | 2021-11-11 | Google Llc | Encrypted Search over Encrypted Data with Reduced Volume Leakage |
CN111597548A (zh) * | 2020-07-17 | 2020-08-28 | 支付宝(杭州)信息技术有限公司 | 实现隐私保护的数据处理方法及装置 |
CN111935141A (zh) * | 2020-08-10 | 2020-11-13 | 合肥工业大学 | 一种针对密态数据的单次不经意抗链接的查询***与方法 |
CN112860738A (zh) * | 2021-04-23 | 2021-05-28 | 支付宝(杭州)信息技术有限公司 | 针对多方安全数据库的查询优化方法、装置和*** |
CN113672949A (zh) * | 2021-07-27 | 2021-11-19 | 美库尔商务信息咨询(上海)有限公司 | 用于广告多方隐私保护的数据传输方法及*** |
CN113886887A (zh) * | 2021-10-25 | 2022-01-04 | 支付宝(杭州)信息技术有限公司 | 基于多方安全计算的数据查询方法及装置 |
Non-Patent Citations (1)
Title |
---|
李超零等: "基于分解与加密的云数据库隐私保护机制研究", 《信息工程大学学报》 * |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2023138379A1 (zh) * | 2022-01-20 | 2023-07-27 | 支付宝(杭州)信息技术有限公司 | 基于隐私保护的联合数据查询方法及装置 |
CN114726511A (zh) * | 2022-03-08 | 2022-07-08 | 支付宝(杭州)信息技术有限公司 | 数据处理方法和装置 |
CN114726511B (zh) * | 2022-03-08 | 2024-03-22 | 支付宝(杭州)信息技术有限公司 | 数据处理方法和装置 |
CN114726514B (zh) * | 2022-03-21 | 2024-03-22 | 支付宝(杭州)信息技术有限公司 | 数据的处理方法和装置 |
CN114726514A (zh) * | 2022-03-21 | 2022-07-08 | 支付宝(杭州)信息技术有限公司 | 数据的处理方法和装置 |
WO2023179185A1 (zh) * | 2022-03-21 | 2023-09-28 | 支付宝(杭州)信息技术有限公司 | 数据的处理方法和装置 |
CN115168409A (zh) * | 2022-09-05 | 2022-10-11 | 金蝶软件(中国)有限公司 | 数据库分表的数据查询方法、装置和计算机设备 |
CN115168409B (zh) * | 2022-09-05 | 2023-02-28 | 金蝶软件(中国)有限公司 | 数据库分表的数据查询方法、装置和计算机设备 |
CN115239486A (zh) * | 2022-09-20 | 2022-10-25 | 华控清交信息科技(北京)有限公司 | 一种联合数据统计方法、装置、***和可读存储介质 |
CN115587233A (zh) * | 2022-10-11 | 2023-01-10 | 华能信息技术有限公司 | 一种数据标识及目录管理方法及*** |
CN115688167A (zh) * | 2022-10-13 | 2023-02-03 | 北京沃东天骏信息技术有限公司 | 匿踪查询方法、装置和***及存储介质 |
CN115688167B (zh) * | 2022-10-13 | 2023-09-26 | 北京沃东天骏信息技术有限公司 | 匿踪查询方法、装置和***及存储介质 |
CN115587382A (zh) * | 2022-12-14 | 2023-01-10 | 富算科技(上海)有限公司 | 全密态数据处理方法、装置、设备、介质 |
CN116166693B (zh) * | 2023-04-21 | 2023-07-25 | 支付宝(杭州)信息技术有限公司 | 一种基于密态范围索引的数据查询方法、装置以及设备 |
CN116166693A (zh) * | 2023-04-21 | 2023-05-26 | 支付宝(杭州)信息技术有限公司 | 一种基于密态范围索引的数据查询方法、装置以及设备 |
Also Published As
Publication number | Publication date |
---|---|
CN114090638B (zh) | 2022-04-22 |
WO2023138379A1 (zh) | 2023-07-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114090638B (zh) | 基于隐私保护的联合数据查询方法及装置 | |
JP2019500645A (ja) | 暗号プロトコルを用いたsqlベースのデータベースの保護 | |
WO2022222813A1 (zh) | 针对多方安全数据库的查询优化的方法、装置和*** | |
US20180139045A1 (en) | Secure computation data utilization system, method, apparatus and non-transitory medium | |
US20240135026A1 (en) | Multi-party data query methods and apparatuses for data privacy protection | |
CN115080615A (zh) | 基于多方安全计算的数据查询方法及装置 | |
CN111984984B (zh) | 基于集合运算的保密统计数据共享方法及*** | |
CN109766389B (zh) | 一种基于位图索引的区块链轻客户端验证查询方法 | |
CN113255002B (zh) | 一种保护多方隐私的联邦k近邻查询方法 | |
CN112966283B (zh) | 基于多方集合求交集的垂直分区数据pparm方法 | |
KR101805878B1 (ko) | 압축을 사용하여 패스워드 공격 방해 | |
CN111143862B (zh) | 数据处理方法、查询方法、装置、电子设备和*** | |
US20130019104A1 (en) | Cell level data encryption | |
CN114584294A (zh) | 不经意分散排列方法及装置 | |
WO2017171726A1 (en) | Distributed data clustering using an untrusted mediator | |
CN112437060B (zh) | 一种数据传输方法、装置、计算机设备及存储介质 | |
CN110866277A (zh) | 一种DaaS应用的数据集成的隐私保护方法 | |
CN115242371A (zh) | 差分隐私保护的集合交集及其基数计算方法、装置及*** | |
WO2020209793A1 (en) | Privacy preserving system for mapping common identities | |
CN111046431B (zh) | 数据处理方法、查询方法、装置、电子设备和*** | |
CN115269585A (zh) | 搜索方法及装置 | |
CN111159730B (zh) | 数据处理方法、查询方法、装置、电子设备和*** | |
EP4266220A1 (en) | Method for efficient machine learning | |
Zhu et al. | Privacy-preserving affinity propagation clustering over vertically partitioned data | |
Tang et al. | Marking based obfuscation strategy to resist side channel attack in cross-user deduplication for cloud storage |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |