zoukankan      html  css  js  c++  java
  • 公匙算法.电子签名


    今年3月24日,《中华人民共和国电子签名法(草案)》(下称草案)经国务院原则通过,即将提请人大审议,这标志着我国首部信息化法律走出了立法第一步。由于该草案明确了合同双方和认证机构在电子签名活动中的权利和义务,其技术细节受到了各方人士广泛关注。笔者通过回顾数字签名的发展历程,结合自已在学习加密、证书技术中的心得体会,试图就电子签名问题梳理出一个脉络,向广大朋友作一个浅显的介绍。不当之处,敬请专家指正。
    基本概念
    “电子签名”是广义的提法,是以保障基于网络交易平台下交易各方的合法权益为目的,满足和替代传统签名功能的各种电子技术手段,并不是手工签字或印章的图像化,其中“交易”是指个人信息交换、电子商务和电子政务等基于网络平台的活动;“交易各方”指从事这些活动的各方当氯耍弧巴纭币话闶钦攵曰チ浴?BR> “数字签名”是通过密码技术实现电子交易安全的形象说法,是电子签名的主要实现形式。它力图解决互联网交易面临的几个根本问题:数据保密;数据不被篡改;交易方能互相验证身份;交易发起方对自己的数据不能否认。
    在密码学中,密码的本质是某种算法,由密码算法算出一把密匙(Key),然后使用该密匙对交易双方传送的数据加密。该数据通称“报文”,加密前叫“明文报文”,即明文;加密后叫“密文报文”,即密文,密文没有密匙是不可读的。所有加密算法本身都是公开的,属于纯数学的范筹,本文不作过多讨论;密码学只关注密匙管理的问题,因为加密通信的安全性只与密匙有关,这是本文关注的重点。
    加密通信方式主要有对称加密和非对称加密两种。
    在开始讨论之前,我们假定:在不安全的网络中(比如互联网),Alice是通信发起人;Bob是通信接收人;Alice与Bob相互信任;而Eve监听通信并伺机破坏:这是John Wiley和Sons在经典教程《Applied Cryptography》(《应用密码学》)中提出的部分人物,这些人物和环境属性现已成为描述密码学技术的标准。
    对称加密——解决数据本身加密问题
    顾名思义,对称加密就是“一把锁对应一把匙匙”,加锁开锁都是它。有传统和现代的区别,以下用古老的替换加密法为例作一简单说明。
    明文:HiIamAlice       密文:ZEECGCFEIP
    密匙(密码):
    A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
    C H I M P A N Z E B D F G J K L O Q R S T X Y W U V
    密匙第一排是常规26个字母,而第二排则是约定的字母顺序,用来替换对应的字母。除了字母,还可用其它约定符号起到同样的作用,都是异曲同工。
    现代的对称加密方式多用繁复的数学算法进行,当前优秀的对称加密算法有DES、3DES、DEA、IDEA等,它们的运算速度快,加密性能优异。其通信过程大致如下:
    1、由Alice通过某种对称加密算法算出一把密匙并传送给Bob;2、Alice用该密匙加密明文,得到密文;3、Alice将该密文传送给Bob;4、Bob用该密匙解密密文,得到明文。
    Eve如果只在第3步截获密文,由于不知道密匙,将一无所获。但当Eve监听到第1步,他和Bob得到的信息就一样多,到第4步,Eve的工作就是解密。并且Eve还能在第3步开始之前中断Alice与Bob的通信线路,然后冒充Bob接受Alice的信息,解密、修改后再冒充Alice加密发送给Bob,Alice和Bob始终蒙在鼓中。如果Bob受到利益损害,则Alice可以指责说这是Bob自已泄露密匙导致。
    可见对称加密的问题在于:1、必须事先传递密匙,造成密匙传递过程中(叫带内传输)极易被窃。常规手段无法解决这种高风险。2、密匙管理困难:假设有n方两两通信,如采用一把密匙,则密匙一旦被盗,整个加密系统崩溃;如采用不同密匙,则密匙数等于n*(n-1)/2,意味着100个人两两通信,则每人要保管4950把密匙!密匙管理成为不可能。3、由于密匙共享,无法实现不可否认。
    虽然对称加密对数据本身的加密能力足够强大,而且已经在政府机关和商业机构内部得到了广泛应用,但不解决上述问题,面向互联网的电子商务和电子政务就无从谈起。
    公匙加密——解决密匙带内传输问题
    1975年下半年,斯坦福大学的教授狄菲和赫尔曼向全美计算机会议提交了名为《多用户加密技术》的论文,总结了正在探索中的公匙加密技术,但没有提出新的解决方案。
    1976年5月,两人在全美计算机会议上又公布了离散指数密码算法,并在IEEE发表了著名的《密码学研究新方向》论文,提出了基于离散指数加密算法的新方案:交易双方仍然需要协商密匙,但离散指数算法的妙处在于:双方可以公开提交某些用于运算的数据,而密匙却在各自计算机上产生,并不在网上传递。EVE如果只监听而不参加运算,他是不可能从窃得的信息推导出密匙的。从而保证了密匙的安全。这是公匙加密的雏形。遗憾的是,这一类似于打电话状态的加密方法,要求交易方必须同时在线,且同样以相互信任为前提,所以仍然无法满足现代电子交易的需要。
        1978年,麻省理工学院的三名教授瑞斯特(Rivest)、沙米尔(Shamir)和艾德曼(Adleman)人从这篇论文得到启发,开发了非对称RSA公共密匙算法。由于这一算法既解决了密匙的带内传输问题,又不必交易双方同时在线,也不要求交易方必须信任,终于为现代电子商务的蓬勃发展铺平了道路。
       非对称加密是对称加密“逆向思维”的结果,即“一把锁对应两把钥匙”,任意一把加锁,但必须由另一把开锁。
    公匙加密体制的通信过程大致如下:
       1、Bob公开发布他的公匙;2、Alice用Bob的公匙加密明文得到密文并传送给Bob;3、Bob用它从不公开的私匙对该密文解密。
    尽管这次Eve可以合法得到Bob的公匙,却无法对第2步截获的密文加以解密,因为他没有Bob的私匙。
    Bob的公匙和私匙从何而来?为什么公匙加密的文件只有私匙才能解密?要搞清这两个问题,必须回过头来认识公匙加密的数学基础:大数不可能质因数分解假说。
    只能被1和本身整除的数叫质数,例如13,质数是无限的。得到两个巨大质数的乘积是简单的事,但想从该乘积反推出这两个巨大质数却没有任何有效的办法,这种不可逆的单向数学关系,是国际数学界公认的质因数分解难题。
    R、S、A三人巧妙利用这一假说,设计出RSA公匙加密算法的基本原理:1、让计算机随机生成两个大质数p和q,得出乘积n;2、利用p和q有条件的生成加密密匙e;3、通过一系列计算,得到与n互为质数的解密密匙d,置于操作系统才知道的地方;4、操作系统将n和e共同作为公匙对外发布,将私匙d秘密保存,把初始质数p和q秘密丢弃。  
    国际数学和密码学界已证明,企图利用公匙和密文推断出明文——或者企图利用公匙推断出私匙的难度等同于分解两个巨大质数的积。这就是Eve不可能对Alice的密文解密以及公匙可以在网上公布的原因。
    至于“巨大质数”要多大才能保证安全的问题不用担心:利用当前可预测的计算能力,在十进制下,分解两个250位质数的积要用数十万年的时间。并且质数用尽或两台计算机偶然使用相同质数的概率小到可以被忽略。
    公匙加密最大和唯一的问题是运算速度缓慢,理论上,对称加密算法的速度要比它快上了数百倍。
    形象的说,公匙就是写有Bob名字、绝对坚固但特别笨重的邮箱,它可以放在任何地方,任何人都知道那是Bob的,所有人都能从邮箱的缝隙中塞进纸条。但只有Bob才有唯一的开锁匙匙(私匙)。所以在上面的通信过程中,Eve即使得到装有Alice纸条的Bob的笨重邮箱,也没有任何意义。
    至此,密匙的“带内传输”问题解决了,也就解决了四个根本问题中的“保密”这一问题,但“不可否认”、“身份确认” 和“不被篡改”的问题又接踵而至:
    既然谁都能塞进纸条,Alice不承认有他落款的纸条是他写的怎么办?
    单向Hash函数——实现身份验证的幕后英雄
    在公匙加密体系中,剩下三大任务任务都由“单向Hash函数算法”(下称Hash)来完成,由它配合公匙加密算法,最终完成身份确认、不可否认和不被篡改工作。
    和公匙加密不同,Hash不是加密,只是函数;其作用不是生成密匙,而是生成报文的“数字指纹”。正是这种数字指纹实现了“验证”、“不可否认” 和“不被篡改”。
    Hash函数的工作原理并不复杂:1、通过数学算法,把未做处理的报文(不论是明文还是密文)转换为不定长的待输入字符串,称为预映射值;2、将预映射值再次转换为定长(一般更短)的输出字串,称Hash值,又叫消息摘要(Message Digest),预映射值可任意长,但Hash值总是定长;报文或预映射值有丝毫改动,则Hash值完全不同。
    所谓“单向”,是指不可能由Hash值反推出预映射值或报文,但又不是加密,因为不存在解密的问题。正由于其单向,也就没有了运算速度的障碍。举个例子,就像一片玻璃(预映射值)很轻易就被打碎,但破碎的玻璃渣(Hash值)却不可能恢复到破碎前的状态。
    值得一提的是,最常用的Hash算法叫做MD5(Message Digest 5),它的作者是罗纳德·瑞斯特:RSA中的第一人。
    这样我们就可以综合运用公匙算法和Hash算法,对上述加密通信过程重新设计一个完整的解决方案:
    1、Alice首先以对称算法生成密匙K,并用K将明文D生成密文DC;2、Alice用Bob的公匙将对称密匙K加密为KB,将DC和KB封装;3、将封装后的DC和KB 用Hash算出Hash值H,用Alice的私匙加密为HA;4、将DC、KB和HA封装为一个数据块发送给Bob。
    这时的Eve有公匙算法,有Hash算法,有Alice与Bob的公匙,唯独没有二人的私匙,所以在截获数据块后,可以分析出DC、KB和HA三个部份,其中DC是密文,没有密匙K无法读取;K又被Bob的公匙加密成KB,没有Bob的私匙同样无法读取;虽然HA 可以由Alice的公匙还原为H,但从H不可能反推出预映射值,所以对Eve毫无意义。
    Bob收信后,只需简单的对DC和KB再次用Hash算法算出Hash值HB,并将它与HA比较,相同该数据块真,不同则该数据块假。如果为真,则Bob用自己的私匙解密KB,  得到对称密匙K,再用K解密DC,得到D。
    可见,只要Eve对D、KB、H和HA中任意一项有丝毫改动,那么Bob收信后都会认定该数据块无效,进而确认该数据块是否真的是Alice发来——就算Eve伪造了新的数据块DE、KE和HE,问题是他没有Alice的私匙,也就不可对HE加密,而他如果复制H值,又会因为DE、KE用Hash计算后值与H肯定不同而失败——这一番巧妙周旋,彻底斩断了Eve的黑手!
    以上在对Bob实现“身份验证”的同时对Eve实现“不可篡改”!
    而H之所以用Alice的私匙加密为HA的深意在于——由于公匙加密体系保证了只有Alice自己才有私匙,所以简单反推一下,我们不难看出一旦Bob的验证通过,Alice就已经绝对“不可否认”这整个数据块都是他自己的大作了。
    所以整个方案的核心在第3步:用Hash算出H,并用自己的私匙将其加密为HA,这就是本文的中心:“数字签名”!
    至此,公匙由于被用来加密密匙而不是报文,加密速度和性能大大提高,于是“笨重邮箱”变成“轻巧信封”,而内在的“加密”功能一点也没有减少——并同时实现了“身份验证”、“不可否认” 和“不被篡改”。
    小结一下,在“公匙+Hash”的组合中:私匙用来进行解密和签名,而公匙用来加密和验证签名;加密不可逆,只有私匙才能解密。由于私匙仅为本人所有,这样就产生别人无法生成的文件,形成数字签名;数字签名能保证签名者不可否认;并保证数据自签发后到收到为止未作任何修改。
    现在可以喝庆功酒了吗?不!细心的朋友还能发现“最后一个”含糊不清的地方:在第2步,Alice怎样验证了Bob的公匙确实是“原配”而不是Eve篡改过的?
    PKI/CA架构——数字签名的全面解决方案
    在现实生活中,当你与公司签定劳动合同时,合同中每个被修改的地方和落款都要双方签字盖章,这是解决“不可否认”问题。上面已经讲过了。
    而与Alice验证Bob的公匙相类似,你为了验证公司的合法性,有必要让公司出示营业执照,这是解决“身份验证”问题,显然你并非是相信那张纸,相信的只是纸上的公章,或者说,相信的是有资格颁发这张纸的政府机关。
    自20世纪80年代以来,在现代电子商务日益兴起的背景下,怎样认证公匙成了一个迫切的问题,人们越来越有一种强烈的需求,希望像现实生活中那样,有一个大家都普遍信任、足够权威的组织或机构,来担当类似政府机关的角色,专门负责发放和管理证书,在这种形势下,一种全新的安全机制——公共密匙基础结构(Public Key Infrastructure,PKI)应运而生,它能为所有网络服务提供采用加密和数字签名等密码服务所必需的密匙和证书管理,从而解决电子交易中的四大根本问题。利用PKI可以方便地建立和维护一个可信的网络计算环境,并且不需要用户干预,完全后台进行,从而使得人们在这个无法直接相互面对的环境里,能够确认彼此的身份和所交换的信息。
    PKI体系包括证书认证中心(Certificate Authority,CA)、数字证书库、公匙备份库、恢复系统、证书作废系统、应用接口(API)等五大系统,其中CA是PKI安全体系的核心,因此这一体系又被称作PKI/CA架构。关于PKI的具体细节限于篇辐,不再赘述。
    CA是负责产生、分配并管理数字证书的可信赖的第三方权威机构。通常采用多层次的分级结构,上级CA负责签发和管理下级认证中心的证书,最下一级的认证中心直接面向最终用户。所有人都认可由它签字的公匙,这样大家都保留一份CA的公匙就可以了——得到CA的公匙很简单,因为它广泛提供认证服务;而假冒CA的公匙很困难,因为它的公匙人人都有。
    由CA所签发的数字证书中包括了证书持有人的公匙。
    事实证明,作为专门负责发放和管理证书的权威机构,CA是电子商务和电子政务发展的必然结果,也正是因为如此,草案中才专门针对认证机构的权利和义务进行了规定。
    Bob有两种方式获得由CA签名的证书:
    一、1、Bob离线时用公匙算法产生自己的公匙、私匙;2、在线将公匙及部分个人身份信息发给CA;3、CA将执行一些必要的步骤,以确信请求确实由Bob发出;4、CA颁发给Bob证书,该证书核心包含两大部份:Bob的个人信息和他的公匙(对应上面的DC和KB)为第一部份;CA将第一部份求出Hash值后再用CA的私匙对该Hash值加密(对应于上面的HA),作为第二部份;5、最后将两个部份封装为一个数据块。我们已经知道其实第二部份就是CA的数字签名,相当于CA在证书盖的公章,而整个数据块就是Bob的证书。这种情况一般是在公开的环境中。或者:
    二、Bob还可以直接向CA申请证书,通过提交相应的信息,由CA产生公私匙并签名后直接发放证书给Bob——不必担心私匙的问题,因为这种情况一般适用于企业内部,员工和企业的互信是这种方法的基础,并且这种证书也仅适用于企业内部,对外交易是无效的。
    Bob就可以用这张证书来证明自己的身份了。
    Alice的验证方法很简单:1、如用CA的公匙能正常解密证书,证明证书本身是合法的。2、Alice产生一个随机数,要求Bob用自己的私匙加密,由于Bob 证书中有他的公匙,Alice就可以用Bob的证书将该随机数解密,比较这两个随机数,相同则证书确属Bob所有,反之则假。
    这才真正解决了身份验证的问题——验证是双向的和全方位的!
    不难看出,建立以PKI/CA为基础的安全解决方案,无论是对企业纯管理的内部业务,还是对要产生电子交易行为的网上炒股、购物、远程教育、网上银行等电子商务、电子政务,都是一种安全可靠的选择。 
    数字签名——电子交易的全面解决方案
    综上所述,证书是一个经CA数字签名的包含公匙拥有者信息以及公匙的文件。事实上所有证书格式都是根据国际电信联盟制定的X.509规范制作的。一张标准的证书包括:版本号;唯一序列号;签名算法名称;CA名及其签名;有效期;证书持有者姓名;证书持有者公匙。
    以上我们通过对加密通信的分析,知道数字签名能既验证,又签名,其实它还只签名,不验证,作为公开声明使用。众所周知的是微软在W2K以上版本推出的,针对视窗系统支持的外设公布数字签名的举措;另外,IE安装好后第一次打开网页,如果网页上有FLASH动画,就会弹出一个窗口,说这个控件是Macromedia Inc公司签名发布的,而该公司又是经过某著名CA认证了的,是可以信任的,并且下面还有一个复选框,让你永远相信Macromedia  Inc公司的产品,以后再安装就不需要提示了。如果你同意,这一信息就记录在“右击IE图标→属性→内容→发行商”对话框中供查看和管理;大家还能通过“右击IE图标→属性→内容→证书”来看看证书到底是什么样子,你会发现,你居然有那么多的证书!双击其中一个,在“详细信息”选项卡中,可以看到公共密匙字符串。
    很多应用程序都配有加密狗,以前往往是打印串口盒的形式,而现在多采用USB的接口,这种应用是让数字证书只验证而不签名,那里面保存了程序的某个Hash值,程序启动的时候会调用它,与程序内部的计算结果相比较,完全相同才能进入系统;而我们开通网上银行或者网上炒股的时候的时候,客户端必然会生成私匙,并提示让你妥善保管,当我们以某个用户名上网交易的时候,系统会针对这一私匙进行验证,通过后才可能进行划转资金等操作,一旦有重装系统,或用户名变动等操作,私匙立即失效,从而确保用户安全。
    现在应该没人怀疑“CA+证书”这种身份验证方式了,但有人依然不屈不挠:最顶级CA的公匙又由谁来认证?
    先有蛋,还是先有鸡,这个问题恐怕只有全国人大开了会才能解决,说来有趣,按照目前技术上的机制:最顶级CA的证书是自签名的,说白了,就是自己封自己为大王,并且100年有效(可以在上述IE属性查看)!当然理论上的前提是一定要得到大家的认可。话说到这里,已经不是技术问题了。所以我们尽可稍安勿燥,静候全国人大正式发布《电子签名法》之后,一切就可“真相大白”了。
  • 相关阅读:
    Android 主题theme说明 摘记
    Android开发 去掉标题栏方法 摘记
    安卓项目五子棋代码详解(二)
    关于 ake sure class name exists, is public, and has an empty constructor that is public
    百度地图3.0实现图文并茂的覆盖物
    android onSaveInstanceState()及其配对方法。
    关于集成科大讯飞语音识别的 一个问题总结
    android 关于 webview 控制其它view的显示 以及更改view数据失败的问题总结
    C# 解析 json Newtonsoft果然强大,代码写的真好
    c#数据类型 与sql的对应关系 以及 取值范围
  • 原文地址:https://www.cnblogs.com/silva/p/283535.html
Copyright © 2011-2022 走看看