CN111898154A - 一种协商式的移动应用隐私数据共享协议签署方法 - Google Patents

Abstract

本发明公开了一种协商式的移动应用隐私数据共享协议签署方法，其步骤包括：1)基于设定的移动应用隐私数据共享协议，确定通用模板中所含属性以及每个属性的值域或参考值；其中所述通用模板为通用协议模板；2)基于所述通用模板中的共享隐私数据PDS，在目标行业定制约束下生成对应目标行业的行业模板；3)企业基于所述行业模板确定协议标题、概述、参与方以及描述部分，并在企业定制约束下对PDS中的共享项E进行企业定制，生成企业模板；4)用户基于所述企业模板选择共享项E，生成用户协议并签名；5)企业对步骤4)签名后的用户协议进行签名保存并发给对应用户。本发明可以达到良好的协商效果，从而使得用户的隐私数据得到有效保护。

Description

一种协商式的移动应用隐私数据共享协议签署方法

技术领域

本发明属于数据共享安全领域，涉及一种协商式的移动应用隐私数据共享协议签署方 法—NSMA-PDSA(Negotiable Signing for Mobile Application-oriented PrivacyData Sharing Agreement)。用户在使用某移动应用前，需要签署隐私政策，为协商性不强的“阅读-同意”式 签署方法；本发明针对隐私政策中关于隐私数据共享的部分，将其改进为隐私数据共享协议， 并使用可协商的“行业定制-企业定制-用户选择-双方签名”式签署方法，使得隐私数据共享部 分可以单独成为一个协议附在隐私政策中。

背景技术

如今，移动应用隐私数据共享已经成为十分普遍的现象，为了保障共享时的安全，各国 纷纷出台法律，要求移动应用提供商根据自身情况告知其隐私政策，对其收集、使用、共享 用户数据情况进行明示。隐私政策的出现在一定程度上对规范移动应用隐私数据共享起到了 作用，但其作用有限，一个重要原因是：现有隐私政策为单向的“霸王条款”(并非协议)，且 缺乏有效的协商式签署方法：用户往往只能同意，否则就不能使用该移动应用。

针对此问题，W3C组织曾提出了个人隐私偏好平台(Platform for PrivacyPreferences,P3P) 项目，其思想是通过匹配web应用的隐私政策和用户的隐私偏好来决定是否允许将用户的隐 私数据提供给web应用使用，但是由于P3P项目需要手动设置、工作量大、面向的是网站应 用、因此未能被大部分APP采用且项目本身也已经暂停。至今，仍然没有一种有效的协商式 签署方法被提出或使用。

虽然协商式签署方法还有待突破，但相关研究成果较多，主要包括：隐私政策、数据共 享协议两方面。“隐私政策(privacy policy)”(隐私策略、隐私声明、隐私保护条例、隐私保 护协议等)是由网站/移动应用制定的，针对网站/移动应用在采集、传播、分享、使用以及发 布个人信息的各阶段，所涉及到的责任和义务、免责情形等说明的法律条款。随着隐私保护 的相关法律出台，各类移动应用隐私政策随之出现，引起了学者的广泛关注，成为一个新的 研究热点。国内研究主要集中在：对各网站/移动应用的隐私政策特点调研，指出不足，提出 意见等方面。例如，谈咏梅等人，重点分析了门户、BBS、商务、游戏四类网站的隐私政策， 发现其普遍存在“标准不一致”，“没有违约责任说明”等问题。徐敬宏运用对比分析法，对五 家中英文网站的隐私政策，重点从语义表达上的角度(包括措辞、句型、句法等)进行研究， 发现英文网站的隐私政策相对而言，内容更全面且更易理解。郑嘉楠研究了包括Flicker、Youtube、Myspace等五个主流网站的隐私政策，发现其针对未成年人、非会员的隐私保护相 关内容不够充分，并在此基础上提出我国Web2.0网站隐私政策的改进建议。申琦选取我国搜 索引擎、社交等6类共计49家网站，从一般规定、信息收集、信息共享三个方面出发，发现 其隐私政策存在“命名混乱”、“不好找到”、“用户信息收集说明不够明确”等问题。朱颖选取 我国11类共96个移动应用的隐私政策进行宏观分析，从中可以看出，移动应用隐私政策相 对于传统应用存在同样的问题：水平参差不齐(表现为：内容有长有短，写法有专业有业余 等)、存在霸王条款现象，缺乏协商和监督机制等。任怡林针对80款涉及不同类别的移动应 用隐私政策呈现状态、呈现方式、告知情况等做了详细调研分析，给出完善隐私政策的对策 以及管理和保护用户个人信息的建议。

国外在隐私政策上也有一定研究。在健康方面，Graber等人研究了80个不同的健康应用 网站的隐私政策、Lisa Rosenfeld等人针对76个主流痴呆症app，调研了其隐私政策存在情况 以及用户数据保护情况，发现只有46％的app拥有可用的隐私政策，并且其内容的明确性有 待加强。在金融方面，Lewis等人对相等数量(25家)的银行、信用咨询公司和支票兑现公 司的隐私政策进行研究。由于大多数用户都不容易读懂健康类和金融类移动应用的隐私政策， 因此分析隐私政策的存在性、可读性是上述研究的重点。在社交平台方面，Winkler等人针对 “不少用户不清楚他们哪些信息会被公开使用”这一现象，对脸书、谷歌、推特、领英的隐私 政策各方面进行调研，发现隐私政策已经成为了受法律保护的合同，但超过半数以上的用户 无法理解隐私政策内容，因此作者建议一方面社交平台要提高隐私政策的易读性、设计更有 效的阅读机制，另一方面用户也应该更加清楚隐私策略的变化和自己的隐私数据涉及情况。

数据共享协议是约束各方如何共享数据的电子协议，对于数据共享协议框架，国外研究 相对国内起步较早，且成果较多。研究主要分为协议文本建模及改进、建模后的冲突分析两 方面。对于协议文本建模及改进方面，最早开始于Swarup等人。他们基于现实世界文本方式 的协议备忘录(memoranda of agreement,MOA)，提出了数据共享协议(datasharing agreement, DSA)框架的概念。Swarup等人定义了DSA框架的组成元素，并基于数据流图表，将文本 协议关于共享描述的部分建模为一组分布式时态逻辑谓词(distributed temporal logic,DTL) 表示的义务(obligation)。然而，Swarup给出的框架过于强调数据流动，而对共享方式描述 较少，而且缺乏系统实现。Ilaria Matteucci等人扩展了DSA框架的组成元素，添加了包括DSA 标题、机构、时期、权利(授权)等字段，并针对义务和权利字段，提出了一种对用户可读、 系统内编码、可以翻译成POLPA的语言CNL4DSA(controlled natural language for data sharing agreement)，以便后续进行DSA协议分析。Alvaro E.Arenas等人，受CNL4DSA语言的启发， 在权利、义务字段基础上，提出了禁止字段，并对这三个字段提出了Event-B规范语言。与CNL4DSA不同的是，Event-B语言将协议条款与系统功能分开建模，将条款语句表示为时间 逻辑公式(temporal-logicformulas,TLF)，该公式可在不同系统直接进行冲突检查、行为验证。 然而，隐私相关语句(例如使用目的定义)并没有在模型中给出定义。Benjamin Aziz等人使 用微软定义的一种简单而强大的规范语言SecPAL，添加了处罚字段，考虑了包括诸如罚款及 其相关风险之类的定量因素，将允许、处罚和义务语句表示为LTL断言。上述框架都是基于 策略描述语言进行建模，然而，策略描述语言的灵活性，可扩展性和易用性不够强，因此 Mingyuan Li等人基于本体技术，提出了与上述框架不同的DSAP框架，填补了DSA框架隐 私约束的空白，同时还兼顾灵活性和准确性。另外，作者以健康研究数据共享为场景，通过 提供适当的词汇和结构来在基于链接数据的审核日志中记录隐私事件，证明了DSAP隐私策 略中静态和动态语义都可以使用DSAP本体捕获，从而实现DSAP相关隐私约束的事后审计。

对于建模后的冲突分析方面，聚焦于DSA的研究相对较少一些。Maurizio Colombo等人， 基于CNL4DSA语言，开发出一种基于Maude(POLPA解析框架)和Web Service构建的DSA 协议分析器，以识别权利字段中条款之间可能存在的冲突或不兼容之处。JoseFran.Ruiz等人， 在DSA框架的基础上，提出了DSA生态系统设想，包括DSA创作、DSA分析和冲突解决、 DSA映射、DSA管理、DSA仓库等子系统，并进行可视化展示。GianpieroCostantino等人， 基于CNL4DSA语言，提出了更快的冲突检测和分析算法，并通过改变DSA中规则的数量和 每个规则中术语的数量来评估其性能。实验表明，不到半分钟或大约半分钟，该算法即可分 析多达数百条权利、禁止、责任语句。

发明内容

针对现有隐私政策“霸王条款”及其缺乏协商式签署方法的问题，本发明提出一种协商 式的移动应用隐私数据共享协议签署方法(Negotiable Signing for MobileApplication-oriented Privacy Data Sharing Agreement，即NSMA-PDSA)。本发明采用“行业定制-企业定制-用户选 择-双方签名”的签署方法，通过引入协商约束，使得协议签署具有可协商性。其中，将协商 约束定义为行业定制约束、企业定制约束和用户选择约束三种形式，行业监管者可以基于通 用协议模板，在行业定制约束的作用下实现行业协议模板的定制；企业可以基于行业协议模 板，在企业定制约束的作用下实现企业协议模板的定制；用户可以基于企业协议模板，在用 户选择约束下生成用户协议。最后，双方进行数字签名，表示企业、用户双方达成一致，因 此结合这四个步骤可以达到良好的协商效果。

概念定义：

·移动应用提供商：指向用户提供移动应用服务的服务机构，通常为互联网企业，简称 “企业”。

·移动用户：移动应用使用者，简称“用户”。

·协商：指共同商量以便取得一致意见的过程。

·行业定制是指某行业的监管、标准制定者等相关方(统称“监管者”)，根据行业现状， 基于通用协议模板(简称“通用模板”)的相关属性，在行业定制约束下，生成适合与本行业的行业协议模板(简称“行业模板”)的过程。

·企业定制是指企业根据自身需求，基于行业模板的相关属性，在定制约束下，生成企 业协议模板(简称“企业模板”)的过程。

·用户选择是指用户根据自身需求，基于企业模板的相关属性，在选择约束下，生成用 户协议的过程。

移动应用隐私数据共享协议要素构成：

移动应用隐私数据共享协议完整的定义为：<Title,Overview,Principals,Date,Valid_Time, Description,PDS,CP,D_Sign>

Title为协议标题，是协议的简短概括(例如，某移动应用隐私数据共享协议)，为企业自行编写的字符串。

Overview为协议概述，是协议制定意义、基于隐私数据共享提供的服务等简单说 明，为企业自行编写的字符串。

Principals为参与方，定义为一个元组：<user,company>。user,company分别代表用户和企业身份的唯一标识，由用户和企业各自给出，都为字符串类型。

Date为生效日期，是协议被双方确认签名时的日期，为日期类型。

Valid_Time为有效时长，是协议具有法律效力的时长，可以用来解决隐私政策中 “没有个性化的隐私数据保存期限”问题，此属性企业给出范围供用户选择，单位通常为月， 因此Valid_Time∈N*(N*为正整数)。

Description为描述，是一个对隐私数据共享进行说明的法条集合，由企业自行编 写给出(例如，术语和定义，双方职责，需求变更说明等)，定义为：Description＝{D₁,D₂,…, D_i}。i为隐私数据共享说明性法条的个数，i∈N*。对任意D_i∈Description，定义为：D_i＝<D_{i_name},D_{i_content}>。D_{i_name}为第D_i的名称,D_{i_content}为第D_i的内容。

PDS为共享的隐私数据。为了解决隐私政策中“隐私数据共享方面描述粒度不细” 的问题，PDS对应一个类型的隐私数据(而不是某一个隐私数据)，这是因为：不同类型的 隐私数据往往会有共性，并且同时出现，在服务器端呈现的是同一张数据表，便于管理；反之，如果隐私数据不加分类，以某个隐私数据为基本对象进行协商的话，框架实现时将会过于繁琐。与Description类似，PDS定义为：PDS＝{pds₁,pds₂,…,pds_j}。j为所有隐私 数据类型数，j∈N^*。对任意pds_j∈PDS，定义为：pds_j＝{E₁,E₂,…,E_n}。E₁,E₂,…,E_n分别 代表n个共享项，n∈N^*。对pds中的任意E_i，定义为：E_i＝{e_{i_1},e_{i_2},…,e_{i_t}}。e_{i_1},e_{i_2},…, e_{i_t}分别代表共享项中的t个元素，t∈N^*。

CP为奖励与赔偿认定，是用户应用Description中的奖励与赔偿相关计算方法，根据PDS、Valid_Time进行奖励与赔偿程度测算得到的，定义为一个元组：<Compensation,Punishment>。Compensation为奖励认定，Punishment为赔偿认定，且二者皆∈Q₊。

D_Sign为数字签名，是一个协议具有法律效力的标志，需要双方的参与。与传统签名不同，数字签名除具有签名者(SignA/B)，签名值(Sign_value)以外，还需要对签名 算法(Sign_method)、摘要算法(Hash_method)、摘要值(Hash_value)、公钥值(Public_key)进行说明，因此D_Sign定义为一个元组：<Hash_method,Hash_value,SignA,SignB>。 Hash_mothod，Hash_value为字符串类型，SignA/B的定义为一个元组：<Sign_method, Sign_value,Public_key>。Sign_method，Sign_value为字符串类型，Public_key为整型。

协商约束定义：

协商约束包括行业定制约束、企业定制约束和用户选择约束。

(1)行业定制约束

行业定制约束规定了监管者在定制行业模板时需要遵守的约束，监管者可以在行业定制 约束下，基于通用模板对PDS和pds进行行业定制。因此行业定制约束包含两种定制类型： 针对PDS的行业定制约束(简称PDS行业定制约束)和针对pds的行业定制约束(pds行业 定制约束)。

1)PDS行业定制约束

PDS行业定制约束是指基于通用模板对PDS的行业定制操作必须满足PDS行业定制约 束。PDS行业定制约束定义如下：

<I_PDS,G_PDS,I_PDS′,ci1>

这里G_PDS表示通用模板中的PDS，I_PDSˊ表示针对行业需求对G_PDS进行补充的元 素所构成的集合，ci1表示PDS行业定制约束条件，定义为：

<ci1_name,ci1_expression>

ci1_name为PDS行业定制约束条件名称，ci1_expression为PDS行业定制约束条件逻辑表达式， ci1_name＝“ci1”，

I_PDS表示基 于G_PDS和I_PDSˊ在约束条件ci1的作用下进行行业定制操作生成的行业模板中的PDS。

2)pds行业定制约束

pds行业定制约束是指基于通用模板对pds(pds∈PDS)的行业定制操作必须满足pds行 业定制约束。pds行业定制约束定义如下：

<I_pds,G_pds,I_pds′,ci2>

这里G_pds表示通用模板中的pds，I_pdsˊ表示针对行业需求对G_pds中进行补充的元素 所构成的集合，ci2表示pds行业定制约束条件，定义为：

<ci2_name,ci2_expression>

ci2_name为pds行业定制约束条件名称，ci2_expression为pds行业定制约束条件逻辑表达式， ci2_name＝“ci2”，

I_pds表示基于G_pds 和I_pdsˊ在约束条件ci2的作用下进行行业定制操作生成的行业模板中的pds。

(2)企业定制约束

企业定制约束规定了企业在定制企业模板时需要遵守的约束，企业可以在企业定制约束 下，基于行业模板对共享项E进行企业定制。因此，企业定制约束只包含一种，即针对E的 企业定制约束(简称E企业定制约束)。

1)E企业定制约束

E企业定制约束是指基于行业模板对E的企业定制操作必须满足E企业定制约束。E企 业定制约束定义如下：

<C_E,I_E,C_E′,cc>

这里I_E表示行业模板中的E，C_Eˊ表示针对企业需求对I_E中的元素进行补充，补充 的元素所构成的集合，cc表示E企业定制约束条件，定义为：

<cc_name,cc_expression>

cc_name为企业定制约束条件名称，cc_expression为企业定制约束条件逻辑表达式，cc_name∈ {“cc-empty”,“cc-single”,“cc-multiple”}，

其对应关系如表1所示。 C_E表示基于I_E和C_Eˊ在约束条件cc的作用下进行定制操作生成的企业模板中的E。

表1为E企业定制约束条件

(3)用户选择约束

设置的用户选择约束规定了用户在选择用户协议时需要遵守的约束，用户可以在用户选 择约束下，基于企业模板对E和Valid_Time进行用户选择。因此，用户选择约束包含两种： 针对E的用户选择约束(简称E用户选择约束)和针对Valid_Time的用户选择约束(简称 Valid_Time用户选择约束)。

1)E用户选择约束

E用户选择约束是指基于企业模板对E的用户选择操作必须足E用户选择约束。E用户 选择约束定义如下：

<U_E,C_E,cu1>

这里C_E表示企业模板中的E，cu1表示E用户选择约束条件，定义为：

<cu1_name,cu1_expression>

cu1_name为E用户选择约束条件名称，cu1_expression为E用户选择约束条件逻辑表达式，cu1_name∈{“cu1-cannot”,“cu1-empty”,“cu1-single”,“cu1-multiple”}，cu1_expression∈{“U_E＝＝C_E”,…}， 其对应关系如表2所示。U_E表示C_E在约束条件CU的作用下进行选择操作生成的用户协 议中的E。

表2为E用户选择约束条件

2)Valid_Time用户选择约束

Valid_Time用户选择约束是指基于企业模板对Valid_Time的用户选择操作必须足 Valid_Time用户选择约束。Valid_Time用户选择约束定义如下：

<U_V,C_V,cu2>

这里C_V表示企业模板中的Valid_Time，cu2表示Valid_Time用户选择约束条件，定义 为：

<cu2_name,cu2_expression>

cu2_name为Valid_Time用户选择约束条件名称，cu2_expression为Valid_Time用户选择约束条件 逻辑表达式，cu2_name＝“cu2-single”，

U_V表 示C_V在约束条件cu2的作用下进行定制操作生成的用户协议中的Valid_Time。

NSMA-PDSA的实现流程：

本签署方法包括行业定制、企业定制、用户选择、双方签名四个阶段，涉及到的具体流 程如图1所示。

1)行业定制阶段：在此阶段，监管者基于通用模板，重点针对PDS、pds，在行业定制约束下生成针对特定行业的行业模板。

2)企业定制阶段：在此阶段，企业基于行业模板，由法律相关人士编写协议标题、概述、 参与方以及描述部分，由业务相关人员根据实际情况，对E在企业定制约束下进行定制，从 而生成企业模板。

3)用户选择阶段：在此阶段，用户基于企业模板，结合自身情况，对E在选择约束下进 行选择，从而得到用户协议。

4)双方签名阶段，用户首先对上一步的选择确认无误并对用户协议进行签名，随后企业 再对相同的用户协议签名，此时用户协议生效。最后，企业将生效协议自己保存一份、发送 至用户一份，并各自保管，对应图1中的第1步至第8步。本发明选择Park提出的多重签名方 案进行协议签名，并做了技术改进或处理。其中，除了第7步以外，任何一步的失败都需要双 重签名阶段重新开始。双方签名阶段涉及到的符号如表3所示，其具有签名流程为：

表3双方签名阶段符号说明

(1)移动用户密钥生成及协议发送

移动用户通过移动终端生成SK1、SK2、PK1、PK2，有

随后，移动用户将SK2、PK1发送至TTP、将M发送至移动应用平台 和TTP，对应图1中的第1步。

(2)TTP对PK1、SK2认证

TTP接收到M、SK2、PK1后，验证其合法性。如果通过验证，对PK1进行认证签名(记为Vc)，即Vc＝PK1^D(SKTTP)mod N，并将Vc发送至移动应用平台，对应图1中的第2步。

(3)移动应用平台验证Vc有效性

移动应用平台得到Vc后，验证其有效性，如果有效，则从其中取出PK1并告知移动终 端Vc有效，对应图1中的第3步。

(4)移动用户第一部分签名A1发送及验证

移动用户利用SK1对M签名(记为A1)，即A1＝H(M)^D(SK1)mod N，并将A1发送至 移动应用平台，对应图1中的第4步。

(5)移动应用平台验证A1有效性及发送B

移动应用平台利用PK1验证A1的有效性，即H(M)＝A1^E(PK1)mod N是否成立，如果 有效则生成PKB、SKB，并利用SKB对M签名(记为B)，即B＝H(M)^D(SKB)mod N，将 PKB、B返回至移动用户，对应图1中的第5步。

(6)移动用户验证B有效性及发送A

移动用户利用PKB验证B的有效性，即H(M)＝B^E(PKB)mod N是否成立，如果有效则 生成SKA、PKA。其中，

随后，利用SKA对M签名(记为A)，即 A＝H(M)^D(SKA)modN，并将PKA、A发送至移动应用平台，对应图1中的第6步。

(7)移动应用平台验证A有效性

移动应用平台利用PKA验证A的有效性，即H(M)＝A^E(PKA)mod N是否成立，如果 有效则告知用户协议完成，如果无效则执行争议解决，对应图1中的第7步。另外，除本步 骤外，其余步骤若是出现异常，则直接返回至步骤1。

(8)争端解决

移动应用平台将A1、B发送至TTP，TTP验证其有效性。有效则TTP利用SK2对M签 名(记为A2)，即A2＝H(M)^D(SK2)mod N，随后通过A1，A2计算出A，即A＝A1· A2(mod N)。随后，TTP将A发送至移动应用平台；将B发送至移动终端，对应图1中的 第8步。

TTP对移动用户的部分密钥进行认证签名，记为

本发明的创新点：

1.给出协商约束的定义

在给出协议要素构成的基础上，本发明给出重点要素的协商约束，包括行业定制约束、 企业定制约束和用户选择约束。行业定制约束规定了监管者在定制行业模板时需要遵守的约 束规则，计算机可以基于行业定制约束，对通用模板中PDS和pds的定制操作进行限制，例 如，允许添加、多选，不允许空选；企业定制约束规定了企业在定制企业模板时需要遵守的 约束规则，计算机可以基于企业定制约束，对行业模板中的定制操作进行限制，例如，允许 添加、单选，不允许多选；用户选择约束规定了用户在选择用户协议时需要遵守的约束规则， 计算机可以基于行业定制约束，对企业模板中E的选择操作进行限制，例如，允许单选、多 选，不允许空选。

2.实现了协商式的协议签署方法

基于协议要素构成以及协商约束，本发明给出“行业定制-企业定制-用户选择-双方签名” 的签署方法实现流程。在行业定制阶段，通用模板中的PDS、pds在行业定制约束下生成针 对特定行业的行业模板，被此行业的监管者公布。在企业定制阶段，企业基于行业模板，由 法律相关人士编写协议标题、概述、参与方以及描述部分，由业务相关人员根据实际情况， 对E在企业定制约束下进行定制，从而生成企业模板。在用户选择阶段，用户基于企业模板， 结合自身情况，对E在选择约束下进行选择，即：对不可选择约束作用的共享项进行阅读， 对其他约束作用的共享项、单项选择约束作用的有效时长进行选择，从而得到用户协议。最 后是签署阶段，用户首先对企业提供的选择集合(如不满意可放弃使用该移动应用)、自身的 选择满意并签名，随后企业再签名并将生效协议自己保存一份、发送至用户一份，并各自保 管。

3.改进和补充了多重签名方案

主要包括：优化实现流程，当Vc无效时，可以更早的终止签名，节省部分流程的开销。 内嵌签名至XML文档中，使得协议内容和签名是一体的，减少了发送签名的开销，并且从 形式上和纸质协议保持相同。使用Servlet技术进行通信，更高效地实现整个多重签名方案的 跨平台过程，具体如下所示：

(1)优化实现流程

Park提出的方案中，Alice将Vc发送至Bob是在协议执行阶段的第1步，而本发明将此 步骤提前至协议初始化阶段，即TTP对Alice的PK1、SK2认证后，TTP直接将Vc发送至Bob。更改之后由于Bob提前获得Vc，因此如果Vc无效，可以更早的终止签名，节省部分 流程的开销。

(2)内嵌签名至XML文档中

本发明将xml语言的用户协议设计为嵌入式签名结构，双方在签名时只对非签名标签进 行签名，再将对方签名以及自己的签名填入到xml文档的签名标签中，从而生成最终的生效 协议。这样以来，协议内容和签名是一体的，减少了发送签名的开销，并且从形式上和纸质 协议保持相同。

(3)使用Servlet技术进行通信

本发明利用Servlet技术处理对方传来的HTTP请求，请求中可以包含公钥、签名、Vc等 相关信息，并可以根据不同的url产生并返回不同的响应，例如企业验证用户部分签名、用 户验证企业签名等，从而更高效地实现整个多重签名方案的跨平台过程。

本发明实现了NSMA-PDSA原型系统并在其上进行了实验以评测本发明的可行性，重点 包括：行业模板定制、企业模板定制、用户协议生成、用户协议签署、生效协议查看五个功 能。

(1)行业模板定制功能

在此功能使用前，需要人为设定协议的通用模板。本系统对通用模板设置了12个pds，5 个E及其值域和协商约束。随后，测试样例在行业定制约束下定制了3个pds：个人基本资 料、个人财产信息、个人生物识别信息，最后，测试样例在行业定制约束下定制了5个共享 项。

(2)企业模板定制功能

测试样例基于行业模板，在企业定制约束下重点对3个pds进行定制。

(3)用户协议生成功能

测试样例基于企业模板，在用户选择约束下重点对3个pds进行选择。

(4)用户协议签署功能

本系统参考Park提出的多重签名方案，使用RSA算法进行实现。

(5)用户协议查看功能

测试样例将签署后的用协议由XML格式被转换为法律形式的自然语言文本。

与现有技术相比，本发明的积极效果为：

本发明通过引入协商约束，使得协议签署具有可协商性，可以达到良好的协商效果，从 而使得用户的隐私数据得到有效保护。

附图说明

图1为本发明的实现流程图。

图2为本发明的原型系统架构图。

具体实施方式

下面结合附图和实施步骤对本发明进一步说明。

原型系统中有四个实体，其架构设计如图2所示，监管者对应的是行业监管平台、企业 对应的是移动应用平台、用户对应的是移动终端、可信第三方对应的是TTP，如图1所示。

1)行业监管平台主要提供基于web的行业模板生成：在模板定制中，行业监管平台参 考通用模板，在遵守行业定制约束的情况下，根据行业业务需求定制行业模板，并将其保存 至本地，当接收到企业的文件下载请求时将行业模板文件发送至移动应用平台。

行业监管平台主要包含了协议定制功能模块，其功能和接口设计如下表3所示。

表4为行业监管平台功能模块

2)移动应用平台主要提供基于web的企业模板生成和协议签署服务：在模板定制中， 移动应用平台参考行业模板，在遵守行业定制约束的情况下，根据自身业务需求定制企业模 板，并将其保存至本地，当接收到用户的文件下载请求时将企业模板文件发送至用户；在协 议签署中，需要移动应用平台验证用户的签名、产生并发送自身签名、与TTP交互完成争端 解决、生成并保存生效协议。移动应用平台主要包含了协议定制、协议签署两个功能模块， 其功能和接口设计如下表4所示。

表5为移动应用平台功能模块

3)移动终端，主要提供基于安卓的协议生成和签署服务。当用户在某个移动应用注册账 号成功时，触发协议选择模块，发送模板下载请求至移动平台并获得响应(企业模板文件)。 随后，根据解析的企业模板文件及其约束规则，向用户提供选项，并根据用户的选择认定奖 励和赔偿方案。当用户完成协议的协商并确认签名时，协议被转化为XML文件，与TTP交 互，包括Vc生成、争端解决等，完成多重签名；当用户查看协议时，生效协议由XML语言 转化为法律形式的自然语言供用户查看。移动终端主要包含了协议协商、协议签署、协议查 看三个功能模块，其功能和接口设计如下表5所示。

表6为移动终端模块

4)TTP作为可信的第三方，主要提供基于web的协议签署服务。其功能是保存用户的 部分密钥(SK2、PK1)、根据PK1生成认证签名Vc、争端解决。TPP主要包含了协议签署 一个功能模块，其功能和接口设计如下表6所示。

表7为TTP模块

Claims (10)

1.一种协商式的移动应用隐私数据共享协议签署方法，其步骤包括：

1)基于设定的移动应用隐私数据共享协议，确定通用模板中所含属性以及每个属性的值域或参考值；其中所述通用模板为通用协议模板；

2)基于所述通用模板中的共享隐私数据PDS，在目标行业定制约束下生成对应目标行业的行业模板；

3)企业基于所述行业模板确定协议标题、概述、参与方以及描述部分，并在企业定制约束下对PDS中的共享项E进行企业定制，生成企业模板；

4)用户基于所述企业模板选择共享项E，生成用户协议并签名；

5)企业对步骤4)签名后的用户协议进行签名保存并发给对应用户。

2.如权利要求1所述的方法，其特征在于，设定的移动应用隐私数据共享协议为：<Title,Overview,Principals,Date,Valid_Time,Description,PDS,CP,D_Sign>；其中，Title为协议标题，Overview为协议概述，Principals为参与方，Date为生效日期，Valid_Time为有效时长，Description为协议的描述，PDS为共享的隐私数据，CP为奖励与赔偿认定，D_Sign为数字签名。

3.如权利要求1或2所述的方法，其特征在于，PDS＝{pds₁,pds₂,…,pds_j}；j为所有隐私数据类型数，pds_j为第j类隐私数据；pds_j＝{E₁,E₂,…,E_n}，其中E_n代表第n个共享项，对每一类隐私数据pds中的第i个共享项E_i，E_i＝{e_{i_1},e_{i_2},…,e_{i_t}}，e_{i_t}代表共享项E_i中的t个元素，i＝1～n。

4.如权利要求3所述的方法，其特征在于，步骤2)中，基于通用模板对PDS和pds进行行业定制约束；其中对PDS进行行业定制约束为：<I_PDS,G_PDS,I_PDSˊ,ci1>，G_PDS表示通用模板中的PDS，I_PDSˊ表示针对目标行业需求对G_PDS进行补充的元素所构成的集合，ci1表示PDS行业定制约束条件，I_PDS表示基于G_PDS和I_PDSˊ在约束条件ci1的作用下进行行业定制操作生成的行业模板中的共享隐私数据PDS；对pds进行行业定制约束为：<I_pds,G_pds,I_pdsˊ,ci2>，G_pds表示通用模板中的pds，I_pdsˊ表示针对目标行业需求对G_pds中进行补充的元素所构成的集合，ci2表示pds行业定制约束条件，I_pds表示基于G_pds和I_pdsˊ在约束条件ci2的作用下进行行业定制操作生成的行业模板中的一类隐私数据pds。

5.如权利要求4所述的方法，其特征在于，对ci1进一步定义为：<ci1_name,ci1_expression>；其中，ci1_name为PDS行业定制约束条件名称，ci1_expression为PDS行业定制约束条件逻辑表达式；对ci2进一步定义为：<ci2_name,ci2_expression>；其中，ci2_name为pds行业定制约束条件名称，ci2_expression为pds行业定制约束条件逻辑表达式。

6.如权利要求3所述的方法，其特征在于，步骤3)中，在企业定制约束下对PDS中的共享项E进行企业定制为：<C_E,I_E,C_Eˊ,cc>；其中，I_E表示行业模板中的共享项E，C_Eˊ表示针对企业需求对I_E中的元素进行补充的元素所构成的集合，cc表示E企业定制约束条件，C_E表示基于I_E和C_Eˊ在约束条件cc的作用下进行定制操作生成的企业模板中的共享项E。

7.如权利要求6所述的方法，其特征在于，对cc进一步定义为：<cc_name,cc_expression>；其中，cc_name为企业定制约束条件名称，cc_expression为企业定制约束条件逻辑表达式。

8.如权利要求3所述的方法，其特征在于，步骤4)中，对共享项E定义用户选择约束：<U_E,C_E,cu1>；其中，C_E表示企业模板中的E，cu1表示E用户选择约束条件，U_E表示C_E在约束条件CU的作用下进行选择操作生成的用户协议中的E。

9.如权利要求3所述的方法，其特征在于，步骤4)中，对Valid_Time定义用户选择约束：<U_V,C_V,cu2>；其中，C_V表示企业模板中的Valid_Time，cu2表示Valid_Time用户选择约束条件，U_V表示C_V在约束条件cu2的作用下进行定制操作生成的用户协议中的Valid_Time。

10.如权利要求1所述的方法，其特征在于，对用户协议进行签名的方法为：

11)用户生成第一部分私钥SK1、第二部分私钥SK2以及SK1对应的公钥PK1、SK2对应的公钥PK2，将SK2、PK1发送至TTP，将用户协议M发送至移动应用平台和TTP；

12)TTP接收到M、SK2、PK1后，验证其合法性；验证通过后对PK1进行认证签名，记为Vc，并将Vc发送至移动应用平台；

13)移动应用平台验证Vc有效后，从Vc中取出PK1；

14)用户利用SK1对M签名，记为A1，并将A1发送至移动应用平台；

15)移动应用平台利用PK1验证A1的有效性，如果有效则生成移动应用平台私钥SKB和SKB对应的公钥PKB，并利用SKB对M签名，记为B，将PKB、B返回给用户；

16)用户利用PKB验证B的有效性，如果有效则生成用户私钥SKA及对应公钥PKA；然后利用SKA对M签名，记为A，并将PKA、A发送至移动应用平台；

17)移动应用平台利用PKA验证A的有效性，如果有效则告知用户协议完成；如果无效则移动应用平台将A1、B发送至TTP，TTP验证其有效性，如果有效则TTP利用SK2对M签名，记为A2，然后通过A1，A2计算出A，TTP将A发送至移动应用平台、将B发送给用户。

Images