；
[0059]图4为本申请实施例提供的软件授权方法的另一种实现流程图；
[0060]图5为本申请实施例提供的软件授权装置的一种结构示意图。
[0061]说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三” “第四”等(如果存在)是用于区别类似的部分，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示的以外的顺序实施。
【具体实施方式】
[0062]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0063]本发明实施例提供的软件授权方法应用于具有双系统的电子设备上，该双系统中的第一系统的安全性高于该双系统中的第二系统的安全性，第一系统和第二系统逻辑隔离。
[0064]目前，针对移动设备的开放环境，安全问题也越来越受到关注，基于此，业界提出将同一硬件设备划分为两种相互独立且硬件上隔离的执行环境:普通执行环境(RichExecut1n Environment, REE)和可信执行环境(Trusted Execut1n Environment, TEE) 0平台上的软硬件资源可以分别标识为两种执行环境状态，标识为安全(或可信)执行状态的软硬件资源只能由可信执行环境所访问，而标识为普通执行状态的软硬件资源则可以为两种执行环境所访问。普通执行环境运行目前常用的移动操作系统，如Android、1s等，可信执行环境运行一个功能简单、代码量小、封闭且可认为审核控制的安全操作系统。安全性较高的应用部署在安全操作系统中，并为部署在移动操作系统中的普通应用提供安全服务。移动操作系统与安全操作系统逻辑隔离，二者只能通过授权的接口进行交互。当普通应用调用相应的安全应用执行时，硬件设备由普通执行环境切换到可信执行环境，此时整个硬件设备处于可信状态，设备与外界的交互都得到控制，保证都是真实可信的行为。
[0065]本发明实施例中，第一系统可以是运行在可信执行环境的安全操作系统，第二系统可以是运行在普通执行环境的智能操作系统，如Android、1s等移动操作系统。
[0066]请参阅图1，图1为本申请实施例提供的软件授权方法的一种实现流程图，包括:
[0067]步骤Sll:第二系统下载软件的第一代码。
[0068]本发明实施例中，需授权软件的代码被软件开发者分为两部分，分别为无需授权即可执行的部分(为叙述方便，记为第一代码)，以及需要授权才可执行的部分(为叙述方便，记为第二代码)，第二代码为软件的核心业务代码，第一代码和第二代码组成软件的业务逻辑。
[0069]步骤S12:第二系统运行下载下来的第一代码，该第一代码的运行过程包括:
[0070]步骤S121:下载加密后的第二代码和加密后的第三代码；
[0071]本发明实施例中，软件开发者在发布软件代码的同时，还发布用于对第二代码进行授权的代码(为叙述方便，记为第三代码)。
[0072]其中，第二代码和第三代码均加密发布，即软件开发人员在发布第二代码和第三代码前，对第二代码和第三代码分别加密，在发布第二代码和第三代码时，发布的是加密后的第二代码和第三代码。
[0073]步骤S122:向第一系统发送第一请求消息，以使第一系统对加密后的第三代码进行解密；
[0074]步骤S123:在第一系统对加密后的第三代码解密成功后，向第一系统发送第二请求消息，以使第一系统对加密后的第二代码进行解密；
[0075]其中，第二代码由第一系统运行第三代码而得到，也就是说，第一系统对加密后的第二代码进行解密的过程是通过第一系统运行第三代码实现的。第三代码的运行过程包括:
[0076]接收到第二请求消息后，检测第一系统和第二系统的安全性，在检测出第一系统和第二系统均安全时，发起认证过程，当认证通过时，对加密后的第二代码进行解密得到第二代码。
[0077]步骤S13:第一系统对加密后的第二代码解密成功后，将第二代码拷贝到第一系统与第二系统的共享内存中。
[0078]将第二代码拷贝到第一系统与第二系统的共享内存中后，就可以在第二系统加载运行软件了。
[0079]可见，本发明实施例提供的软件授权方法，将软件解密过程和认证授权的过程都放置在可信执行环境(即第一系统)下运行，普通执行环境下的攻击不会影响可信执行环境下的安全，而且，本发明实施例提供的软件授权方法包括两次解密过程，第二次解密过程是在双系统均安全，且认证通过的情况下进行的，在保证电子设备安全的情况下，保证软件的运行是在授权许可下进行，提高了软件被破解的难度，提高了软件的安全性。
[0080]可选的，第一系统对加密后的第三代码进行解密的具体实现过程可以包括:
[0081]第一系统可以使用电子设备绑定的第一密钥对加密后的第三代码进行解密。
[0082]可信执行环境通常需要绑定密钥以保证可信执行环境的安全，该密钥不可导出可信执行环境，同一类型的电子设备可以共享一个密钥，该密钥可以是对称密钥，也可以是非对称密钥。
[0083]本发明实施例中，软件开发者在对第三代码进行加密时，使用电子设备绑定的密钥对第三代码进行加密。具体的，
[0084]若使用电子设备绑定的对称密钥对第三代码进行加密，则软件开发者可以向电子设备的对称密钥的享有者提交加密请求，由电子设备的对称密钥的享有者用对称密钥对第三代码进行加密。本发明实施例中，第一密钥为电子设备的对称密钥。
[0085]若使用电子设备绑定的非对称密钥进行加密，则软件开发者可以获取非对称密钥的公钥对第三代码进行加密。本发明实施例中，第一密钥为非对称密钥的公钥。
[0086]可选的，第一系统对加密后的第二代码进行解密的过程可以包括:
[0087]第一系统使用第三代码中携带的第二密钥对加密后的第二代码进行解密。
[0088]本发明实施例中，软件开发者使用自定义的密钥对第二代码进行加密，并将密钥集成到第三代码中。
[0089]第一系统在对加密后的第三代码解密成功后，当需要对加密后的第二代码进行解密时，使用第三代码中携带的密钥对第二代码进行解密。即第二密钥为第三代码中携带的密钥。
[0090]可选的，检测第一系统和第二系统的安全性的一种实现流程图如图2所示，可以包括:
[0091]步骤S21:分别获取所第一系统和第二系统的状态列表；
[0092]第一系统的状态列表可以是在第一系统启动过程中记录的第一系统的状态列表，第一系统的状态列表中可以包括:安装程序，第一代码完整性，第一系统启动链信息等；同理，第二系统的状态列表可以是在第二系统启动过程中记录的第二系统的状态列表。第一状态列表和第二状态列表可以均记录在第一系统中。
[0093]步骤S22:将第一系统的状态列表中的各个状态值与第一系统的预期状态值进行比较，并将第二系统的状态列表中的各个状态值与第二系统的预期状态值进行比较；
[0094]系统的预期状态值(包括第一系统的预期状态值和第二系统的状态值)可以是设备出厂时运行系统所记录的状态。
[0095]步骤S23:当第一系统的状态列表中的各个状态值均与第一系统的预期状态值一致，且第二系统的状态列表中的各个状态值均与第二系统的预期状态值一致时，确定第一系统和第二系统均安全。
[0096]当第一系统的状态列表中的各个状态值均与第一系统的预期状态值一致，且第二系统的状态列表中的各个状态值均与第二系统的预期状态值一致时，说明第一系统和第二系统的完整性均未被破坏。
[0097]任意一个系统的状态值与预期值不一样，该系统就是不安全的。
[0098]可选的，上述认证过程可以是终端身份认证，也可以是网络认证。优选的，本发明实施例提供的进行网络认证的认证过程的一种实现流程图如图3所示可以包括:
[0099]步骤S31:第一系统显示用户认证界面；
[0100]步骤S32:接收用户输入的认证码；
[0101]例如，用户输入可以从开发者向用户发送的邮件中获取认证码。用户在用户认证界面输入所获取的认证码。
[0102]步骤S33:第一系统向第二系统发送第一认证请求，第一认证请求中携带有安全性报告，用户输入的认证码和第一系统生成的随机数；
[0103]安全性报告是第一系统检测第一系统和第二系统的安全性后生成，由第一系统签名。第一系统在用户输入认证码后，生成随机数。
[0104]为了进一步提高安全性，可以对认证码和随机数进行加密。
[0105]步骤S34:第二系统接收到第一认证请求后，向网络侧的授权服务器发送第二认证请求，该第二认证请求中携带有所述安全性报告，电子设备的身份识别信息，所述认证码和所述随机数；
[0106]电子设备的身份识别信息可以是电子设备的ID，网卡MAC地址，硬盘序列号等代表网络终端特征的唯一识别信息。安全性报告中包括第一系统和第二系统的预期状态记录和详细的检验过程。
[0107]步骤S35:第二系统接收到授权服务