自新冠病毒（COVID-19）在全球大规模爆发以来,各个国家的社会,经济和公民健康都面临巨大挑战。正如联合国秘书长安东尼奥·古特雷斯所指出,COVID-19的危害性超过了二战以来的任何危机。到目前为止,全球感染人数仍在持续上升。这种情况出现的主要原因是COVID-19病毒具备较高的传染性,且病毒感染者在潜伏期就具有传染性。因此,应对COVID-19的传播关键是要尽快识别出和确诊患者接触过的密切接触者,采取相应措施对相关密切接触者进行社交隔离,阻断COVID-19的传播路径,将危害降至最低。在对密切接触者追踪方面,由于病毒的RO系数较高,早期依靠人力来进行排查追踪的模式难以满足对所有密切接触者进行追踪的需求。与此同时,使用配备蓝牙的电子设备（如,智能手机,电子手环）对密切接触者进行追踪已被证明是阻断COVID-19传播的一种可行方式。通过使用短距离无线通信蓝牙技术,每个人都可以使用他/她的蓝牙设备收集和记录与他/她接触过的用户信息。在用户通过系统自查确定自己为密切接触者时,可以自己主动向有关部门申报进行社交隔离。当地卫生部门也可以在确诊患者的配合下通过这些信息识别密切接触者,采取相应的行动,通知密切接触者潜在风险。由于这种方法需要收集用户个人的隐私信息,如身份隐私、相遇信息隐私或联系人名单。因此应采取谨慎的策略,防范个人隐私的泄露。相关工作进展:自COVID-19爆发以来,学术界和工业界提出了多种基于蓝牙追踪接触者的方案（Contact Tracing）。设计这种方案的一个关键挑战是如何同时实现强隐私性和高效的的密切接触者人追踪。为此目的,研究人员根据不同的追踪需求提出了不同的设计。方案设计中的难点是对隐私保护和追踪效率的平衡,目前“Contact Tracing”方案主要有两大类“集中式”与“分布式”。采用集中式设计的“Contact Tracing”方案如新加坡政府于2020年3月推出的基于BlueTrace协议的TraceTogether,澳大利亚政府于2020年4月26日发布的同样基于BlueTrace协议的CovidSafe应用,法国政府于2020年6月推出基于ROBERT协议的StopCovid应用程序,此外还有印度政府于2020年5月发布Aarogya Setu,该应用除了收集用户的接触信息外,还可以通过GPS收集位置信息。ContactChaser提出了一个简单的基于群签名的方案,该设计同样考虑了利用GPS对用户的位置信息进行收集。一般来说,在集中式设计中通常需要一个可信中心负责生成用户假名,进行密切接触者的追踪。这种设计的优势在于追踪效率高,但对用户的隐私保护则较弱。采用分布式设计的“Contact Tracing”应用如苹果谷歌公司联手开发的Apple-Google。由MIT领导研发的PACT-East,该应用允许用户有选择的在其本地存储额外的信息,例如位置信息。通过存储可选的额外信息将帮助系统提高准确性,减少误报。PACT-West与PACT-East核心功能相似,采用钥匙链的设计来生成用于广播的伪随机ID,可以节省用户的存储空间。Monast提出了基于零知识证明的设计方案,该方案会使用户在相遇时会根据接收到的广播信息,生成对应的凭证。在分布式设计中,系统无可信中心,用户设备自己生成假名,自觉进行密切接触者的追踪。分布式设计的优势在于隐私性较好,但对密切接触者的追踪上过于依赖于用户的自觉性,效率不高,一旦作为密切接触者的用户不主动上报,则系统也无法识别相关的密切接触者从而导致追踪失败。此外,分布式设计将联系人列表存储在每个用户的智能手机上,而不会向任何中央机构披露这些信息。虽然这种方式可以更好地保护用户隐私不受服务器的侵犯,但正如Vaudenay其研究中指出,由于在追踪阶段,需要上传确诊患者的标识符信息到公告栏上。这增加了确诊患者隐私暴露的风险,使得确诊患者用户更容易受到链接攻击。此外Kuhn团队首次提出“Contact Tracing”应用设计的正式概念。Ahmed团队Kuhn团队中基于的研究成果上,增加了对混合式方案的讨论,不仅研究了“Contact tracing”方案中的隐私和漏洞,而且分析了设计方案实现和可用性问题。混合式设计如Castelluccia等人提出的Desire方案,在用户相遇时通过广播交换数据,并根据用户双方的广播数据生成标识,分别加密保存在服务器。在追踪阶段,由服务器来进行风险通告,这降低了分布式设计中常见的链接攻击的可能性。由Jhanwar等人提出的PHyCT方案,在设计中采用了秘密共享技术,这种技术要求在追踪阶段需要用户和隐私保护服务器的共同配合。Beskorovajnov等人提出的ConTra Corona方案也采用了秘密共享技术,用户只有在相遇时间足够长,收集到足够多的秘密分片后,才会被认定为密切接触者。方案中需要引入了三个服务器。作为隐私安全的前提,方案假设这些服务器不可串通且信息的传输是在安全信道中进行的。Trieu等人提出的EpiOne方案采用私有集交叉点（PSI）加密技术。Duong等人提出的Catalic方案在EpiOne的基础上提出了在云计算模型下,使用代理计算的方案,这提高方案实用性,并降低用户本地计算和通信开销。Vaudenay在对集中式和分布式的研究中指出理想的“Contact Tracing”解决方案应该是混合式的,在现实世界中的由于用户对密切接触者追踪的持有不同态度,“Con-tact Tracing”方案设计应该为用户提供更多的隐私选择,此外Chan和Najam也进一步指出,在疫情发展的不同阶段,用户对于隐私的需求是变化的。针对于此本文提出MLCT（Multiple Level Contact Tracing）一种新的具备多层级隐私披露的混合式“Contact Tracing”方案,方案将用户广播信息分为两部分,分别是身份信息和相遇信息,并根据信息的披露程度,分为四个隐私级别。此外,MLCT方案考虑现有方案并为涉及到的密切接触者的隐私保护,并提出密切接触者的预授权机制。论文详细阐述方案的构造并提供相应的性能分析和安全性证明。在方案的设计上,MLCT采用Camenisch提出的匿名凭证技术,利用证书机构[CA],完成对用户身份的托管,利用政府机构[GV],完成对密钥的生成和分发。相比于同样采用群签名技术的ContactChaser方案,MLCT利用匿名凭证技术将身份托管在[CA]上,加强了对用户身份隐私的保护。同时借鉴PHyCT中秘密共享技术的应用设计了针对密切接触者隐私保护的预授权机制,在保证信息收集的同时,增强MLCT系统中用户身份隐私的保护。MLCT的优势在于为用户提供身份隐私保护的同时,充分考虑政府,确诊患者,密切接触者对于接触追踪不同的隐私需求,提高追踪效率。在现实世界中,政府机构为更有效的控制疫情需要收集确诊患者的接触信息。而用户对于配合政府收集接触信息的行为持有不同的态度。积极用户愿意配合政府机构,提供包括时间,地点人员的信息。隐私敏感的用户在意自身的隐私是否安全。如何收集积极用户提供的有效信息,同时保护隐私敏感用户的隐私信息是一个难点。针对这一点MLCT提出四个层级的隐私信息披露选择,在保护用户隐私的前提下,通过提供更多的隐私披露选择,鼓励用户主动配合以提高追踪效率。从而避免分布式设计中由于用户不配合导致的追踪失败的问题,以及集中式设计中可信中心权力过大的问题。相比于之前研究中的混合式方案,MLCT提供了更多的隐私选择的同时提出针对保护密切接触者身份的预授权机制。追踪密切接触者的过程不在仅仅由政府和确诊患者参与,还需要经过密切接触者的预授权。MLCT提出只有在密切接触者完成预授权之后,在追踪阶段赋予政府和确诊患者才具备去匿名化能力。从MLCT-level1到MLCT-level4,四种隐私保护层次,可适应不同的实际需求。其设计思路主要是（1）使用[CA]完成对用户身份的注册,这样设计的目的是为了将用户身份进行托管。以达到MLCT-level3的设计目的即在不暴露用户身份隐私的情况下完成对相遇信息的收集,帮助疫情防控部门根据疫情信息制定更为有效的疫情防控政策。（2）利用秘密共享方案,建立预授权机制保护密切接触者的隐私。密切接触者上传基于用户私钥生成的假名的秘密分片到隐私服务器[PS],作为一种预授权的机制。在追踪阶段,对密切接触者身份的解密,需要得到[PS]的授权,若用户没有进行预授权操作,则无需向[PS]上传秘密分片,在追踪阶段不会被解密身份。（3）本地存储用户相遇信息和用户假名的广播秘密分片。本地存储的两部分信息由用户控制,可根据确诊用户的意愿,分别上传以达到MLCT-level3,MLCT-leve12级别或者全部上传以达到MLCT-level4的追踪级别。系统模型的各个实体如下,布告栏机构[BB]主要负责公布确诊患者用户的广播标识符（用户假名的广播秘密分片）的Hash值,以供用户自查,通过[BB]机构,能够使安全方案达到MLCT-level1追踪级别。隐私服务器[PS]主要负责用户的预授权操作,包括记录,存储用户假名的秘密分片的Hash值。在追踪阶段检查上传解密请求中的医生签名对符合要求的预授权用户的身份解密请求授权。[GV]检索数据库找出对应的私钥以及匿名凭证,签名后发送给[CA],[CA]在核实签名,和解密身份后,才会响应[GV]的身份解密请求。此时,安全方案达到MLCT-level2追踪级别。[GV]机构除了参与MLCT-level2的检索确诊用户的群私钥之外,更重要的是在MLCT-level3中,[GV]机构对确诊患者用户上传的相遇信息进行审核,以达到对疫情信息收集的目的,此时[CA]机构并未接收来自[PS]的对该确诊患者用户的授权签名,所以系统不会解密密切接触者的身份信息。安全模型,考虑在真实的场景中,服务器通常具备较高的安全性,能抵御强大的攻击,而用户设备的安全性较差,难以抵御强大的攻击。因此MLCT方案的威胁模型中,所有服务器都是诚实且好奇的（半可信）,攻击者可以控制一组妥协的用户设备。而设备和机构服务器之间的数据传输是在可信信道中进行的,不考虑侧信道攻击。在此假设下,MLCT可以保证方案的正确性,追踪的有效性,抵御两种假阳性攻击,确诊患者用户身份隐私攻击,密切接触者的身份隐私攻击。多层级追踪具体流程如下,当医生诊断出确诊患者后,会对患者在过去14天使用的广播标识符（用户假名的广播分片）的Hash值生成附有时间戳的签名。并将其发布在布告栏中供其他用户下载自查,确诊患者在确诊后可以选择上传相遇信息协助疫情防控部门。在MLCT-level2中,确诊患者可自愿向[PS]部门提供本地数据库收集的广播标识符。[PS]机构的服务器根据广播标识符的Hash值,进行检索。在恢复出假名后,系统解密后得到密切接触者群私钥的Hash值,附上带有时间戳签名提交给[GV],[GV]在根据密切接触者群私钥的Hash值,检索出密切接触者群私钥和对应的身份证书,生成附有时间戳的签名后提交给[CA]机构进行身份的识别。在MLCT-level3追踪级别中,确诊患者用户可自愿向[GV]部门提供本地数据库收集到的,包括相遇信息、广播标识符、签名在内的完整数据。在[GV]部门通过对签名的验证后,[GV]机构可以获得疫情防控的重要信息,如热点地区等。若确诊患者用户同时启用MLCT-level2和MLCT-level3则达到MLCT-level4追踪级别,即确诊患者用户向[PS]提交本地的广播标识符,同时向[GV]提供完整的信息元组,则可以完成对确诊患者用户的身份和相遇信息的解密,达到最强的追踪级别。MLCT框架所使用的密码学工具主要有,2-out-of-2 secret sharing,Hash函数,具备安全性,完全追踪性和完全匿名性的群签名方案以及相应的匿名凭证,语义安全的对称加密算法,安全的具备强不可伪造性的数字签名算法。MLCT方案中,所采用的是Boneh的短群签名方案,此方案的开销较小,且安全性,完全追踪性和完全匿名性。Camenisch提出的匿名凭证方案中的涉及对于短群签名方案的扩展,引入匿名凭证,对用户身份进行托管。此外,通过利用具备强不可伪造性的Schnorr签名方案来作为医生和[PS]机构的签名方案,Schnorr签名方案在应用时可以使用安全的Hash函数确保方案的安全性,此外应用Schnorr方案的批验证技术,可以降低方案的计算开销,提高方案的运行效率。MLCT方案在用户设备的计算开销主要来自群签名的生成和验证过程。签名者的计算代价包括8次幂运算,而验证者的计算代价包括6次幂运算和1次配对,参考Monast方案的实验数据,在配备高通骁龙855（Kryo 485 CPU,1x2.84GHz&3x2.42GHz&4x1.8GHz）的Android手机上,两次配对的计算时间约为100ms。所以群签名的的生成和验证过程也可预估在100ms以内。这个计算开销在实际应用中是可以接受的。通信开销方面,蓝牙5支持255字节的广播信息,而群签名大小是192字节。相遇信息可以拥有63字节的数据空间,其中时间,位置（经度纬度）/蜂窝基站标识符,需要16字节。剩余的57字节数据空间,可以保留用来记录Covid-19应对防疫所需的其他信息,如记录疫苗接种情况。因此方案的通信开销在实际应用中也是可以接受的。未来的工作改进方向,本文所提出的的MLCT方案,适用于Covid-19大流行导致的人员流动受限的情况,方案的追踪效率会随着注册人员的增长而降低,因此可以通过以城市为单位建立群。在社交关系图的保护方面,[PS]向[GV]授权解密确诊患者用户的真实身份时,可以加入一个混合机制。如[PS]可以将来自不同确诊用户的去匿名化请求打乱后一起返回。混合机制的引入可以加强对社交关系图的保护。MLCT方案在实施中,应该配合相关限制政策,尊重确诊患者的选择,动态合理的调整追踪级别,谨慎启用高级别的追踪,防止权力的过度使用。