罗玙榕,曹进,李晖,赵兴文,尚超
(西安电子科技大学网络与信息安全学院,陕西 西安 710071)
随着移动互联网及电子商务的迅速发展,我国网络/移动支付逐渐普及,目前已有7.68亿网络支付用户,占网络用户的85%[1]。发票是支付消费的凭证文件,而在网络支付盛行环境中,基于环保与便利的需求,传统纸质发票逐步实现电子化,网络支付与电子发票技术体系融合程度逐步加深,能够推动行业效能及发展的大幅提升。电子发票具有无纸化、易存储、便于传递与交付、低消耗等优势,但电子发票文件因失去物理防伪特征,给发票防伪及其查验操作带来许多安全挑战[2]。
纸质发票可通过特殊的制造工艺进行防伪,并同时保证发票的唯一性,防止重复报销。由于电子发票数据易于复制且流转频繁,收票方难以保证所持有的电子发票的完整性、有效性及合法性[3]。电子发票防伪数据简单、开票核验方单一等,导致伪造成本低,易重复报销。电子发票因缺乏相关安全标准,从2013年京东集团发布中国网络支付首张电子发票至今,我国尚未形成完备的电子发票防伪体系,也为电子发票的推行带来阻碍。因此,电子发票的防伪码生成及公开查验成为电子发票技术应用推广的核心问题之一。此外,目前电子发票查验模式为四要素对比查验,且开具、交付与流转方式未进行安全管控,电子发票文件中交易信息以明文形式存储,导致销售方商业数据外流,同时引发购买方隐私数据泄露等严重的数据安全问题,在公开查验的同时保护交易双方隐私数据成为未来电子发票查验技术发展的必然趋势。为实现发票的全面安全无纸化,建立统一普适的电子发票公开查验架构具有非常重要的理论意义和应用前景。
电子发票防伪技术主要分为三类:①税控码防伪;②电子签章或电子签名防伪;③二维条码防伪。税控码防伪方案与纸质发票统一,采用在线开具系统,由税务机关生成与交易信息一致的税控防伪码,发票内容与电子发票图形文件保存完全一致从而进行对比查验。文献[4]实现了税控码防伪查验系统,是目前税务机关官方采用的查验方案。持票人登录国家税务总局全增值税发票查验平台进行复杂的查验操作,需要手动输入发票号码及税控信息,因为系统并发服务资源控制了用户每日查验次数,导致用户无法根据自身需求随时随地进行便捷的真伪查验。电子签章或电子签名可以实现与纸质发票税务机关盖章相同的效果,并可通过对发票数据签名保障发票信息的完整性及不可否认性。文献[5]设计了一种适应差异化用户的电子发票生成及查验系统,其方案采用数字签名对发票信息进行传递完整性保护,但系统仍采用数据库要素对比的方式进行真伪查验,查验的便捷性和效率仍未提升。文献[6]提出了一种基于SM2数字签名的发票真伪查验方案,融合了税务机关及开票方的双重签名,查验者可通过验证签名从而进行公开查验。但该方案中,税务机关仅对发票模板进行签名,未对发票交易信息进行核验,可能引发发票数据造假等问题。此外,该方案未对发票交易信息进行传输安全性保护,导致交易双方隐私泄露。文献[7]为巴西官方电子发票设计管理系统,采用公钥体制对电子发票数据进行签名,但其中仅包括税务机关的核验及签名,发票交易信息的正确性无法得到保障。文献[8]提出一种通用的基于数字签名的发票真伪查验方案,但其需要多重验证,导致计算开销过大。二维条码防伪方式基于我国自主知识产权的二维码技术[9-10],可将发票要素信息加密编码,具有存储量大及防伪效率高等优势,文献[11]详细说明了我国基于二维码的电子发票防伪查验方案,但二维码查验方式对硬件需求高,需要手机摄像头或专用查验机器扫描后与税务系统数据库进行发票对比查验,查验流程复杂且难实现全票面信息防伪查验。此外,有一些基于新技术的电子发票查验方案,文献[12-13]提出基于区块链的电子发票查验及异常追溯方案,其本质是传统发票要素对比方案,并且造成大量存储冗余,不适用于当前的电子商务环境。以上方案均需在客户端在线请求税务系统数据库信息对比税控信息,从而实现发票真伪验证,实时性和便捷性较低。我国税务信息化从“纸质控税”发展至“互联网+电子票据融合”,急需一种电子发票查验方案实现发票数据真伪性、完整性、有效性等全方位的验证,为收票方、报销单位等各种角色提供公开、隐私保护控制、便捷高效的查验方案,支撑电子发票服务的全面落地与实施。
本文主要的研究工作如下。
1) 建立基于电子签名的电子发票公开查验架构。针对开票、流转、查验等三大流程,综合考虑电子发票信息的多方来源,设计融合了开票方及税务主管部门核验的电子发票通用防伪码生成机制。
2) 基于SM2签名算法设计了适用于电子发票系统的联合无证书签名方案,实现电子发票信息与交易信息的双重完整性、真伪性、有效性保护,对发票交易信息进行加密保护,控制用户敏感信息的传播。联合签名有效降低查验者的验签次数,提高查验效率及便捷性。
3) 仿真结果及安全分析表明,本文方案具有很高的计算效率及简洁的发票存储结构,能实现具有隐私保护的电子发票公开多维信息查验并能抵抗各类协议攻击。与传统基于数字签名的发票查验方案进行性能对比,验证了本文方案的高效性及安全功能的多样性。
文献[14]的电子发票服务架构包含电子发票服务系统、收票方、开票方、查验方(如图1所示)。
图1 电子发票服务架构 Figure 1 Electronic invoice service structure
1) 电子发票服务系统。电子发票服务系统由国家税务机关进行管理及运营,为包括商家和消费者在内的实体用户提供开票、查验及安全监管服务,在本文的查验架构中,电子发票服务系统中应包含密钥生成中心(KGC, key generation center)及开票子服务系统。
2) 开票方。开票方一般为商品销售方,为购买者提供电子发票。
3) 收票方。收票方一般为商品消费者,需要获得发票进行报销等活动。
4) 查验方。查验方即查验者,本文方案中任何获得电子发票文件的实体均可进行发票真伪查验。
本文方案中攻击者可监听、截获或篡改公开信道传输的消息,本文电子发票查验方案应满足以下安全需求。
1) 电子发票真伪公开可验证性:获得电子发票文件的任意实体可验证电子发票真伪,即可准确判断该电子发票为攻击者伪造/篡改的假票或为税务机关及开票方均认可的真票。发票真伪性包括电子发票数据的准确性、完整性及有效性。
2) 电子发票防伪造性:攻击者无法根据公开信道所截获的信息伪造出能通过真伪性验证的发票数据。攻击者可能是服务架构中任何一方,也可能是电子发票服务系统中无身份的攻击者。
3) 发票隐私信息保护性:电子发票包含商品购买者的隐私信息(如购买的具体商品及数量信息),本文方案应保障除报销等用途外的查验者可获得发票具体信息,其他查验者仅能查验其真伪而无法获取购买者的隐私信息。
电子发票元数据由发票唯一标识、交易数据及税控信息等部分组成,其中税控信息为税务部门生成的发票信息安全保障数据,如防伪码、真伪验证码等。交易信息主要为两部分:①由收票方提供包括购买方名称、纳税人识别号、开户银行等信息在内的发票抬头;②由开票方提交包括购买商品详情/价格/数量、销售方信息、交易时间等在内的交易明细。
为保障电子发票的可验证性,电子发票应由税务主管部门及开票方共同签名,保证交易信息的正确性及发票的有效性。文献[6]提出一种可验证的税务主管部门/开票方双签名方案,但该方案中由主管部门对模板签名后直接交予开票方,无法由主管部门确认及记录交易信息,不利于发票的追溯与稽查,该方案需要两次签名验证,造成极大的计算消耗。因此,本文引入一种基于SM2算法的联合无证书签名方案,设计了一种电子发票公开查验架构(如图2所示),具体过程如下。
图2 电子发票公开查验架构 Figure 2 electronic credentials public verification architecture
1) 收票方发起开票请求,向开票方提供发票抬头信息。
2) 开票方向电子发票服务系统提出开票申请,开票子系统反馈发票唯一标识及发票抬头单位或个人公钥至开票方。
3) 开票方生成开票信息(含交易明细、发票抬头等信息),通过其交易安全信道发送至收票方,如购物平台客户端发送至消费者。
4) 收票方确认交易信息等开票信息无误后,开票方将交易信息与发票唯一标识签名后发送至开票子系统。
5) 税务主管部门验证签名及交易信息合规后,对发票内容进行签名,并根据标准电子发票模板生成电子发票数据发送至收票方。
6) 收票方可直接通过签名内容验证发票内容的有效性,或提交至报销单位由报销单位查验。其他获得电子发票数据的实体也可直接验证签名有效性进行真伪性查验。
基于SM2[15]无证书签名方案可生成电子发票税控信息,实现电子发票真伪公开查验。为适用于电子发票服务架构,基于文献[16]中的无证书SM2加密方案设计无证书联合签名方案生成电子发票查验码,形成具有隐私保护的电子凭据查验架构,防止发票信息泄露、篡改、造假等,保障电子发票数据的准确性、完整性、有效性。表1为系统参数符号对照。
表1 系统参数符号对照Table 1 System parameter symbol cross-reference
电子发票服务系统遵循国家标准[17]生成椭圆曲线参数,其中G为椭圆曲线的基点,G的阶为素数n,KGC生成系统公私钥对( PKS,SKS)。
对任意用户(包括开票方商户、收票方及查验方)i在电子发票服务系统注册,将生成一对用户公私钥,并与税务主管Qi= (di)−1QED+kiG部门生成一对联合公私钥。注册步骤如下。
1) 税务主管部门选取随机数kED∈ [1 ,n− 1],计算QED=kEDG并通过公开信道发送至用户i。
2) 用户i选取随机数ki∈ [1 ,n−1]及di∈ [1 ,n− 2],计算Qi= (di)−1QED+kiG并通过公开信道发送至KGC。
3) KGC选取随机数k0∈ [1 ,n− 1],计算Q=Qi+k0G、t0=k0+H(i‖Q)SKs( modn),其中,Q作为用户i的部分公钥发布,t0发送至i。
4) 用户i计算ti=di(ki+t0+ 1) ( modn)及公钥Pi= (di)−1G作为公钥发布,私钥为di。
5) 税务主管部门计算相关的私钥,用于与用户i联合签名,即dED=(kED+ti)−1(modn)及对应公钥PED= (dED)−1Pi。
6) 用户i与税务主管部门的联合公钥为P=Q+H(i‖Q)PKS。
电子发票信息由税务主管部门、开票方、收票方三方数据共同生成,并由税务主管部门和开票方核验交易信息后联合签名形成电子发票防伪码。发票防伪码生成步骤如下。
步骤1接收开票请求后,税务主管部门创建一份新的电子发票。
1) 生成发票唯一标识码I。
2) 再次选取随机数kED∈ [1,n− 1],并计算RED=kEDPED。
3) 发送 (I,RED)至开票方IE。
步骤2开票方IE与收票方IR通过线下或线上安全交易平台确认开票交易信息M及收票方自选随机数N,其中收票方IR提供的发票抬头单位或个人为V。
步骤3开票方对发票信息进行SM2签名算法中的标准预处理[16]生成算法参数,并对交易信息签名,具体如下。
1) 预处理1输出字符串用于预处理2:Z=H(ENTL‖ IE ‖a‖b‖xG‖yG‖xp‖yp);其中,ENTL为实体标识符IE的比特长度,a、b为系统椭圆曲线参数。
步骤4 开票方签名。
1) 开票方选取随机数kIE∈ [1 ,n− 1],计算
开票方生成的部分签名 (r,sIE)和交易数据均通过电子凭据系统安全信道传输至税务主管部门。
步骤5税务主管部门对开票方签名、开票信息进行核查。
1) 计算RED+sIEPIE−rG= (x1',y1')。
2) 验证r=是否成立,验证开票信息(T,M)是否异常。
3) 若等式成立,未出现异常,则税务主管部门正常签名生成电子发票。
最终防伪码签名为(r,s)。发票数据为
目前,发票使用规定中表明在发生销货退回、开票有误等情形,或开具时发现有误的,可作废处理。作废发票需在防伪税控系统中将相应的数据或文件标记“作废”处理。本文方案中,需由开票方提出申请并签名后,由税务部门审核并签名生成“作废发票”发送至发票抬头所指定的个人或单位,防止作废发票的使用,发票冲销或作废步骤如下。
开票方收到退货或发票开具错误提醒时,生成作废发票信息(I⊕N, invalid,C),其中C为开票方选取的随机数,称为冲销编号。
1) 预处理2生成作废发票签名信息MV。
2) 开票方将消息MV及 (I⊕N, invali d,C)发送至税务主管部门申请发票冲销,主管部门批准后选取随机数kE′D∈ [ 1,n− 1]并计算RE′D=kEDPED发送至开票方。
3) 开票方采取发票防伪码生成步骤4中方式对MV进行签名,并将部分签名 (r′,sI′E)发送至税务主管部门。
4) 税务主管部门采取发票防伪码生成步骤5中方式生成签名(r′,s′),冲销(作废)发票数据为
5) 税务主管部门将冲销(作废)发票MIV存储记录,并发送至开票方IE及发票抬头中的单位或个人V,防止作废发票的使用。
对于任意获得发票数据的验证者,均可通过验证发票中的联合签名有效性判断发票真伪。查验方公开查验步骤如下。
1) 查询开票方部分公钥后,计算开票方IE的联合公钥P=Q+H(IE ‖Q)PKS。
2) 与发票防伪码生成中步骤3一致,完成预处理计算获得M。
3) 提取发票信息计算u=r+s(modn),sG+uP= (x2,y2)。
4) 验证r=是否成立,若等式成立,则判断为有效真发票,若等式不成立,则判断发票无效。
5) 对发票抬头中指定的单位或个人V应首先检查发票编号是否在冲销发票数据库中或已报销,若为有效发票编号则按照步骤1)~步骤3)进行验证,并使用私钥计算Decdv(EncPV(M⊕T))⊕T获得发票具体交易信息,进行报销等操作。
3.1.1 签名有效性
由式(2)及PIE= (dIE)−1G可推得税务机关验证部分签名有
从上式可得x1=x1',继而可推得r=+x1) (modn) =(M+x1′) ( modn)成立,部分签名验证有效。
对标准SM 2签名算法,仅需验证等式sG+uP=RIE= (x1,y1)成立。
由式(6)及等式u=r+s( modn)可推得
可证本文方案中所采用的联合签名有效性与标准SM2签名一致。
3.1.2 公开可验证性
任何获得发票数据MI可通过提取签名及查询开票方公钥计算签名联合公钥,对发票真伪进行验证,仅需一次验签即可验证税务主管部门及开票方双方签名的发票数据。税务主管部门的有效签名代表该发票符合国家税务相关法规,即发票合法性。开具方有效签名代表发票交易信息经开具方及消费方核验认可,即发票的正确性。此外,签名有效可证明发票数据未被篡改,即发票的完整性。综上,发票数据所有者可便捷地实现电子发票真伪的公开验证。
3.1.3 防伪造性
由签名不可伪造性可知,仅由税务主管部门及开票方双方核验签名后才可生成有效签名,攻击者需要同时持有税务主管部门私钥dED及开票方私钥dIE或仅持有联合私钥d=(dEDdIE)−1− 1 (modn)才能生成有效签名,其中任意一方或其他攻击者无法仿冒或伪造签名。本文方案中,发票由税务机关给出的唯一标识码I及收票方选择的发票随机数编码N保持发票唯一性,并添加电子发票开具时间戳T防止重放攻击伪造发票,同时发票报销单位可通过记录已报销/已处理发票的(I,N)防止不合规的重复使用。
3.1.4 隐私保护性
本文方案形成的发票数据中交易信息等用户敏感隐私数据以EncPV(M⊕T)加密形式存储或流转。发票抬头中指向的单位或个人V可使用私钥解密获得具体的发票交易信息,用于报销等后续操作。在本文方案设计中,仅开票方、消费方(申请开票者)、税务主管部门及发票抬头中单位或个人可检查交易信息,在保障发票可追踪、可用性的同时保护了交易双方的隐私信息。
3.1.5 抗协议攻击
本文方案能够抵抗多种协议攻击。首先,税务系统需核验开票方签名有效性后生成最终联合签名,能够抵抗中间人攻击。其次,电子发票标识由税务系统给出的唯一标识及开票方所选定的随机数组成,并在发票数据中加入时间戳后由双方签名,能够保证发票的唯一性防止重放攻击。本文方案还具有抗仿冒攻击能力,即防伪造性。此外,本文采用无证书联合签名方案,有效解决了密钥托管问题,能防止单方面密钥泄露导致的签名仿冒攻击。
本文使用协议安全仿真软件Scyther[18]进行协议总体安全仿真验证,基于模型改进算法,Scyther可用于协议攻击搜索、协议角色执行模拟和安全验证。Scyther是一种在完全密码假设下对安全协议进行形式化分析的工具,可用于发现由协议构建方式引发的问题,该工具下设立了一系列的声明包括保密性及可信认证,如保密性secrecy、有效性aliveness、抗重放攻击 Niagree及仿冒与中间人攻击Weakagree等[19]。
本次仿真采用了Dolev-Yao[20]攻击模型,和1.1节中设定的安全模型一致,攻击者可以控制公开信道并在应用场景中实施一系列攻击,模型中需要验证可信性的角色为发票票面信息MS及发票唯一标识符I,以及验证发票交易信息M的公开信道保密性。使用安全协议描述语言(SPDL, security protocol description language)在Scyther中构建第2节中描述协议,仿真结果如图3所示,发票票面信息MS及唯一标识符I可以成功抵抗各类攻击下验证消息的有效性,并保障交易信息M的保密性,本文方案在Scyther工具仿真下未发现有效攻击。
图3 查验协议在Scyther工具下的安全仿真结果 Figure 3 Formal verification results of Scyther
表2列举了本文方案与文献[8]中电子发票典型验证方案、文献[12]中基于数字签名的查验方案在安全功能上的对比。通过以上分析可知,本文方案在实现电子发票公开真伪性查验的基础上,同时实现交易双方隐私信息的保护,并能抵抗多种类型的协议攻击。
表2 本文方案与同类方案安全功能对比Table 2 Comparison of security features between the proposed scheme and other schemes
本节主要分析本文所提电子发票公开查验架构的计算开销。在本文方案、文献[8]中电子发票典型验证方案与文献[12]中基于数字签名的查验方案中统一使用SM2数字签名/加解密算法及SM3杂凑函数,可对比协议整体流程计算开销。因实际电子发票场景中,服务各方所依托的设备算力具有差异,分别在3个计算能力不同的设备上实施C语言封装的SM2及SM3算法统计所消耗的时间以接近现实应用场景。设备1模拟税务机关电子发票服务系统ED,CPU参数为Intel Xeon Gold 6240 2.60 GHz 72核。设备2模拟开票方客户端IE,CPU参数为Intel Xeon E5-2682 v4 2.50 GHz 2核。设备3模拟查验方客户端IR,CPU参数为Intel Core 2 2.40 GHz 2核。SM2-256及SM3算法计算消耗时间如表3所示,其中,SM2签名及验签消耗中不包括两项SM3预处理时间。
表3 各算法计算消耗时间Table 3 Time consumption of each algorithm
各方案计算消耗时间对比如表4所示,计算消耗对比如图4所示,通过引入基于SM2的联合签名在保障多方核验的情况下有效减少了查验方的计算消耗,考虑到查验方一般使用移动终端且查验是较为频繁的操作,本文方案能大幅提高查验服务效率,此外,在税务机关、开票方计算效率方面具有一定优势。由于各方案签名方不同,签名方计算消耗有所差异,本文方案计算消耗主要集中在计算能力较强的电子发票服务系统中,且本文方案中税务机关及开票方计算总体消耗较其他方案低。此外,本方文案使用联合签名,对同一开票方具有相同公钥签名的特征,在处理来自同一开票方(如京东等大型电商企业)的发票时可共享公共参数,有效降低计算开销,大批量同一开票方发票查验计算消耗对比如图5所示。综上,本文方案在提高查验效率的同时对交易双方的敏感隐私数据进行了保护和传播控制。
表4 各方案计算消耗时间对比Table 4 Computation time comparison of each scheme
图4 各方案计算消耗对比 Figure 4 Verification calculated consumption comparison of each scheme
图5 大批量同一开票方发票查验计算消耗对比 Figure 5 Comparison of the consumption of large quantities of the same invoicing party invoice verification calculation
电子发票文件需要便于存储与传输,因此电子发票的数据量大小是其重要参数。本节主要分析发票文件大小,即各方案生成的每张可查验发票所占存储数量的对比。基于本文中使用的SM2-256及SM3算法,对电子发票方案中的各参数做出以下长度定义。① SM2签名长度32 byte。② SM2加密长度与明文一致(不含校验码)。③ SM3哈希长度32 byte。④ 身份标识、发票标识、时间戳均为4 bytes;⑤ 发票交易信息为64 byte。同类型方案发票数据量对比如表5所示,相比其他方案,本文方案因使用联合签名精简了发票存储内容,有效降低了多方核验签名的数据量,有利于生成简洁的电子发票文件,适用于大规模电子商务交易场景。
表5 同类型方案发票数据量对比Table 5 Comparison of data bytes of related solutions
本文针对电子发票查验问题,结合SM2数字签名算法,设计了基于无证书联合签名的电子发票真伪公开验证方案。本文方案充分考虑了电子发票流转频繁、交易信息敏感、易复制伪造等特点,设计了多方核验签名的电子发票查验架构,在保障公开高效查验的前提下,对发票交易信息进行传输保护,防止交易双方隐私泄露。理论及仿真分析表明,本文方案不仅保障了电子发票的多方核验生成、即时公开真伪查验、抵抗协议攻击等安全需求,还能实现用户隐私信息保护。与同类型方案相比,本文方案在提供更多安全功能及更强安全性的基础上,有效提高查验效率且具有更精简的发票结构,利于电子发票存储及传输,更适用于海量电子商务交易下的电子发票应用场景,支撑电子发票服务的推广与应用。