首页
社区
课程
招聘
[翻译]prikey.c关于ecc内容翻译
发表于: 2008-3-25 11:34 9170

[翻译]prikey.c关于ecc内容翻译

2008-3-25 11:34
9170

【翻译】prikey.c关于ecc内容翻译



“翻译by nujia”  这篇翻译来自prikey.c的最后部分。


*-------------------------------------------------------------



v7.1 改进



概述



v7.1有显著的改进,有很多新的特征但是没有公开文档,包括:



     


        o SIGN=, SIGN2= ... SIGNn=


        o v7.1 SIGN 如果是 non-CRO 格式, 会有12个字符, 但是也和以前的格式有点不同.


        o CRO 格式有三种sign长度。


        o 可以使用2段过滤器,以后可能不再支持。


        o 总的来说有6点关键的功能(5个是新增的)


          


                - license-key


                - 没有使用CRO的SIGN, 与license-key有些相似


                - 支持113位sign长度  (57字节)


                - 支持163位sign长度  (84字节)


                - 支持239位sign长度  (120字节)


                - 2段过滤器    (现在没有相关文档)



          2段过滤器以后不在支持。     



有很多灵活的功能如下:



          每个checkout可以定义/忽略通过LM_STRENGTH


         


          同样,每个FEATURE 可以定义根据lmcrypt里的LM_STRENGTH的值来确定sing的长度



          这样一个公司可以自己决定在应用程序中使用LM_STRENGTH的长度。


         


          不同sign长度的原因是软件公司可以用不同的seed或不同的key过滤器(比如两段过滤器)


         


下面主要讨论cro,最后再讨论non-cro



没有公开的文档是什么?为什么没有公开?


_____________________________



1. sign目前没有公开文档,但是我认为这是非常重要的方法,将来会有很多公司采用它。



2. 在每个feature中使用不同的sign长度,目前没有公开,假如没有这个市场需求的话,我们以后将不再使用这项技术。



3. key-filters看起来已经过时了,目前还存在主要有以下几个原因:首先是它是我们采用cro的一个初始化方法。其次是我们认为仍有公司想利用这个技术来增加软件的安全性,



毕竟这不需要额外付费。最后一个原因也是最重要的一个原因是一些公司想不增加公钥的长度而获得更好的安全性。(译者注:这是不可能的,呵呵)



创建


-----


在创建一些key过滤器时,需要一步步详细的介绍。



第一个依赖关系序列如下:



    $DAEMON依赖于lsvendor.o


    lsvendor.o依赖于lm_new.o(lm_new.c)


    lm_new.c由lmnewgen生成


    lmnewgen依赖于lmcode.o(lmcode.c)


    lmcode.o由lmrand1生成,


    lmrand1依赖于lm_code.h


   


    (译者注:DAEMON->lsvendor.o -> lm_new.o ->lmnewgen ->lmcode.o ->lmrand1 ->lm_code.h)


   


这些依赖关系和flexlm v6.1是相同的,唯一不同的是lm_new.o里包含了更多的信息。 本质上,lm_code.h文件是用一个“模糊”的格式转换成了lm_new.o 。



下面是lc_new_job()里VENDORCODE结构的新添加的4项内容。



        int pubkeysize[LM_PUBKEYS];


        unsigned char pubkey[LM_PUBKEYS][LM_MAXPUBKEYSIZ];


        int strength;


        int (*pubkey_fptr)();     



LM_PUBKEYS 是 3, 所以如果使用CRO, 关于CRO的不同的信息就在VENDORCODE结构里。


pubkeysize,pubkey和长度都是计算公钥的必须的参数。



pubkey_fptr 存在于函数 l_pubkey_verify()中,除了license-generator,它叫l_prikey_sign()函数。



(这种格式用在任何license-key过滤器重,比如flexlm v6里的两段过滤器。这过滤器仍然有效,并且在servtest函数里测试过,但是我们不对此提供支持)



lm_new.o 现在包含了所有客户端的公钥信息。



公钥/私钥对


————————————



但是lm_code.h只包含SEED和VENDORCODE,它是怎样转变成公钥/私钥的呢?



公钥对由lmnewgen产生,seed3和seed4用来产生公钥对,如果seed3和seed4不变,那么每次运行都会产生相同的公钥对,但是如果你改变了seed的一位,公钥对的一半将会改变,



也就是这种改变的对应关系是不可能逆向的。从理论上讲,从公钥对是不能逆向获得seed3和seed4的。



所以,我们没有存储公钥对,ISV(独立软件开发商)应该注意到这一点。他们唯一要做的是保存好seed3和seed4。另外,一个license-generator比如像gtlicense理论上能获得



seed,为了生成license。



必须注意加密的seed3和seed4没有出现在发布的产品中,只有公钥出现在前台/后台程序中,而私钥仅仅出现在license-generator中。



lmcode.o包含了lm_code.h的信息,(lmcode.o由lmrand1程序产生。)



lmcode.o和lmnewgen.o链接生成lmnewgen程序,而它产生lm_new.c。 它调用l_gen_pkey_headers() 生成lm_new.o (它包含公钥 public-key) 和 lmprikey.h (它包含私钥



private key)。


l_gen_pkey_headers() 最后调用 Certicom 的程序 sb_genKeyPair() 生成公钥/私钥对( public-key pairs)。



总结:lmnewgen用seed3和seed4制作公钥/私钥对。公钥在lm_new.c被“模糊”化。而私钥保存在lmprikey.h中,而lmprikey.h包含在license-generator源代码中。



LICENSE GENERATOR(license生成器)



[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课

收藏
免费 7
支持
分享
最新回复 (3)
雪    币: 200
活跃值: (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
2
完全不懂....
2008-3-26 11:33
0
雪    币: 235
活跃值: (320)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
3
我也是……天书中~~
2008-3-27 15:57
0
雪    币: 749
活跃值: (45)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
4
也不懂 55555555555
2008-3-27 21:18
0
游客
登录 | 注册 方可回帖
返回