自定义授权机制来保护系统复制与传播

自定义授权机制来保护系统复制与传播,第1张

自定义授权机制来保护系统复制与传播 背景

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

需求

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%请求验证,以避免对系统的性能影响,对于企业应用而言,登录环节因为授权验证部分登录请求耗时略长,进入系统后流畅 *** 作,对用户体验影响较小。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5687688.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存