CN113221074A - 一种离线授权方法 - Google Patents

Abstract

本发明涉及一种离线授权方法，方法包括：在授权服务器与离线的第一设备交互时，借助于第三方将第一设备的请求码转发给授权服务器，以及授权服务器基于第三方将对应请求码的授权码转发给第一设备，使得第一设备基于授权码使用该第一设备内的应用程序；其中，请求码和授权码均采用Base32码和RS码组成的比特格式、能够分段纠错和校验的信息码；所述授权码为所述授权服务器借助于至少一级分发服务器生成的，和/或，所述授权码为请求码、授权数据的签名信息，所述授权数据包括：一次分发模式的全部授权数据，或者所述授权数据包括：多次分发模式的全部预授权信息和授权确认信息。本发明的方法能够满足安全性的前提下，易用性高。

Description

一种离线授权方法

技术领域

本发明涉及信息安全技术领域，尤其涉及一种用于软件或数字内容保护的离线授权方法。

背景技术

目前对于数字内容的保护存在多种方案，常见的分成硬件加密方案和软件加密方案，硬件加密方式，授权存放在硬件中，受保护的软件运行时依赖于硬件；软件加密的方式，采用授权文件的方式替代硬件，授权信息存在于文件中，授权文件一般都是通过互联网在线获取。通常，借助于软件加密方式的设备需要连接互联网进行在线获取授权。然而，数字内容应用于特定的无法连接互联网的设备时，则不能通过上述互联网的方式实现授权。即在不能联网的情况下，授权数据很容易泄露和伪造，如何保证离线授权的安全性成为行业内研究的热点。

现有方案公开一种离线授权的方案，在设备不能联网时，通过手工输入授权信息。上述手工输入授权信息导致的问题是容易出错且效率低。故，需要一种快捷高效同时又安全的获取数字内容授权的离线授权方案。

发明内容

(一)要解决的技术问题

鉴于现有技术的上述缺点、不足，本发明提供一种离线授权方法，用于解决现有技术中无法联网的设备进行授权时的安全性不高，且效率低的问题。

(二)技术方案

为了达到上述目的，本发明采用的主要技术方案包括：

第一方面，本发明实施例提供一种离线授权方法，包括：

在授权服务器与离线的第一设备交互时，借助于第三方将第一设备的请求码转发给授权服务器，以及授权服务器基于第三方将对应请求码的授权码转发给第一设备，使得第一设备基于授权码使用该第一设备内的应用程序；

其中，请求码和授权码均采用Base32码和RS码组成的比特格式、能够分段纠错和校验的信息码；

所述授权码为所述授权服务器借助于至少一级分发服务器生成的，和/或，所述授权码为请求码、授权数据的签名信息，所述授权数据包括：一次分发模式的全部授权数据，或者所述授权数据包括：多次分发模式的全部预授权信息和授权确认信息。

可选地，在授权服务器与离线的第一设备交互时，借助于第三方将第一设备的请求码转发给授权服务器，以及授权服务器基于第三方将对应请求码的授权码转发给第一设备，包括：

S1、授权服务器在对一受保护的应用程序进行授权时，产生第一公私密钥对；

S2、所述授权服务器将所述第一公私密钥对中的第一私钥进行保存，并将所述第一公私密钥对中的第一公钥发送给开发商设备，开发商设备用于将所述第一公钥集成到分发第一设备的应用程序中；

S3、所述授权服务器接收第一设备借助于第三方发送的用于对所述应用程序授权的请求码，所述请求码为安装且使用所述应用程序的第一设备产生的，携带有第一设备上的机器指纹的且采用第一公钥加密的请求码；

S4、所述授权服务器根据第一私钥对所述请求码进行解密，同时依据解密的请求码中的信息生成授权数据，以及采用所述第一私钥对所述授权数据和所述请求码进行签名，得到用于借助于第三方发送第一设备的授权码，使得第一设备基于所述第一公钥验证所述授权码的签名，并在验证通过后得到授权文件以使用所述应用程序。

可选地，所述第一设备为多个时；

第一中心设备用于将所有第一设备产生的请求码进行组合，得到组合请求码；所述第一中心设备为指定的多个第一设备中的设备；

相应地，第一中心设备借助于第三方与所述授权服务器交互，获得组合授权码；

所述第一中心设备将组合授权码分发给每一台第一设备，该第一设备基于组合授权码解析出自身的授权码；或者，第一中心设备借助于第三方将组合授权码分发给每一台第一设备，该第一设备基于组合授权码解析出自身的授权码，验证授权码的授权签名的有效性，同时验证该第一设备的指纹是否包含在该第一设备的机器指纹仓库中，所述机器指纹仓库是预先安装的每一第一设备中且包括第一中心设备对应的所有第一设备的机器指纹的信息。

可选地，所述S1之后，还包括：

所述授权服务器产生预授权信息，所述预授权信息用于和应用程序同时部署在第一设备中，任一个第一设备的预授权信息依据该第一设备的授权数据确定；

相应地，所述授权服务器将各第一设备对应的预授权信息借助于第三方分发到各自的第一设备中，以使第一设备中同时部署应用程序和预授权信息；

步骤S4包括：

所述授权服务器根据请求码生成授权确认信息，并采用第一私钥对请求码、预授权信息和授权确认信息进行签名，得到用于借助于第三方发送第一设备的授权确认码，使得第一设备基于所述第一公钥验证所述授权确认码的签名，并在验证通过后得到授权文件以使用所述应用程序。

可选地，所述方法还包括：

在开发商设备确认受保护的应用程序需要升级时，所述授权服务器生成升级码，并借助于第三方将所述升级码发送第一设备；

所述升级码包括：原授权码信息和升级授权信息，和采用第一私钥进行的签名数据；

或者，升级码包括升级授权信息和采用第一私钥进行的签名数据。

可选地，所述授权服务器为根服务器，且存在多级分发服务器时，

每一级分发服务器用于对上一级的发送的授权码进行安全性的验证并签名，依次经由最后一级的分发服务器获得最终的授权码，并发送至第一设备，第一设备中的应用程序与多级分发服务器无关联，进而第一设备采用第一公钥验证部署在授权服务器的授权码的签名，并在验证通过后得到授权文件以使用所述应用程序。

可选地，所述授权服务器为根服务器，且存在一级分发服务器时，

所述授权服务器产生第一公私密钥对，第一公私密钥对中的第一公钥用于保存到应用程序中；

第一级分发服务器产生第二公私密钥对，第二公私密钥对中的第二公钥用于发送到授权服务器；

根服务器使用第一私钥对第二公钥或第二公钥和预授权进行签名，生成第一确认码，第一确认码中还包含第二公私钥对中的第二公钥；

第一私钥签名后的预授权信息、第一确认码随同应用程序部署在第一设备中；

第一设备产生第一请求码，并发送第一级分发服务器；

所述第一级分发服务器根据第一请求码，生成用于发送第一设备的第二确认码，所述第二确认码包括：采用第二私钥对授权确认信息进行的签名；

第一设备接收第二确认码，并通过第一公钥验证部署在第一设备的预授权信息和第一确认码，以及通过第二公钥验证第二确认码，在验证通过后使用所述应用程序。

可选地，所述方法还包括：

在开发商设备需要升级受保护的应用程序的授权时，其升级码的发送验证过程和授权码的发送验证过程一致。

可选地，所述请求码和授权码均包括：对应授权信息的信息字符和校验字符；

其中，信息字符为29个，且校验字符为两个，所述校验字符用于自动校正信息字符中输入错误的一个字符；以及校验字符用于提示输入错误的两个以上的字符；

或者，信息字符为29个，校验字符为四个，所述校验字符用于自动校正信息字符中输入错误的两个字符；以及校验字符用于提示输入错误的四个字符。

(三)有益效果

本发明的有益效果是：本发明的方法在使用应用程序的设备无法联网时能够发放易于手输方式的授权码，通过对授权码的进一步安全验证，进而能够较好的保证安全性。

由于采用了公私钥加密算法，安全性和在线授权的安全性保持一致，并不会因为是离线，第三方更容易接触到授权信息而降低安全性。

在本发明的另一种授权方案中，采用预授权机制，可以大幅降低需要输入的授权信息内容的长度，只需要输入少量信息即可。

此外，本发明中采用特定的编码方式，改善输入的容错性，不会出现字符“l”和数字“1”混淆的情况，即使有少量的信息输入错误，也能实现自动纠正，无需逐个检查校验。

在本申请中，授权码采用特定的编码方式能够提高输入的准确性和提高输入速度，同时可有效实现安全性。

附图说明

图1为本发明一实施例提供离线授权方法的时序图；

图2和图3分别为本发明另一实施例提供离线授权方法的时序图；

图4为本发明一实施例提供设备中授权信息的示意图；

图5为本发明一实施例提供的多级分发授权文件的结构示意图。

具体实施方式

为了更好的解释本发明，以便于理解，下面结合附图，通过具体实施方式，对本发明作详细描述。

为了更好的理解本发明实施例中的离线授权方法，以下对现有技术中的在线授权方法进行说明。

现有的在线授权方法包括：第一步：设备产生待发送授权服务器的请求码，请求码中包含设备的机器指纹信息等相关信息；第二步：授权服务器接收设备发送的请求码，并根据请求码产生授权码，授权码包含所有的授权信息，比如使用日期，模块信息等；第三步：设备接收授权服务器发送的授权码，并基于授权码产生有效的授权文件；第四步：设备基于授权文件打开受保护的软件/数字内容。

上述在线授权的过程是通过互联网进行数据传输，所以请求码、授权码的长度以及网络通讯次数都无需考虑很多，但是如果是离线授权，设备无法通过网络传输，因为安全策略或其他原因等，也不方便通过U盘和光盘拷贝，只能通过手工输入，这时就需要考虑在安全性不降低的情况下，解决易用性问题。

为了更好的理解本发明离线授权方法，以下对各词语进行解释说明。

应用程序：开发商开发的软件，需要被授权后才能在指定的设备上运行；

设备/第一设备：应用程序运行的载体，待授权的电子设备或计算机设备；

授权服务器：负责发方授权的服务器，包含数据库，授权管理系统。

请求码：设备/第一设备上的应用程序产生的请求信息，包含设备的指纹(如机器指纹)等信息；

授权码：授权服务器产生的包含授权内容的信息码。

实施例一

本实施例提供一种离线授权的方法，如图1所示，其包括下述的步骤：

101、授权服务器产生与应用程序匹配的第一公私密钥对。

在本实施例中，授权服务器可以采用RSA、ECC等算法产生一对第一公私密钥对，该第一公私密钥对中的第一私钥存储在授权服务器中，第一公钥保存到应用程序中，后续会和应用程序一同安装到设备中，在授权验证时采用第一公钥进行验证。

102、开发商开发应用程序，应用程序内集成第一公私密钥对中的第一公钥。

可以理解的是，开发商在开发应用程序之前，可以借助于授权服务器产生待开发的应用程序匹配的第一公私密钥对，由此，在开发商基于开发商设备开发出该应用程序时，可以实现该应用程序内集成有第一公私密钥对中的第一公钥。

开发商开发的应用程序，包含应用程序的唯一标识，同时，应用程序内包括第一公钥。在具体实现中，第一公钥可以作为证书单独安装。

103、开发商设备基于开发的应用程序进行分发，设备安装应用程序。

现有技术中可以通过线上或线下的方式实现应用程序的分发，在本申请中由于是使用应用程序的设备属于安全设备或者不能联网的设备，故只能通过线下的方式实现应用程序的分发。

104、设备内的应用程序启动运行后，会产生用于与授权服务器配合的第二公私密钥对，并保存在设备中。

本实施例中，应用程序的标识供授权服务器识别，并使授权服务器在授权服务时能正确发放授权，授权服务器可以支持多个应用程序的授权发放，采用正确的私钥加密，一个授权密钥对对应一个或多个应用程序或模块。

105、设备产生请求码，请求码中包含设备的指纹，设备时间，应用程序标识，第二公钥，随机数等，请求码采用第一公钥进行加密。

具体地，设备中的应用程序产生请求码，请求码包含如下信息：机器的指纹(包括但不仅限于硬盘、CPU、网卡、BIOS、机器名称等，不同的设备读取的不同)，应用程序的标识，用户标识，如果已经有授权，读取当前的授权版本，组成请求码。

为了缩短请求码，只有机器指纹是必选，其他都是可选。机器指纹也可根据需要进行选择一个或多个，机器指纹可以是机器指纹的原始值，也是可以是变换(比如哈希)后的值，授权服务器只需要和请求码的处理方法对应即可。涉及到隐私问题，部分设备只允许读取设备指纹的明文，用户自行进行转换后发送给授权服务器。

106、设备借助于第三方将请求码发送到授权服务器。

例如，第三方可包括但不限于电话、U盘、光盘、第三方机器、打印、二维码等方式。

107、授权服务器根据使用第一私钥解密设备发送的请求码，产生授权码。

其中，授权码包含所有的授权信息，以及设备的指纹，设备的标识，并采用第二公钥进行加密，采用第一私钥进行签名。

授权码可理解为授权信息的组合，比如授权日期，授权的模块数量，授权的用户数，授权的一些配置信息等，把这些信息按照一定的方式组织起来，然后通过加密签名组织成授权码。授权码的组成可以有很多种方式，本实施例不对其限定。下述任一实施例中授权码的长度都不变化，通过授权码对应的算法对各信息进行安全加密，获得指定长度的授权码。

授权服务器根据身份标识进行授权，包括但不限于使用日期、使用次数、模块授权等，把所有的信息组成授权码。授权码的组成方式有多种，一例如，明文组码方式和加密组码方式。如果为了可读性强，直接通过授权码不需要解析就可读懂授权信息，可采用明文组码，明文带来的缺点是码长会略有增加，另外如果授权码中包含私密信息，比如包含数据库的密码等，则不适合明文。

针对加密组码方式，加密的密钥的选择可以有多种方式，可以是固定密钥，或是采用一次一密，设备产生一个随机数作为密钥因子借助于第三方发送给授权服务器，授权服务器对随机数按照事先协商好的变换算法方法进行变换，产生加密密钥，加密授权数据并借助于第三方发送给设备。

另外，还可以采用数据签名的方式实现，无论是否对数据加密，都会在数据的末尾添加数据的签名，签名的私钥从数据库中获取，设备对数据验签时，公钥从设备的程序中获取，只有验证签名通过，才表示授权数据是合法有效的。

108、设备借助于第三方收到授权码时，采用第二私钥进行解密，并通过第一公钥验证签名，同时获取设备上指纹和授权码中的指纹进行匹配，全部通过后，添加授权到设备。

也就是说，设备收到授权码后，根据数据格式解析授权码，并把授权数据保存到设备中，签名也会一并保存。

需要说明的是，本实施例中请求码可已根据需要包含多项信息，但必须包含设备的机器指纹，例如“mid:xxxx”,或者“cpu:xxxx；mac:yyyy”。

授权码包含信息和签名，例如：“exp:30；sign:xxxx”。

请求码和授权码的格式可以根据需要进行自定义。如果没有要保密的信息，可以采用明文的方式，因为有签名，所以不会被篡改。

本实施例中的签名算法可根据实际需要进行选择。由于本发明实施例中涉及的是离线授权方案，为此，在本发明实施例中授权码在满足安全的前提下，授权码较短且易用性强。

对于无法联网的安全性设备，在生产或安装时把模块数据和授权内容(如预授权信息)导入到设备。应说明的是，此时导入的授权内容并不属于被激活的内容，其不能授权使用，需要进行单独的授权激活流程，在授权激活流程中，其数据量非常小，由此可以较好适用于离线授权。另外，前述实施例中的请求码包括机器指纹，其对应的授权码可仅包括对机器指纹，授权时间的一个签名。

实施例二

本实施例中的离线授权可以不通过网络，并可以安全可靠的对使用应用程序的设备实现授权。现有技术中在授权码对应较多的模块进行授权时，其授权码的信息或数据较多，不方便人工输入，其易用性差，为此，本实施例中把授权码分成两个部分，第一部分作为预授权信息可以根据应用程序共同部署在设备中，第二部分则数据非常少，可以保证安全使用的前提下，提高易用性。

也就是说，本实施例的授权码的第一个部分是预授权信息，预授权信息可包含全部的授权数据，该些数据包括但不限于授权时间、授权模块、用户数、产品信息等。特别说明的是，预授权信息中授权数据不包含机器指纹和授权签名。同时，预授权不能被设备直接使用。也就是说，预授权和设备之间不存在任何关联关系，也不绑定设备。

授权服务器可以提前产生用于跟随应用程序一并安装的预授权信息，并将其保存成文件，然后和安装程序一起安装。通过对授权数据的划分，可以避免手动输入较长的信息；

本实施例中授权码的第二部分是授权签名，包含指纹和授权签名，设备在授权使用应用程序时，只有将预授权和授权签名组合才可以实现对应用程序的完整授权，此时才能够使用应用程序。

上述划分两部分的授权数据其授权签名中可不包含授权数据，所以数据量会比较小，方便手工输入。当然，在其他扩展实施例中，授权码还可以划分三部分或四部分等，本实施例不对其限定，均在本发明的核心构思之内。

特别说明的是，本实施例中每一设备的预授权信息为授权服务器根据该设备的授权数据确定的。任意两台设备的预授权信息可不相同。只有两台设备的授权数据均相同时，该两台设备的预授权信息可能相同，在其他相同下，任意两台设备的预授权信息可不相同，由此，可较好的保证每一台设备的授权安全性和易用性。

结合上述实施例一的步骤进行说明，在步骤101中，授权服务器在产生第一公私密钥对之后，为了授权的易用性，还可产生针对指定授权设备的授权码的第一部分即预授权信息，如图2所示。本实施例中的预授权信息和请求码、第一公钥等均无关，是由授权服务器直接产生，预授权信息只包含授权服务器设定的授权信息。通常为批量化操作，预授权信息可以不关联一台设备，可用于任何设备，只是授权验证时不能独立使用，必须配合确认码才可以工作。预授权信息相当于以前的授权信息拆分成了两部分，一部分是预授权信息，和设备无关，一部分是确认信息即确认码，和设备绑定。

相应地，在步骤102中，开发商开发应用程序，应用程序内集成第一公私密钥对中的第一公钥，以及指定设备的预授权信息随同应用程序一同部署到指定设备中。

本实施例中，第一公私密钥对只需要在最开始产生一次，授权服务器可以产生多次的预授权信息，比如每个客户的设备都产生一个预授权信息。实际应用中，第一公私密钥对是在开发商开发软件之前产生，预授权信息是在设备安装软件之前产生，每一个客户的设备可配置有属于自己的预授权信息。

对应上述步骤103至步骤106的顺序和信息均相同。

在步骤107中，授权服务器根据使用第一私钥解密设备发送的请求码，并基于该解密的请求码、预授权信息产生授权码。此时的授权码中包括的签名可为授权签名信息。

在本实施例中授权签名数据通常是对要发送的所有数据包的内容进行的签名，防止对数据包内容进行篡改。基于前述描述，本实施例中授权签名是不包括设备的指纹信息，由此提高授权签名可输入性，易用性。在其他实施例中，授权签名是可以包括设备的机器指纹/指纹信息，本实施例不对其限定。

本实施例中的预授权信息可以是：“module:aaa；module:bbb；data:xxxx”,授权签名可以是：“mid:mmmm；sign:ssss”。

实施例三

上面两个实施例的方案是对一台设备进行授权，如果有多台设备需要获取相同的授权，采用上述实施例一或实施例二的方式则很不方便。

本实施例中可以在每台设备均产生各自的请求码之后，把所有设备的请求码按照一定的格式排列成一个组合请求码保存到指定设备的机器指纹仓库中，然后将组合请求码发给授权服务器。

授权服务器接收组合请求码后，对授权进行签名时，会同时对机器指纹仓库进行签名。设备安装应用程序并进行授权的时候，需要两方面的验证才能授权有效，第一方面是验证本设备的指纹是否包含在机器指纹仓库中，第二方面是验证授权签名的有效性。

需要说明的是，本实施例中所有设备的的机器指纹可预先获取存储在一个机器指纹仓库中，并同时将该机器指纹仓库存储于每一台设备中，由此，在每台设备接收授权码之后，可验证本设备的指纹是否包含在机器指纹仓库中，以及验证授权签名的有效性。

离线授权可以实现脱离网络实现授权，预授权也可以减少数据的输入量，但如果设备数量很多，每个设备一个请求码，一个授权码，授权的输入仍然有不少的工作量，因此对于多个设备进行授权，可以采用批量授权的方式。

本实施例的离线授权方法的流程可具体说明如下：

301、授权服务器产生与应用程序匹配的第一公私密钥对；

302、开发商开发应用程序，应用程序内集成第一公私密钥对中的第一公钥；

303、分发应用程序，多台设备中每一设备安装应用程序。

304、每个设备内的应用程序运行后，产生第二公私密钥对，并保存在各自的设备中。

305、每一设备产生请求码，请求码中包含设备的指纹，设备时间，应用程序标识，第二公钥，随机数等，请求码采用第一公钥进行加密。

306、每个设备都产生一个请求码，借助于独立的第三方(如操作人员)将所有设备的请求码在一个指定设备内合成一个组合请求码。

在本实施例中，所有请求码的组合的方式可以是任何一种形式，比如每行一个请求码，或者采用xml/json的方式，每台设备一个请求码等，不限组合方式和格式，保持和授权服务的处理方式一致即可。

在组合请求码中，除了每个设备的指纹不同，其他都是相同的，可以节省数据的传输量。格式如“mid:xxxx；mid:yyyy；mid:zzzz”，其中mid的内容可以是复杂的格式，可以加密，可以明文；mid可以包含设备的一个指纹，也可包含多个指纹，比如“[cpu:xxxx；hd:yyyy],[cpu:aaaa,hd:bbbb]”。

本实施例中的组合请求码和预授权码一起保存在指定设备指定的目录下，和授权确认码一起使用。

307、借助于第三方将组合请求码发送到授权服务器。

例如，该步骤中的第三方可包括但不限于电话、U盘、光盘、第三方机器、打印、二维码等方式。

308、授权服务器根据收到组合请求码后，根据使用每一台设备的第一私钥解密对应设备发送的组合请求码中的各请求码，并依序产生的一个组合授权码。

也就是说，授权服务器针对组合请求码中的每一个请求码产生一个授权码，并将产生的授权码进行组合形成组合授权码。

单个授权码的产生方式和前述实施例中单台设备的授权码的产生方式一致。

309、设备接收授权服务器发送的组合授权码并获取与自身匹配的授权码，进而先验证授权码的签名是否正确，签名内容包含预授权信息、请求码和确认码，然后读取设备指纹，验证读取的机器指纹是否包含在请求码中，验证通过后，使用授权。

具体地，在解析出自身的授权码时，采用第二私钥进行解密，并通过第一公钥验证签名，同时获取设备上指纹和授权码中的指纹进行匹配，全部通过后，添加授权到设备。

本实施例中可以减少操作的复杂度，因为离线需要人工干预，所以必须是输入输出次数尽可能的少，输入和输出的内容少。批量合并可以大大减少次数。

实施例四

授权的分发可以是由软件开发商直接通过授权服务器分发给最终用户，有的时候是软件是由开发商分发给代理商，代理商然后再分发给最终用户，还有可能存在二级代理商，三级代理商甚至更多。这里的代理商可相当于第三方，在交互过程中，可无需第三方，借助于代理商实现交互。

为了授权的安全，所有的授权数据必须经过授权服务器签名，目前的签名由于授权服务器存在私钥，可以对授权进行签名，其他中间分发服务器(即各代理商对应的服务器)无法使用授权服务器的第一私钥进行签名。

如果进行二级授权分发，需要在授权码中再添加一对公私密钥对，私钥由一级分发服务器保管，授权服务器发出的授权无法直接使用，必须经过一级分发商的二次签名才可以继续使用。同时需要把二次签名对应的公钥包含在授权码里发送给设备，目的是验证发行者。

同理，对于三级分发或更多级分发，过程类似。以下为预授权三级分发具体实施步骤，如图3所示。

401、授权服务器产生第一公私密钥对，第一公钥包含在应用程序中；第一分发服务器产生第二公私密钥对，第二公钥发送给授权服务器保存；第二分发服务器产生第三公私密钥对，第三公钥发送给第一分发服务器保存；

402、授权服务器产生预授权信息(预授权需要和确认授权配合使用)，授权服务器产生第一确认授权，第一确认授权包含第二公钥和采用第一私钥对预授权信息进行的签名。

403、预授权信息和第一确认授权发给第一分发服务器；

404、第一分分发服务器产生第二确认码，第二确认码包含第三公钥和采用第二私钥对预授权和第一确认码的签名；

预授权和第一确认授权、第二确认码发送给第二分发服务器。

在本实施例中，预授权信息在各分发服务器之间并不做任何修改，只是通过各分发服务器逐级下发。

405、第二分发服务器将上述预授权、第一确认授权和第二确认码和应用程序进行组合，以发放到第一设备中。

第一设备，此时由于缺少第三确认授权，授权并不能直接使用。

406、第一设备产生第一请求码，发送给第二分发服务器。

应说明的是，在本实施例中，第一设备即为使用应用程序的设备，该第一设备是无法联网实现在线授权的，故第一设备借助于第三方向第二分发服务器发送第一请求码。

在本实施例中，第二分发服务器、第一分发服务器和上述的授权服务器之间没有直接联网的要求。

407、第二分发服务器根据第一请求码，产生第一授权码，第一授权码包含授权信息，比如使用期限、授权的模块信息等，然后使用第三私钥对授权码进行签名，组成第三确认码，发送给第一设备。

408、第一设备通过应用程序中包含的第一公钥验证第一确认码和预授权信息，然后通过第一确认授权中包含的第二公钥验证第二确认码，通过第二确认码中包含的第三公钥验证第三确认码，所有验证通过后，第一设备可以使用授权。

在本实施例中，第一公钥是在开发程序的时候添加到应用程序中的，所有的应用程序都会包含第一公钥。第二公钥和第三公钥存放在确认授权/确认码中，是随着确认授权的发放，作为授权信息的一部分进行存储的。

实际应用中，应用程序开发完毕后就永久不变了，应用程序和任一分发服务器没有关系，任一分发服务器也不会修改应用程序，任一分发服务器是用于对授权实现分发的。

可选地，在第一设备需要升级的时候，上述方法还包括下述的步骤：

409、第二分发服务器根据第一授权码、第一确认授权、第二确认码产生第一升级码，用第一私钥签名，发放给第一设备。

第一设备逐级验证第一确认码、第二确认码、第一升级码，验证通过后使用。

第一分发服务器在此过程中主要是授权第二分发服务器，第一分发服务器有授权服务器授权，这样第一设备才能逐级验证授权。

在这里第二分发服务器在许可范围内可以直接产生升级码，也可以只能产生确认码，升级码必须有授权服务器产生，然后逐级产生确认码，步骤参见前述授权码的发放。

同样的步骤，第二分发服务器可以产生第二升级码，第三升级码等，如图5所示。

授权的二次分发，要实现两个目标，第一，其他破解者无法伪造授权；由于预授权和确认授权，是逐级签名的，破解者无法进行有效签名。第二，发放授权者无法抵赖；由于有授权发放者的私钥签名，所以授权发放者也无法抵赖。

授权的二次分发，相当于赋予第二分发服务器产生授权的能力。根据前面的描述，第二分发服务器可以无限制的发放授权，因此可以对第二分发服务器的授权分发工具进行授权保护，并利用授权限制分发的数量。

在多级分发过程中，可以省去第三方了，最后一级的分发服务器可实现第三方的功能。当然，在其他实施例中，继续使用第三方也是可以的，本实施例不对其限定，根据实际需要选择。

实施例五

离线授权的场景下经常需要通过键盘输入请求码、授权码和升级码，常见的Base64格式不适合手工输入，Base16格式太长，Base32是一种不错的选择，但是如果只是简单的Base32编码，中间输错一个字符或漏输多输一个字符，都需要花费较长的时间进行校验，找出错误。

因此，本实施例中各个请求码均采用比特编码格式，是一种扩展的Base32算法，即采用Base32和RS(Reed-Solomon)码相结合，虽然增加了少部分的数据输入量，但大大提高了一次性输入的成功率。

在本实例中，采用“ABCEFGHIJKLMNOPQRSTUVWXYZ234567”32个字符作为信息字符，采用每31个字符一组，其中29个为实际有效的授权数据，2个字符为校验字符，如果31个字符中输错一个，能自动进行校正，输错两个或以上，能提示输入错误的信息，大大提高输入的效率。或者采用4个字符为校验字符，能自动校正两个字符，检测四个错误字符。

请求码、授权码和升级码的二进制格式，先按照Base32格式进行编码，按每29个字符进行分组，每组字符串后面添加2个字节的校验码。RS码码长为31个字符，位数长度为31*5位，采用多项式g(x)＝x^5+x^2+1。不足32个字符，直接添加2个字符的校验码。

也就是说，作为离线授权的场景，经常无法进行拷贝和粘贴，大部分场景需要进行手动输入，因此本实施例中涉及到手动输入的方案，需要对数据进行编码，原始升级串数据本身是二进制数据，不利于阅读和输入，可以把按照Base64或Base32等编码方式进行编码，一般可以选择Base32，或者自定义编码，但是如果只用该编码，只有所有的数据都输入完毕后，才能通过验签失败才知道数据输入有误，回来还需要逐个对比一遍查找错误字母并进行修正。

为了解决此问题，本实施例采用分段校验的编码模式，整体采用Base32编码，每29个字符添加2个校验字符，或者27个字符添加4个校验字符，校验算法可以采用RS校验算法，这样在31个字符作为一组输入时，输错1个或2个时，能自动纠正错误，当输错2个或4个时，能指出错误的位置，虽然冗余了2个或4个字符，但大大提高输入的准确性和输入速度。

实施例六

在实际应用中，当授权服务器中确定授权数据存在更新时，授权服务器将产生一个新的数据包发送给设备。例如，操作员触发授权服务器主动产生升级包。也就是说，对已经有授权的设备进行授权升级，比如增加模块的授权，或者延长产品的有效期等。

该数据包会有两种形式，一种是该数据包除了包含更新的数据，也包含之前发给设备的老数据，也就是说是完全数据，再添加对数据的签名，这样的数据好处是可以独立运行，缺点是可能数据量比较大；

另一种是数据包只包含更新的数据，设备使用的时候无法脱离原有的数据直接使用，更新包的签名除了对现有的更新数据签名，还要对上一个数据包的签名进行签名，设备验证的时候，要全部验证才可以，这种方式的好处是升级包数据量会比较小，对于不能联网的设备会特别有优势。

本发明实施例针对升级包提供两种发放方法：

一种方法就是按照离线授权的方法重新发放完整授权，该方法好处是授权码可以独立使用，缺点是授权码的长度比较长，不易于手输。

另一种方法就是发放升级授权，升级码只包含更新的授权信息，比如授权的使用时间更改为365天，升级码为“exp:365；sign:xxxx”。升级码只包含升级更改的授权，升级码的优点是码的长度大大算短，方便输入。

为了确保安全性，防止授权码扩散，有两种方法：

1)每个授权码都包含授权设备的指纹，然后添加签名，比如“exp:365；mid:mmmm；sign:xxxx”，

2)授权码不包含设备指纹，签名的时候需要对上一次授权码或升级码的签名进行签名，这样有更好的安全性，该升级码和之前的授权码或升级码通过签名形成一个授权链，可以有效避免指纹相同的不合法设备使用升级码，同时由于没有设备指纹，该种升级码会更短。

例如：授权码A1：“module1:30；module2:365”，签名为“sign1”

升级码U1：“module1:365”,签名sign2＝sign(sign1+U1)

升级码U2：“module1:1000”,签名sign3＝sign(sign2+U2)

设备使用授权时，必须从授权链的开始逐一验证签名，必须所有的签名都通过才可以使用授权码和升级码，即先后验证通过sign1，sign2和sign3。

特别说明的是，本实施例中的升级码是指授权升级，并不是应用程序的升级。具体应用中，产生升级码可以通过新产生请求码，然后产生升级码，也可以直接利用之前保存的请求码产生升级码，这样可以少一次交互。

上述任意实施例中升级码包括授权的升级信息，比如从30天有效期改成了1年有效期，升级码则包含有效期一年的数据。同理，授权信息可能包含所有的模块信息，自定义信息等数据内容。数据内容的格式可以是自定义的。

升级码直接附加到原有的授权信息后面即可，可以附加多个升级码，设备使用时，先读取原始授权信息，然后逐个读取升级码信息，把这些信息进行合并即为最终生效的授权信息。比如开始有效期30，后来升级为一年，在后来又升级为无限制，最终的有效期就是无限制有效期。

升级的数据包可以以任何方式发送，比如借助第三方可以联网的机器，邮件，手机短信，电话，打印，U盘等。图4列举了使用应用程序的设备中授权文件的信息内容。

另外，上述任意实施例中的签名均是对全部内容签名，防止对数据内容进行篡改。本发明实施例中授权码的长度是固定的，不会随着授权信息的增加/增多而变化。

由此，上述各实施例均实现了对设备内应用程序的授权，保证了设备内应用程序的合法使用。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例，或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。

应当注意的是，在权利要求中，不应将位于括号之间的任何附图标记理解成对权利要求的限制。词语“包含”不排除存在未列在权利要求中的部件或步骤。位于部件之前的词语“一”或“一个”不排除存在多个这样的部件。本发明可以借助于包括有若干不同部件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的权利要求中，这些装置中的若干个可以是通过同一个硬件来具体体现。词语第一、第二、第三等的使用，仅是为了表述方便，而不表示任何顺序。可将这些词语理解为部件名称的一部分。

此外，需要说明的是，在本说明书的描述中，术语“一个实施例”、“一些实施例”、“实施例”、“示例”、“具体示例”或“一些示例”等的描述，是指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

尽管已描述了本发明的优选实施例，但本领域的技术人员在得知了基本创造性概念后，则可对这些实施例作出另外的变更和修改。所以，权利要求应该解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种修改和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也应该包含这些修改和变型在内。

Claims (9)

1.一种离线授权方法，其特征在于，包括：

在授权服务器与离线的第一设备交互时，借助于第三方将第一设备的请求码转发给授权服务器，以及授权服务器基于第三方将对应请求码的授权码转发给第一设备，使得第一设备基于授权码使用该第一设备内的应用程序；

其中，请求码和授权码均采用Base32码和RS码组成的比特格式、能够分段纠错和校验的信息码；

所述授权码为所述授权服务器借助于至少一级分发服务器生成的，和/或，所述授权码为请求码、授权数据的签名信息，所述授权数据包括：一次分发模式的全部授权数据，或者所述授权数据包括：多次分发模式的全部预授权信息和授权确认信息。

2.根据权利要求1所述的离线授权方法，其特征在于，在授权服务器与离线的第一设备交互时，借助于第三方将第一设备的请求码转发给授权服务器，以及授权服务器基于第三方将对应请求码的授权码转发给第一设备，包括：

S1、授权服务器在对一受保护的应用程序进行授权时，产生第一公私密钥对；

S2、所述授权服务器将所述第一公私密钥对中的第一私钥进行保存，并将所述第一公私密钥对中的第一公钥发送给开发商设备，开发商设备用于将所述第一公钥集成到分发第一设备的应用程序中；

S3、所述授权服务器接收第一设备借助于第三方发送的用于对所述应用程序授权的请求码，所述请求码为安装且使用所述应用程序的第一设备产生的，携带有第一设备上的机器指纹的且采用第一公钥加密的请求码；

S4、所述授权服务器根据第一私钥对所述请求码进行解密，同时依据解密的请求码中的信息生成授权数据，以及采用所述第一私钥对所述授权数据和所述请求码进行签名，得到用于借助于第三方发送第一设备的授权码，使得第一设备基于所述第一公钥验证所述授权码的签名，并在验证通过后得到授权文件以使用所述应用程序。

3.根据权利要求1所述的离线授权方法，其特征在于，所述第一设备为多个时；

第一中心设备用于将所有第一设备产生的请求码进行组合，得到组合请求码；所述第一中心设备为指定的多个第一设备中的设备；

相应地，第一中心设备借助于第三方与所述授权服务器交互，获得组合授权码；

所述第一中心设备将组合授权码分发给每一台第一设备，该第一设备基于组合授权码解析出自身的授权码；或者，第一中心设备借助于第三方将组合授权码分发给每一台第一设备，该第一设备基于组合授权码解析出自身的授权码，验证授权码的授权签名的有效性，同时验证该第一设备的指纹是否包含在该第一设备的机器指纹仓库中，所述机器指纹仓库是预先安装的每一第一设备中且包括第一中心设备对应的所有第一设备的机器指纹的信息。

4.根据权利要求2所述的离线授权方法，其特征在于，所述S1之后，还包括：

所述授权服务器产生预授权信息，所述预授权信息用于和应用程序同时部署在第一设备中，任一个第一设备的预授权信息依据该第一设备的授权数据确定；

相应地，所述授权服务器将各第一设备对应的预授权信息借助于第三方分发到各自的第一设备中，以使第一设备中同时部署应用程序和预授权信息；

步骤S4包括：

所述授权服务器根据请求码生成授权确认信息，并采用第一私钥对请求码、预授权信息和授权确认信息进行签名，得到用于借助于第三方发送第一设备的授权确认码，使得第一设备基于所述第一公钥验证所述授权确认码的签名，并在验证通过后得到授权文件以使用所述应用程序。

5.根据权利要求1至4任一所述的方法，其特征在于，所述方法还包括：

在开发商设备确认受保护的应用程序需要升级时，所述授权服务器生成升级码，并借助于第三方将所述升级码发送第一设备；

所述升级码包括：原授权码信息和升级授权信息，和采用第一私钥进行的签名数据；

或者，升级码包括升级授权信息和采用第一私钥进行的签名数据。

6.根据权利要求1所述的方法，其特征在于，所述授权服务器为根服务器，且存在多级分发服务器时，

每一级分发服务器用于对上一级的发送的授权码进行安全性的验证并签名，依次经由最后一级的分发服务器获得最终的授权码，并发送至第一设备，第一设备中的应用程序与多级分发服务器无关联，进而第一设备采用第一公钥验证部署在授权服务器的授权码的签名，并在验证通过后得到授权文件以使用所述应用程序。

7.根据权利要求4所述的方法，其特征在于，所述授权服务器为根服务器，且存在一级分发服务器时，

所述授权服务器产生第一公私密钥对，第一公私密钥对中的第一公钥用于保存到应用程序中；

第一级分发服务器产生第二公私密钥对，第二公私密钥对中的第二公钥用于发送到授权服务器；

根服务器使用第一私钥对第二公钥或第二公钥和预授权进行签名，生成第一确认码，第一确认码中还包含第二公私钥对中的第二公钥；

第一私钥签名后的预授权信息、第一确认码随同应用程序部署在第一设备中；

第一设备产生第一请求码，并发送第一级分发服务器；

所述第一级分发服务器根据第一请求码，生成用于发送第一设备的第二确认码，所述第二确认码包括：采用第二私钥对授权确认信息进行的签名；

第一设备接收第二确认码，并通过第一公钥验证部署在第一设备的预授权信息和第一确认码，以及通过第二公钥验证第二确认码，在验证通过后使用所述应用程序。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

在开发商设备需要升级受保护的应用程序的授权时，其升级码的发送验证过程和授权码的发送验证过程一致。

9.根据权利要求1至8任一所述的方法，其特征在于，

所述请求码和授权码均包括：对应授权信息的信息字符和校验字符；

其中，信息字符为29个，且校验字符为两个，所述校验字符用于自动校正信息字符中输入错误的一个字符；以及校验字符用于提示输入错误的两个以上的字符；

或者，信息字符为29个，校验字符为四个，所述校验字符用于自动校正信息字符中输入错误的两个字符；以及校验字符用于提示输入错误的四个字符。

Images