软件加密时保护软件著作权要注意避免的思路误区

软件加密时保护软件著作权要注意避免的思路误区

一、问题的提出

   首先引用有关“ECC加密算法”介绍的原文结尾部分内容：

“七、椭圆曲线在软件注册保护的应用
…….
软件验证过程如下：（软件中存有椭圆曲线Ep(a,b)，和基点G，公开密钥K）
…….

4、如果H=Hash 则注册成功。如果H≠Hash ，则注册失败。

…….

Cracker要想制作注册机，只能通过软件中的Ep(a,b)，点G，公开密钥K ，
并利用K=kG这个关系获得k后才可以。而求k是很困难的。

练习：
…….
软件验证过程如下：(软件中存有椭圆曲线Ep(a,b)，和基点G，公开密钥K)
…….

5、如果v=x’ 则注册成功。如果v≠x’，则注册失败。”

 一般说来，如果编码算法本身具有起码的强度，而且没有变形（等价）算法等漏洞，被该编码算法保护的软件，解密者的确不大可能在短期内有针对性地开发出实用的注册机，前提是无法改动被保护软件代码。问题是国内外的Cracker是很聪明的，如果发现不能很快地破解出“有效”的注册码，就会直接或间接“篡改”被“Crack”的软件代码，比如将上述

    “ 4、如果H=Hash 则注册成功。如果H≠Hash ，则注册失败。”
    “ 5、如果v=x’  则注册成功。如果v≠x’  ，则注册失败。”

 所以，简单地通过条件判断语句来“甄别”合法用户，可能是保护软件著作权思路里普遍存在的一个明显误区！而且由来已久，特别是在用C语言编写的软件里，这样的例子不胜枚举。

 一旦进入这个误区，那么不论应用软件的认证模块里使用何等保护强度的编码算法，也不论该编码算法是基于对称密匙还是非对称密匙，都难逃被“Crack”的命运，原因就在于“简单地通过条件判断语句来‘甄别’合法用户”导致应用软件著作权的保护异常脆弱！

 就连专业公司都存在这样的安全隐患，国内某专业生产微机安全产品的公司，在其 称异常“坚固”的加密组件里，尽管是基于RSA编码体系，遗憾的是，由于存在上述思路误区，仅仅只花了2天时间，竟然在一台Pentium 150MHz的机器上被破解。

 可见目前这个误区普遍没有引起足够的重视，情况令人担忧。

 可能有同行会说，为防止Cracker直接“篡改”软件代码，对软件加上保护“壳”好了，但是大家要知道，加保护“壳”的做法实际上并不可靠，这体现在二个方面：

 1、这是以牺牲被保护软件的性能甚至稳定性为代价的，被层层“包裹”了保护“壳”的软件（似乎获此“待遇”的往往是应用软件），在此微机可以运行，换一台微机特别是基于不同处理器体系结构的微机上却运行不稳定甚至不能运行，越是“强悍”的保护“壳”就越容易遇到这样的问题。

 上述问题的原因在于标称“强悍”的保护“壳”为防止被“调试”而在该保护“壳”的解码过程里，对其有读写“权限”的硬件寄存器/系统核心数据表等重要系统资源持续“复位/篡改”，真可谓“各显神通，无所不用其极”！而这些做法，稍有疏漏或因为计算环境的变化，被保护软件就可能运行错误甚至导致操作系统瘫痪。如果被保护软件连稳定运行（可再现计算结果）这个起码要求都打折扣，保护“壳”还有意义么

  2、再“强悍”的保护“壳”最后还是要在其解码的过程里“还原”被保护软件的，而不论其是逐步还原或是一次性全部还原。这就应了“以己之矛攻己之盾”的老话，所以不管如何“强悍”的保护“壳”，一经推出，很快就会出现解除该保护“壳”的软件，而不论该软件是通用的或是有针对性的。公开发行特别是通过互联 发行的软件，面对的是国内外的潜在用户群，其著作权（商业秘密）保护思路（方式）面临的挑战也将直接来自国内外技术一流的Cracker。

 可见，用保护“壳”来保护软件著作权，不能真正可靠地保护软件著作权！至少在防止Cracker“篡改”软件代码方面。

 当然，有能力开发保护“壳”的程序员水平都是一流的！行业主管部门在这些方面也是鼓励“百花齐放、百家争鸣”的，自然界里同样存在“生物多样性”。可执行文件的保护与破解本来就是矛盾的一体二面，保护“壳”的推陈出新也直接促进了相关技术的长足发展，如果将这些“对抗性实战”案例作为“基础教育”予以普及一定可以培养更多的后起之秀。

 问题是我们更要将注意力放在主要方面，要思考最“根本”的问题，毕竟保护“壳”技术只是计算机信息安全领域里很小的一个方面。大家是否还记得海南“军机”碰撞引发的Hacker大战家就一定明白我们自己的弱势在哪里了！少数西方发达国家对我们实施技术封锁，不管这些技术是民用还是军用。比如加密强度稍大些的设备（软件）就被其列入所谓的“战略物资”名单实施出口管制，每次我国推出自行研制的新型“超级”计算机，西方发达国家就不得不相应放宽其出口管制。“落后就要挨打”只有“自强不息”才能“振兴中华”！

 明白了保护软件著作权思路里普遍存在的一个明显误区，那么如何才能避免走入这个误区样才能更有效地保护我们的软件著作权（商业秘密）

二、问题的解决

 关键在于认证工作的“继承”上，如何继承——

  “不论前述认证结果正确与否，都将该认证结果再次作为算子，经过必要运算后对发行前已受保护的软件核心功能代码进行解码”。

 当然，我们强调软件核心功能代码在发行前已被保护，而且是被长度至少为128位即16个字节的单向HasH密匙保护（相应地采用经广泛测试的稳健的算子长度至少为128位的编码算法如128位MD5等）。应用软件如果没有正式注册，核心功能代码自然未被解码，用户也会被提示“功能受限，建议注册”。

 如此保护后，如果编码算法没有明显漏洞，要想“Crack”如此加密强度的被保护软件除了穷举，可能短期内很难找到其它的实用方法，这样的保护壁垒会让相当一部分使用常规手段的Cracker望而却步了——要知道算子长度至少为128位的稳健编码算法，要破解之需要大功率计算机或者性能优异的并行算法，而这些对于注册费用低廉的Shareware来说，已经没有意义了。而“穷举”又具有相当的难度！

 惟独被保护的核心功能代码，在解码前只能是“一团乱麻”不具可读性，而技术一流的Cracker面对的不是保护软件著作权技术参差不齐的应用软件程序员，而是面对经过广泛测试的世界级的成熟密码学实践成果，“义无返顾”地破解，结果要么是Cracker震惊世界密码学界，要么则是让Cracker无功而返。当单向密匙长度超过1024位的时候，恐怕只有…….才有兴趣，才有能力破解。

结论

 关于如何更有效地保护软件著作权，我的个人建议（仅供参考）：

 a、公开发行的应用软件里的核心功能代码被长度至少为128位即16个字节的单向密匙保护（必须采用严格的128位或以上的编码算法）；
 b、对用户输入的各项认证信息进行认证后产生一个长度至少为128位即16个字节的单向HasH密匙；
 c、产生的单向HasH密匙整体不参与任何条件比较，不论其正确与否都在合适的时候作为算子经必要单向运算后参与核心功能代码的解码；
 d、核心功能代码被解码后，如果是真正的“合法”用户，核心功能自然顺利执行，否则应用软件提示出错（肯定会出错的）。

 至于如此保护后是否还需要为公开发行的软件加上保护“壳”呢点随个人习惯好了。

 如此这般地说了一通，只是想表达一些自己很早就有了的看法，希望通过贵学院，转告即将成为Cracker的后期之秀，是可以让其少走弯路的，希望不久的将来，计算机信息安全这个行当不再由外国人唱独角戏了。

我来说两句。
ECC签名算法ECDSA是用来防写注册机的，即便是注册用户，也无法写出注册机。
他比DSA有许多优点，比如密钥短而加密强度高。
162bit的ECC密钥 相当于1024bit的RSA密钥的加密强度。
可以说ECDSA或RSA可以在很长的时间内，从根本上杜绝注册机的出现（前提是随机数没有问题）
这当然是基于现有的CPU速度而言的。
ECC是防注册机，不是防爆破的。如果所有的软件都使用签名算法，KeyGen这东西基本上就要消失了。

关于防爆破问题，从理论上说，只要软件可以在机器上正常运行所有功能一次，这个软件就可以有爆破版，因此无论你如何做，也无法防止正版用户的破解。 这也是就是说，随着保密技术的不断加强，Cracker业余爱好者将无软件可pj
因为pj模式会变成这样

因为要涉及到购买环节，所以说Cracker为了自己的爱好，很难不和盗版商勾结。（不幸）

我认为彻底解决这个问题只有Server-Client模式
将关键代码做成接口，放在服务端。客户端只有输入正确的用户名和密码，服务器才会运行这个接口，并将结果返回给客户程序。当然客户端增多，会加大服务器的负担。

这样所有的Cracker就要转行当hacker了

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34618 人正在系统学习中