软件系统授权方案设计

背景

限制通过拷贝的方式复制和传播应用系统，保护版权。

需求

1.限制只有配置了授权文件才能正常运行

2.可设置多项限制条件，包括到期时间、用户数量

整体设计

如何加密？

该应用场景，需要系统运行期间对授权进行验证，因此必须可以反向解密，单向摘要算法如MD5不能使用。系统部署在客户方，并且java生成的中间字节码很容易被反编译，因此对称加密算法安全性较差，也不能使用。比较合适的加密算法是非对称加密，如常见的RSA，通过一对密钥对来实现加密和解密，软件系统的发行者使用私钥加密，软件系统运行时通过内置的公钥进行解密，从而提供安全性。

用什么信息作为加密项？

为避免复制和传播，授权必须与运行环境信息绑定，运行环境包括硬件和软件，硬件信息可以是mac地址、cpu序列号、硬盘序列号中的一项或几项混合，软件信息包括操作系统版本、jdk版本等，一方面注意唯一性，另一方面需考虑是否唯一不变，如虚拟化服务器硬件信息可能存在变化的情况，操作系统和jdk版本可能升级，不宜过多限制。

通常，我们有多款软件产品，还需要将软件的名称和版本号也进行加密（免费升级的情况则需要去除版本号）。

此外，如要限制使用有效期和用户数，同样需要作为加密项。

什么阶段进行授权验证？

如果在系统启动时验证，则会存在无法生成申请码的问题，因此去除该环节的验证。

业务进行时，因RSA加解密比较耗时，也不适合授权验证。

用户登录则是一个比较好的时机。

越权场景及应对

问题：如加密项只考虑mac地址，cpu序列化等服务器信息，则有可能出现单服务器部署多套软件系统问题

应对：加密项中附加运行软环境，域名/ip地址+端口 或者 软件系统对应的磁盘目录

问题：如限制用户数量，只在系统启动、添加用户环节验证，则有可能通过自动化脚本方式，在系统启动后，再从数据库层面导入用户

应对：用户登录环节验证是否合法授权。

问题：如限制ip+端口，集群环境下，是否需要为每个节点授权？用户拿到授权后再拆分成多套系统如何处理？

应对：无法杜绝，可按节点授权，单节点100%费用，增加新节点50%费用，默认只开1个http端口和1个https端口

功能设计

申请码的生成

原始加密项选择mac地址、cpu序列号、主板序列号、ip地址，拼接成字符串后取MD5，这样可以获取到一个32位简短的申请码，且无法得知哪些硬件信息参与了加密。

这样做优点就是申请码很简短，缺点是如用户说自己的授权失效了，想新申请一套，则从申请码无法得知是否是一套全新的系统。

调整优化：

使用RSA公钥，对授权对象加密后转16进制大写字母，这样可以在注册环节（生成lic文件）时可以将用户申请授权码时的硬件设备信息存档，当收到用户反馈授权失效时，可以判断是否是因为变更磁盘、CPU或网络引发的，而不是在申请另外一套系统授权。

授权文件的生成

申请码、失效日期、用户数、端口、软件编码、软件版本，私钥加密，转换为16进制大写字符串，生成lic文件。

用户无法从这一串16进制大写字符串中获取有用消息，但可以通过反编译class文件，拿到公钥，进行反编译，能看到授权文件中限制了哪些信息，如失效时间、用户数量等。

授权验证

验证申请码、失效日期、用户数、端口、软件编码、软件版本

用户登录时取20%请求验证，以避免对系统的性能影响，对于企业应用而言，登录环节因为授权验证部分登录请求耗时略长，进入系统后流畅操作，对用户体验影响较小。