ECC - 在离线程序中使用ECC流程的思考

ECC - 在离线程序中使用ECC流程的思考

概述

应用场景:
一个客户端程序, 想控制授权让正常用户使用(不让非法用户使用).
付费用户会将程序生成的授权申请码(硬件特征码相关, 只有申请者这个计算机节点对应这个唯一的授权申请码)通过公开方式(e.g. 邮件, QQ, 微信)给厂家.
厂家发一个授权文件给用户, 用户用程序提供的导入授权文件的功能, 将授权文件导入(放在程序数据目录中).
程序重启后, 读这个授权文件, 得到程序运行逻辑相关的参数, 用这些参数可以使程序正常运行.

问题引出 - 参数文件防篡改

如果参数文件不加密(明文), 可以是2进制明文(人眼不可识别), 即使明文中的数据结构是一些类写入的数据(e.g. MFC CString, 或者是自定义的类数据), 经过实验(逆向找到如何读参数文件中的数据和序列化的点 + 正向编程写入参数文件试错), 也是能搞清楚如果参数文件的格式. 后续就可以伪造一个参数文件, 从而非法使用软件.

为了防篡改, 至少要加密一下. 只有能正常解密, 最后解密后的参数文件内容才是对的. 如果无法解密, 就无法得到程序逻辑正常运行需要的数据. 如果逆向工程师让程序强行往下走, 程序不是崩溃, 就是逻辑功能不正常. 这就达到软件保护的目的了.

问题引出 - 加密算法的选择

对于最终的程序应用数据, 要使用对称加密(性能高 e.g. AES256)来做, 对称密钥为KeyAes.
如果逆向工程师知道程序中是使用的具体是哪种AES256算法(e.g. CBC, key, iv), 通过逆向, 知道了对称密钥(KeyAes = key, iv), 那么他自己写一个程序, 来生成一个伪造的参数文件也不难.

问题引出 - 如何保护对称密钥

让对称密钥也被加密, 放在参数文件的指定位置(e.g. 头部和尾部的约定数据块KeySecBlock)
先解密KeySecBlock, 得到KeyAes, 再拿KeyAes来解密参数文件中的应用数据.
为了保护KeySecBlock, 自然不能再使用对称加密, 如果是对称加密, 最终会在程序中被看到.
所以, 只有用非对称加密来保护KeySecBlock.

问题引出 - 非对称算法的选择

可选的非对称算法并不多, 大概也就RSA, ECC两种可选.

RSA场景是不需要双方交换会话密钥, 只要一次加密, 单向将加密结果(授权文件)由厂家交给用户, 用户拿厂家公开的公钥来解密即可.保证了防篡改.
但是RSA效率低, 为了保证安全, 密钥长度需要选的很长. e.g. RSA2048, RSA4096

ECC场景需要双方安全交换会话密钥, 效率高, 机密程度高.(网上资料传言, ECC可能有后门, 不过对于商用级别的程序, 不用考虑ECC后门问题. 如果需要考虑, 国密算法中也有非对称加密算法SM2)

比较了RSA, ECC, 自然会选择ECC.
但是ECC场景中是要求安全交换会话密钥, 才能保证流程(用会话密钥来进行对称加解密)上是安全的. 比较适合在线的程序使用(e.g. 客户端 <-> 服务器的通讯保护)

初步看起来ECC算法的使用流程不太适合离线程序, 我又不甘心用RSA.
能不能让离线程序使用ECC来保护KeySecBlock呢?

问题引出 - 是否有可能将ECC的流程用在离线程序上?

想了好久, 改变一下角色定位, 是可以隐含省去安全会话密钥交换的步骤的, 是可以将ECC用在离线程序数据保护的.
术语定义:
厂家授权文件发放程序 = Alice
Alice的私钥(自己选的和产品相关的机密私钥数据, 不能让其他人知道, 别人也不可能知道, 只有厂家才有授权发放程序, 物理上隔绝) = privateKey_Alice
Alice的公钥(公司/产品/版本名称相关, 客户端程序中有也有相同定义, 等于是客户端已经知道了厂家的公钥) = publicKey
付费用户的离线客户端程序 = Bob
Bob的私钥(客户端的授权申请码, 已经由用户通过公开方式给了厂家, 厂家已经知道了客户端的私钥) = privateKey_Bob
Bob的公钥 = Alice的公钥(已经由研发在程序中定义了publicKey, 和授权发放程序相同) = publicKey

通过以上术语定义, 可以看出:

• 厂家授权程序端是知道用户处的客户端程序的所有信息的(包括私钥), 可以模拟客户端和厂家端做会话密钥的交换工作.
• 客户端程序是不知道厂家私钥的, 保证了安全, 但是非对称解密的条件是存在的(知道厂家公钥, 自己的公钥和私钥), 不影响使用参数文件的解密和载入.

现在看ECC流程, 看看是否可以隐含省去安全交换会话密钥的流程, 如果能省去, 就可以将ECC用在离线程序上.

ECC流程置换分析 - 代入授权文件发放和使用流程

Alice和Bob端物理隔离(不在一台计算机上)

Alice 有自己的私钥 privateKey_Alice(Alice知道privateKey_Bob)
Bob 有自己的私钥 privateKey_Bob(Bob不知道privateKey_Alice)
双方(Alice和Bob)都有相同的publicKey(Alice端程序和Bob端的程序中都写死了publicKey, 等于是公钥对于双方都已知)
Alice生成会话公钥session_public_key_Alice(publicKey + privateKey_Alice), 写入参数文件.
Alice端模拟Bob生成会话公钥session_public_key_Bob(publicKey + privateKey_Bob), 放在内存中, 用于中间运算.
Alice端生成对称密钥KeyAes_Alice(privateKey_Alice + session_public_key_Bob), 将应用数据加密.形成授权文件. KeyAes_Alice不在参数文件中
厂家将授权文件通过公开方式交给客户.
客户用程序导入授权文件, 启动客户端.
客户端从参数文件中取出session_public_key_Alice, 结合自己的私钥privateKey_Bob, 生成和Alice段相同的KeyAes_Bob(session_public_key_Alice + privateKey_Bob)
客户端拿KeyAes_Bob去解密授权文件中的应用数据, ECC => AES流程完成
在ECC中, 双方的KeyAes_X实际是相同的, 所以可以用相同的KeyAes来进行同一块AES256的加解密
KeyAes_Alice = privateKey_Alice + session_public_key_Bob = privateKey_Alice + (publicKey + privateKey_Bob)
KeyAes_Bob = session_public_key_Alice + privateKey_Bob = (publicKey + privateKey_Alice) + privateKey_Bob
KeyAes_Alice = KeyAes_Bob = KeyAes

能想到离线应用中, Alice知道Bob的一切, 这点挺关键的. 然后就可以想到ECC可以用在离线应用中.

备注

这种将ECC流程用在离线程序上是可以的.
剩下的事情就是找个大佬写的ECC实现去干活了.

END