POS数字签名防切机系统

1.一种POS数字签名防切机系统，其特征在于，所述系统包括：客户端、服务器端和POS机运行系统，所述客户端与所述服务器端通信连接；
所述客户端，负责将程序软件代码和代码可执行文件一起发送到服务器端，服务器端将代码进行备份，将代码可执行文件签名，获得被签名数据后，向POS机运行系统公布程序软件的发版；
所述服务器端，负责对客户端发送的数据签名，并将签名后的数据返还到客户端；
所述POS机运行系统，获得安装的软件有新版发布时，请求下载并安装运行所述新版软件，在下载、安装运行新版软件过程中利用POS机运行系统中存有的公钥进行验签；
所述服务器端对客户端发送的数据签名，具体按照下述步骤实现：
S11，获取需签名原始文件F，确定签名算法，并生成需签名原始文件F签名前的数据格式I，所述数据格式I为164字节，包括算法标识、公钥ID、附加信息和文件信息；
S12，判断需签名原始文件F中是否包括重要数据字段D，如果是，则，先完成对重要数据字段D的签名，进入S13；如果否，随机填写签名后文件中重要字段的哈希值和签名值，且在签名后文件信息中设置重要数据字段处的字节长度为0，然后进入S13；
S13，使用哈希算法计算需签名原始文件F的哈希值，得到Hash(F)，记为H2；
S14，在正在签名的文件信息中填充随机数R2，填充长度为Length(S)-Length(I)-Length(H2)，其中，Length(H2)为需签名原始文件F哈希值的字节单位长度；
S15，使用私钥根据确定的签名算法，对I|H2|R2|0xDC进行签名，得到需签名原始文件F的签名SF，所述0xDC为签名结束的标记；
S16，获取需签名原始文件签名SF的字节长度LSF和/或重要数据字段签名LSD的字节长度，获取附加信息字段的总长度La，获取签名包标志E，所述标志E为字符串
SIGNED.VERSION01；
S17，形成完成的签名后的文件，其格式为：F|La|SD|SF|I|LSF|LSD|E；其中，符号|表示内容按字节流连接；
所述重要数据字段D的签名，具体为：
A1，计算重要数据字段D的哈希值，即为H1；
A2，在正在签名的文件信息中填充随机数R1，随机数R1的长度为Length(S)-Length(I)-Length(H1)，其中，Length(S)为签名密钥的字节单位长度，Length(I)为需签名原始文件F签名前的数据格式I的字节单位长度，Length(H1)为重要数据字段D哈希值的字节单位长度；
A3，使用预先定制的私钥根据确定的签名算法，对I|H1|R1|0xDC进行签名，得到重要数据字段的签名SD，所述0xDC为签名结束的标记。
2.根据权利要求1所述POS数字签名防切机系统，其特征在于，所述POS机运行系统在下载、安装运行新版软件过程中利用POS机运行系统中存有的公钥进行验签，具体按照下述步骤实现：
S21，查看正处于下载或安装运行新版软件的数据文件信息中是否包括签名包标识E，如果是，则正处于下载或安装运行新版软件为签名后的文件，进入S22判断签名文件是否有效；如果否，则下载或安装运行新版软件不是签名后的文件，提示下载不成功或安装运行失败的提示；
S22，假定需验证的签名文件格式为F’|La’|SD’|SF’|I’|LSF’|LSD’|E；
F’表示需验证签名文件对应的原始文件，La’表示需验证签名文件中附加信息的总长度，SD’表示需验证签名文件中重要字段的签名，SF’表示需验证签名文件对应的原始文件的签名，I’表示F’的数据格式，LSF’表示SF’的字节长度，LSD’表示SD’的字节长度，S23，查看I’中的签名算法、哈希算法标志是否均为0x00，如果是，则需验证的签名文件无效；如果否，则进入S24；
S24，根据I’中的原始文件长度和重要数据长度，分别提取原始文件f和重要数据d；然后根据I’中的算法标志，分别计算原始文件f和重要数据d的hash值，得到Hf和Hd；
S25，根据LSF’、LSD’分别提取SD’、SF’，在SD’、SF’的基础上，使用公钥解密需验证签名文件的签名数据得到签名前的数据格式I、签名前原始文件的哈希值H2、签名前原始文件重要数据字段的哈希值H1；
S26，判断解密得到的I和需验证的签名文件中明文存在的I’、解密得到的H2和Hf、解密得到的H1和Hd是否均一致，如果是，需验证签名文件的签名验证通过；如果否，则需验证签名文件的签名验证失败。
3.根据权利要求2所述POS数字签名防切机系统，其特征在于，步骤S21之后还包括：验证需验证签名文件中附加信息的总长度La’与利用公钥解密得到的原始文件F签名后得到的签名文件中的附加信息的总长度La是否一致。
4.根据权利要求1所述POS数字签名防切机系统，其特征在于，所述服务器端对客户端发送的数据签名使用的算法种类及对应的密钥长度为：
算法DES，对应的密钥长度为168bits；
算法RSA，对应的密钥长度为2048bits、3072bits、4096bits；
算法ECC，对应的密钥长度为224bits、256bits、384bits、512bits；
算法AES，对应的密钥长度为2048bits、3072bits；
算法SM2，对应的密钥长度为256bits。
5.根据权利要求1所述POS数字签名防切机系统，其特征在于，所述公钥ID用16字节的十六进制数表示。
6.根据权利要求1所述POS数字签名防切机系统，其特征在于，所述附加信息包括签名公司信息数据、签名者姓名数据、签名时间；所述签名时间为固定的8字节BCD码，精确到秒，其中最后一个字节表示星期。
7.根据权利要求1所述POS数字签名防切机系统，其特征在于，所述算法标识的表示形式如下：
算法标识0x0000时，其后续域，除了签名包标识域以外的域为无效数据；
算法标识0x00表示不签名，算法标识0x0N表示不同密钥长度同一算法，N为正整数。
8.根据权利要求1所述POS数字签名防切机系统，其特征在于，当服务器端根据客户预先定制的应用私钥进行原始文件签名时，所述POS数字签名防切机系统包括固件密钥对、初始密钥对和应用密钥对；
所述固件公私钥中的私钥用于对固件及固件中的重要数据进行签名，公钥用于验证固件及固件中重要数据的签名；
利用初始公私钥对中的私钥对应用公私钥对中的公钥签名，存在POS机系统中的初始公私钥对中公钥验签后得到应用公私钥对中的公钥，并将应用公私钥对中的公钥覆盖初始公私钥对中的公钥；
应用公私钥对至少同时保存2对，用于对使用应用公私钥对中私钥签名程序验签。

POS数字签名防切机系统\n技术领域\n[0001] 本发明涉及程序装置领域，尤其涉及一种POS数字签名防切机系统。\n背景技术\n[0002] 目前POS机大量普及及运用于各种行业中，银行卡收单业务，作为银行卡体系运作的收单环节，也是银行卡受理环境最重要的组成部分。随着近年来银行卡业务的发展，特别是11年底人民银行放开银行卡收单限制，开始发放第三方支付牌照，收单市场得到了极大发展。POS布放量屡创新高。\n[0003] 但在收单市场蓬勃发展的同时，粗放的发展方式与无序竞争也产生的很多问题与金融风险。其中，POS代理商自行切换POS程序，是最为严重的金融风险之一。代理商从非正式渠道取得POS设备，自行切换POS程序，将原有的正规、安全的POS应用切换成其他未知应用，形成交易风险。\n[0004] 因此，为了杜绝这类行为，规避金融风险。本发明采用数字签名防切机系统杜绝此类问题的发生。\n发明内容\n[0005] 本发明的目的在于提供一种POS数字签名防切机系统及方法，从而解决现有技术中存在的前述问题。\n[0006] 为了实现上述目的，本发明所述POS数字签名防切机系统，所述系统包括：客户端、服务器端和POS机运行系统，所述客户端与所述服务器端通信连接；\n[0007] 所述客户端，负责将程序软件代码和代码可执行文件一起发送到服务器端，服务器端将代码进行备份，将代码可执行文件签名，获得被签名数据后，向POS机运行系统公布程序软件的发版；\n[0008] 所述服务器端，负责对客户端发送的数据签名，并将签名后的数据返还到客户端；\n[0009] 所述POS机运行系统，获得安装的软件有新版发布时，请求下载并安装运行所述新版软件，在下载、安装运行新版软件过程中利用POS机运行系统中存有的公钥进行验签。\n[0010] 优选地，所述服务器端对客户端发送的数据签名，具体按照下述步骤实现：\n[0011] S11，获取需签名原始文件F，确定签名算法，并生成需签名原始文件F签名前的数据格式I，所述数据格式I为164字节，包括算法标识、公钥ID、附加信息和文件信息；\n[0012] S12，判断需签名原始文件F中是否包括重要数据字段D，如果是，则，先完成对重要数据字段D的签名，进入S13；如果否，随机填写签名后文件中重要字段的哈希值和签名值，且在签名后文件信息中设置重要数据字段处的字节长度为0，然后进入S13；\n[0013] S13，使用哈希算法计算需签名原始文件F的哈希值，得到Hash(F)，记为H2；\n[0014] S14，在正在签名的文件信息中填充随机数R2，填充长度为Length(S)-Length(I)-Length(H2)，其中，Length(H2)为需签名原始文件F哈希值的字节单位长度；\n[0015] S15，使用私钥根据确定的签名算法，对I|H2|R2|0xDC进行签名，得到需签名原始文件F的签名SF，所述0xDC为签名结束的标记；\n[0016] S16，获取需签名原始文件签名SF的字节长度LSF和/或重要数据字段签名LSD的字节长度，获取附加信息字段的总长度La，获取签名包标志E，所述标志E为字符串\nSIGNED.VERSION01；\n[0017] S17，形成完成的签名后的文件，其格式为：F|La|SD|SF|I|LSF|LSD|E；其中，符号|表示内容按字节流连接；\n[0018] 所述重要数据字段D的签名，具体为：\n[0019] A1，计算重要数据字段D的哈希值，即为H1；\n[0020] A2，在正在签名的文件信息中填充随机数R1，随机数R1的长度为Length(S)-Length(I)-Length(H1)，其中，Length(S)为签名密钥的字节单位长度，Length(I)为需签名原始文件F签名前的数据格式I的字节单位长度，Length(H1)为重要数据字段D哈希值的字节单位长度；\n[0021] A3，使用预先定制的私钥根据确定的签名算法，对I|H1|R1|0xDC进行签名，得到重要数据字段的签名SD，所述0xDC为签名结束的标记。\n[0022] 优选地，所述POS机运行系统在下载、安装运行新版软件过程中利用POS机运行系统中存有的公钥进行验签，具体按照下述步骤实现：\n[0023] S21，查看正处于下载或安装运行新版软件的数据文件信息中是否包括签名包标识E，如果是，则正处于下载或安装运行新版软件为签名后的文件，进入S22判断签名文件是否有效；如果否，则下载或安装运行新版软件不是签名后的文件，提示下载不成功或安装运行失败的提示；\n[0024] S22，假定需验证的签名文件格式为F’|La’|SD’|SF’|I’|LSF’|LSD’|E；\n[0025] F’表示需验证签名文件对应的原始文件，La’表示需验证签名文件中附加信息的总长度，SD’表示需验证签名文件中重要字段的签名，SF’表示需验证签名文件对应的原始文件的签名，I’表示F’的数据格式，LSF’表示SF’的字节长度，LSD’表示SD’的字节长度，[0026] S23，查看I’中的签名算法、哈希算法标志是否均为0x00，如果是，则需验证的签名文件无效；如果否，则进入S24；\n[0027] S24，根据I’中的原始文件长度和重要数据长度，分别提取原始文件f和重要数据d；然后根据I’中的算法标志，分别计算原始文件f和重要数据d的hash值，得到Hf和Hd；\n[0028] S25，根据LSF’、LSD’分别提取SD’、SF’，在SD’、SF’的基础上，使用公钥解密需验证签名文件的签名数据得到签名前的数据格式I、签名前原始文件的哈希值H2、签名前原始文件重要数据字段的哈希值H1；\n[0029] S26，判断解密得到的I和需验证的签名文件中明文存在的I’、解密得到的H2和Hf、解密得到的H1和Hd是否均一致，如果是，需验证签名文件的签名验证通过；如果否，则需验证签名文件的签名验证失败。\n[0030] 优选地，步骤S21之后还包括：验证需验证签名文件中附加信息的总长度La’与利用公钥解密得到的原始文件F签名后得到的签名文件中的附加信息的总长度La是否一致。\n[0031] 优选地，所述服务器端对客户端发送的数据签名使用的算法种类及对应的密钥长度为：\n[0032] 算法DES，对应的密钥长度为168bits；\n[0033] 算法RSA，对应的密钥长度为2048bits、3072bits、4096bits；\n[0034] 算法ECC，对应的密钥长度为224bits、256bits、384bits、512bits；\n[0035] 算法AES，对应的密钥长度为2048bits、3072bits；\n[0036] 算法SM2，对应的密钥长度为256bits。\n[0037] 优选地，所述公钥ID用16字节的十六进制数表示。\n[0038] 更优选地，所述附加信息包括签名公司信息数据、签名者姓名数据、签名时间；所述签名时间为固定的8字节BCD码，精确到秒，其中最后一个字节表示星期。\n[0039] 更优选地，所述算法标识的表示形式如下：\n[0040] 算法标识0x0000时，表示该镜像未经过签名，其后续域，除了签名包标识域以外的域为无效数据；\n[0041] 算法标识0x00表示不签名，算法标识0x0N表示不同密钥长度同一算法，N为正整数。\n[0042] 优选地，当服务器端根据客户预先定制的应用私钥进行原始文件签名时，所述POS数字签名防切机系统包括固件密钥对、初始密钥对和应用密钥对；\n[0043] 所述固件公私钥中的私钥用于对固件及固件中的重要数据进行签名，公钥用于验证固件及固件中重要数据的签名；\n[0044] 利用初始公私钥对中的私钥对应用公私钥对中的公钥签名，存在POS机系统中的初始公私钥对中公钥验签后得到应用公私钥对中的公钥，并将应用公私钥对中的公钥覆盖初始公私钥对中的公钥；\n[0045] 应用公私钥对至少同时保存2对，用于对使用应用公私钥对中私钥签名程序验签。\n[0046] 本发明的有益效果是：\n[0047] 1、采用一对一的方式进行，签名的过程中，为每个客户定制用于加解密的公私钥对，保证签过名的不同客户的程序之间不能下载、运行。\n[0048] 2、算法采用非对称及目前主流的算法，基本无法破解，可以防止用户的暴力破解、非法使用。\n[0049] 3、申请审批采用网络备份的方案，可以做到有效的管控。\n附图说明\n[0050] 图1是服务器端对客户端发送的数据签名的流程示意图；\n[0051] 图2是重要数据字段D的签名的流程示意图；\n[0052] 图3是POS机运行系统在下载、安装运行新版软件过程中利用POS机运行系统中存有的公钥进行验签的流程示意图。\n具体实施方式\n[0053] 为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施方式仅仅用以解释本发明，并不用于限定本发明。\n[0054] 实施例\n[0055] 本实施例所述POS数字签名防切机系统，所述系统包括：客户端、服务器端和POS机运行系统，所述客户端与所述服务器端通信连接；\n[0056] 所述客户端，负责将程序软件代码和代码可执行文件一起发送到服务器端,服务器端将代码进行备份，将代码可执行文件签名，获得被签名数据后，向POS机运行系统公布程序软件的发版；\n[0057] 所述服务器端，负责对客户端发送的数据签名，并将签名后的数据返还到客户端；\n[0058] 所述POS机运行系统，获得安装的软件有新版发布时，请求下载并安装运行所述新版软件，在下载、安装运行新版软件过程中利用POS机运行系统中存有的公钥进行验签。\n[0059] 更详细的解释说明为：\n[0060] (一)参照图1，所述服务器端对客户端发送的数据签名，具体按照下述步骤实现：\n[0061] S11，获取需签名原始文件F，确定签名算法，并生成需签名原始文件F签名前的数据格式I，所述数据格式I为164字节，包括算法标识、公钥ID、附加信息和文件信息；\n[0062] S12，判断需签名原始文件F中是否包括重要数据字段D，如果是，则，先完成对重要数据字段D的签名，进入S13；如果否，随机填写签名后文件中重要字段的哈希值和签名值，且在签名后文件信息中设置重要数据字段处的字节长度为0，然后进入S13；\n[0063] S13，使用哈希算法计算需签名原始文件F的哈希值，得到Hash(F)，记为H2；\n[0064] S14，在正在签名的文件信息中填充随机数R2，填充长度为Length(S)-Length(I)-Length(H2)，其中，Length(H2)为需签名原始文件F哈希值的字节单位长度；\n[0065] S15，使用私钥根据确定的签名算法，对I|H2|R2|0xDC进行签名，得到需签名原始文件F的签名SF，所述0xDC为签名结束的标记；\n[0066] S16，获取需签名原始文件签名SF的字节长度LSF和/或重要数据字段签名LSD的字节长度，获取附加信息字段的总长度La，获取签名包标志E，所述标志E为字符串\nSIGNED.VERSION01；\n[0067] S17，形成完成的签名后的文件，其格式为：F|La|SD|SF|I|LSF|LSD|E；其中，符号|表示内容按字节流连接；\n[0068] 参照图2，所述重要数据字段D的签名，具体为：\n[0069] A1，计算重要数据字段D的哈希值，即为H1；\n[0070] A2，在正在签名的文件信息中填充随机数R1，随机数R1的长度为Length(S)-Length(I)-Length(H1)，其中，Length(S)为签名密钥的字节单位长度，Length(I)为需签名原始文件F签名前的数据格式I的字节单位长度，Length(H1)为重要数据字段D哈希值的字节单位长度；\n[0071] A3，使用预先定制的私钥根据确定的签名算法，对I|H1|R1|0xDC进行签名，得到重要数据字段的签名SD，所述0xDC为签名结束的标记。\n[0072] 其中\n[0073] (1)所述服务器端对客户端发送的数据签名使用的算法种类及对应的密钥长度为：\n[0074] 算法DES，对应的密钥长度为168bits；\n[0075] 算法RSA，对应的密钥长度为2048bits、3072bits、4096bits；\n[0076] 算法ECC，对应的密钥长度为224bits、256bits、384bits、512bits；\n[0077] 算法AES，对应的密钥长度为2048bits、3072bits；\n[0078] 算法SM2，对应的密钥长度为256bits。\n[0079] (2)所述算法标识的表示形式如下：算法标识0x0000时，表示该镜像未经过签名，其后续域，除了签名包标识域以外的域为无效数据；算法标识0x00表示不签名，算法标识\n0x0N表示不同密钥长度同一算法，N为正整数。举例子为表1：\n[0080] 表1表示两种不同算法的算法标识与算法标识对应的含义\n[0081]\n[0082] (3)附加信息是开发人员溯源的有效手段。对于设备的签名验证而言，无具体意义。所述附加信息包括签名公司信息数据、签名者姓名数据、签名时间；\n[0083] 签名公司信息数据用ASCII字符表示，其他填充为0。\n[0084] 签名者姓名数据用ASCII字符表示，其他填充为0。\n[0085] 所述签名时间为固定的8字节BCD码，YYYYMMDDHHMMSSWW，精确到秒，其中最后一个字节表示星期。\n[0086] (4)所述公钥ID用16字节的十六进制数表示。\n[0087] (5)填充随机数由外部生成的随机数，防止对同一固件镜像的签名结果一致。\n[0088] (6)签名数据表示对参与签名的域的散列/杂凑值进行签名，得到签名结果。其有效数据长度由签名算法和散列/杂凑算法决定，为密钥长度或者密钥长度的2倍。\n[0089] (7)签名包标识表示二进制文件包含签名包。如果该二进制文件没有签名包标识，可理解为该文件不是一个有效的签名固件文件。\n[0090] (8)服务器端使用的明文密钥结构，如表2：\n[0091] 表2服务器端使用的明文密钥结构\n[0092]\n[0093] (二)参照图3，所述POS机运行系统在下载、安装运行新版软件过程中利用POS机运行系统中存有的公钥进行验签，具体按照下述步骤实现：\n[0094] S21，查看正处于下载或安装运行新版软件的数据文件信息中是否包括签名包标识E，如果是，则正处于下载或安装运行新版软件为签名后的文件，进入S22判断签名文件是否有效；如果否，则下载或安装运行新版软件不是签名后的文件，提示下载不成功或安装运行失败的提示；\n[0095] S22，假定需验证的签名文件格式为F’|La’|SD’|SF’|I’|LSF’|LSD’|E；\n[0096] F’表示需验证签名文件对应的原始文件，La’表示需验证签名文件中附加信息的总长度，SD’表示需验证签名文件中重要字段的签名，SF’表示需验证签名文件对应的原始文件的签名，I’表示F’的数据格式，LSF’表示SF’的字节长度，LSD’表示SD’的字节长度，[0097] S23，查看I’中的签名算法、哈希算法标志是否均为0x00，如果是，则需验证的签名文件无效；如果否，则进入S24；\n[0098] S24，根据I’中的原始文件长度和重要数据长度，分别提取原始文件f和重要数据d；然后根据I’中的算法标志，分别计算原始文件f和重要数据d的hash值，得到Hf和Hd；\n[0099] S25，根据LSF’、LSD’分别提取SD’、SF’，在SD’、SF’的基础上，使用公钥解密需验证签名文件的签名数据得到签名前的数据格式I、签名前原始文件的哈希值H2、签名前原始文件重要数据字段的哈希值H1；\n[0100] S26，判断解密得到的I和需验证的签名文件中明文存在的I’、解密得到的H2和Hf、解密得到的H1和Hd是否均一致，如果是，需验证签名文件的签名验证通过；如果否，则需验证签名文件的签名验证失败。\n[0101] 步骤S21之后还包括：验证需验证签名文件中附加信息的总长度La’与利用公钥解密得到的原始文件F签名后得到的签名文件中的附加信息的总长度La是否一致。\n[0102] (三)服务器端是否使用预先定制的私钥对原始文件签名\n[0103] (1)当服务器端使用初始密钥对中的私钥对原始文件签名时，所述POS数字签名防切机系统包括固件密钥对和初始签名验签密钥对；\n[0104] 所述固件密钥中的私钥用于对固件及固定件中的重要数据进行签名，公钥用于验证固件及固件中重要数据的签名；\n[0105] 利用所述初始签名验签密钥对中私钥对客户端发送的数据进行签名，初始签名验签密钥对中公钥存储在POS机运行系统，用于验签发版的数据。\n[0106] (2)当服务器端根据客户预先定制的应用私钥进行原始文件签名时，所述POS数字签名防切机系统包括固件密钥对、初始密钥对和应用密钥对；\n[0107] 所述固件公私钥中的私钥用于对固件及固件中的重要数据进行签名，公钥用于验证固件及固件中重要数据的签名；\n[0108] 利用初始公私钥对中的私钥对应用公私钥对中的公钥签名，存在POS机系统中的初始公私钥对中公钥验签后得到应用公私钥对中的公钥，并将应用公私钥对中的公钥覆盖初始公私钥对中的公钥；\n[0109] 应用公私钥对至少同时保存2对，用于对使用应用公私钥对中私钥签名程序验签。\n[0110] 其中，密钥生成和管理：运行于PC端的管理工具，通过USB与U-Key交互。\n[0111] 管理工具的功能包括：支持RSA密钥对的生成，支持密钥强度为1024bits和\n2048bits；支持密文导出私钥，导出的私钥需要受由两个分量组成的密钥保护，密钥强度至少相当于192bit 3DES；支持密文私钥的导入；可以将生成的私钥、或密文导入的私钥，下载到U-Key当中；可以明文导出公钥。\n[0112] U-Key的功能包括：支持通过编程接口导入RSA私钥，支持密钥强度为1024bits和\n2048bits；安全存储私钥，私钥不可导出；为便于管理和分发，每个物理U-Key只存储一个私钥，注意根据签名文件的类型不同，需要使用存储了对应私钥的U-Key。\n[0113] 签名工具的功能：支持对固件、应用、固件公钥、应用公钥验证公钥、应用公钥的签名；第一阶段只支持RSA 2048+SHA512。\n[0114] 以表3和表4的形式对比签名前需签名包的数据格式和签名后签名包的数据格式：\n[0115] 表示3为签名前签名包结构\n[0116]\n[0117]\n[0118] 其中，除原始文件内容由编译工具生成以外，其他字段由签名工具设置。\n[0119] 表4为签名后签名包结构\n[0120]\n[0121]\n[0122]\n[0123] 通过采用本发明公开的上述技术方案，得到了如下有益的效果：\n[0124] 1、采用一对一的方式进行，签名的过程中，为每个客户定制用于加解密的公私钥对，保证签过名的不同客户的程序之间不能下载、运行。\n[0125] 2、算法采用非对称及目前主流的算法，基本无法破解，可以防止用户的暴力破解、非法使用。\n[0126] 3、申请审批采用网络备份的方案，可以做到有效的管控。\n[0127] 以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。