电子签章功能与实现.docx

上传人:b****7 文档编号:10430349 上传时间:2023-02-11 格式:DOCX 页数:16 大小:459.64KB
下载 相关 举报
电子签章功能与实现.docx_第1页
第1页 / 共16页
电子签章功能与实现.docx_第2页
第2页 / 共16页
电子签章功能与实现.docx_第3页
第3页 / 共16页
电子签章功能与实现.docx_第4页
第4页 / 共16页
电子签章功能与实现.docx_第5页
第5页 / 共16页
点击查看更多>>
下载资源
资源描述

电子签章功能与实现.docx

《电子签章功能与实现.docx》由会员分享,可在线阅读,更多相关《电子签章功能与实现.docx(16页珍藏版)》请在冰豆网上搜索。

电子签章功能与实现.docx

电子签章功能与实现

     电子签章系统可实现在电子文件(Word,Excel,CAD图纸,PDF,HTML-WEB页面,LotusNotes,TIF传真,XML数据,FORM表单,WPS,GDFTM版式文件等)上实现手写电子签名和加盖电子印章,并可将签章和文件绑定在一起,通过密码验证、签名验证、数字证书确保文档防伪造、防篡改、防抵赖,安全可靠。

它具有制章的唯一性、不变造、伪造,签章的真实性,文档完整性、真实性、不可篡改,验章的真实性、有效性。

电子签章系统可以通过辨识电子文件签署者的身份,确保文件的真实性、完整性和不可抵赖性。

       JSCA电子签章结合成熟的组件技术、PKI技术、图像处理技术以及智能卡技术,按照一系列的标准体系,以电子形式对电子文档签名并加盖签章。

       软件采用COM组件技术,将传统印章与电子签名技术完美结合,通过签章可以确认文档来源、确保文档的完整性、防止对文档XX的篡改以及确保签名行为的不可否认。

 

1.电子签章是什么?

 

  在传统的书面信息传递环境中,信息安全的保障为当事人的签字、盖章,电子签章制度则是在虚拟的网络环境中的信息安全保障,电子签章类似传统的“印章”。

 

  从技术上讲,电子签章,泛指所有以电子形式存在,依附在电子文件并与其逻辑关联,可用以辨识电子文件签署者身份,保证文件的完整性,并表示签署者确认电子文件所陈述事实的内容。

从广义上讲,电子签章不仅包括我们通常意义上讲的“非对称性密钥加密”,也包括笔迹辨别、指纹识别,以及新近出现的眼虹膜透视辨别、面纹识别、DNA识别等。

目前,最成熟的电子签章技术就是“数字签章”,它是以公钥及密钥的“非对称型”密码技术制作的电子签章。

我们通常所说的电子签章也是指数字签章。

 

  数字签章是运用一种名为“非对称密码系统”(Asymmetric Cryptography)的技术来对发文者的电子文件作加、解密运算,其目的是使收文者可确定电子文件的发出者是谁、该电子文件在传输中未遭篡改并保证发文者不能否认其发文的行为。

有了这个保障,通过网络传播的信息就可以说是真实可信的了。

 

  2.CA认证机构:

“刻印章的店” 

  如果把数字签章比喻为“印章”,那么CA认证机构实际上就是“刻印章的店”。

 

  为了确保用户及他所持有密钥的正确性,公共密钥系统需要一个公正的、值得信赖而且独立的第三方机构充当认证中心,来确认声称拥有公共密钥的人的真正身份,认证机构(Certification Authority,简称CA)遂因此而生。

 

  要确认一个公共密钥,CA首先制作一张“数字证书”,它包含用户身份的部分信息及用户所持有的公共密钥,然后CA利用其本身的密钥为数字证书加上数字签名。

CA认证机构功能是产生及保管各人的密钥,以供随时认证,当网络交易发生争议或纠纷时,认证机构作为公正第三方,提供认证资料做为裁决的依据。

 

  如同目前刻公章需要到公安机关备案一样,数字签章的发文者亦需要先向CA登记其公钥,再由CA签发数字证书。

数字证书上所记录的是与私钥相对应的公钥。

发文者以数字签章签署于电子文件后,可将电子文件并同数字证书一起传送给收文者,收文者即可利用数字证书上所载的公钥验证数字签章的真实性与文件的完整性,而收文者只要能确认该凭证确实为CA所签发(收文者也可取得CA的公钥以验证CA数字证书上所签署的数字签章的真实性),便可确信数字证书内的公钥确为凭证所指之人所有。

本文将探讨数字签名、数字证书、强签名程序集、反编译等以及它们在.NET中的运用(一些概念并不局限于.NET在其它技术、平台中也存在)。

1.数字签名

数字签名又称为公钥数字签名,或者电子签章等,它借助公钥加密技术实现。

数字签名技术主要涉及公钥、私钥、非对称加密算法。

1.1公钥与私钥

公钥是公开的钥匙,私钥则是与公钥匹配的严格保护的私有密钥;私钥加密的信息只有公钥可以解开,反之亦然。

在VisualStudio中,可以在项目属性页或者通过强命名工具Sn.exe生成公钥与私钥对,参考创建公钥私钥对。

1.2非对称加密算法

非对称加密算法(也叫公钥加密算法)借助于私钥加密、公钥解密,使用了两个不同的密钥,因此被称为非对称加密;数字签名属于非对称加密算法的一种。

比较著名的非对称加密算法是RSA,在.NET中对应的类为RSACryptoServiceProvider类,参看。

数字加密算法包括密码生成算法、密码标记算法、验证算法。

NET中的RSACryptoServiceProvider类包含这些相应的方法。

1.3数字签名过程

消息的发送者用一个HASH函数提取出消息的摘要,然后用私钥借助非对称加密算法对消息进行加密,将消息原文与加密后的数字签名同时发送给接受者;消息接受者收到消息原文与数字签名后,首先利用同一HASH函数从消息原文提取消息摘要,再用发送者发布的公钥对数字签名进行解密出发送者的消息摘要,对比消息摘要,如果一致则证明,此消息来自发送者,且内容未经修改。

对于RSA算法,解密与解密分别对应:

Encrypt与Decrypt方法。

1.4数字签名的功能

确定消息确实是由发送方签名并发出来的,因为私钥是私有的,其他人假冒不了发送方的签名。

二是数字签名能确定消息的完整性。

因为数字签名的特点是它代表了消息的特征,消息如果发生改变,HASH函数得到的消息摘要就会不同,数字签名的值也将发生变化,因而不同的消息将得到不同的数字签名。

2.数字证书

数字证书亦称电子证书,它是在Internet上用来标志和证明网络通信双方身份的数字信息文件。

它是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。

最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。

授权中心的数字签名可以帮助我们从授权中心验证证书是否被更改,即身份信息是否被更改等。

简言之它就如同我们的身份证。

数字证书可以保证信息除发送方和接收方外不被其它人窃取;信息在传输过程中不被篡改;发送方能够通过数字证书来确认接收方的身份;发送方对于自己的信息不能抵赖。

数字证书广泛运用于服务器证书,如SSL证书,电子邮件证书,客户端证书等等。

理论上任何人都可以给你发个数字证书,亦即是说给你发数字证书的那个人或机构对你的公钥进行加签。

对PGP和GPG系统来说,就是如此,而不需要一个统一的身份认证机构。

但我们一般仅信任权威的数字认证机构颁发的证书。

在InternetProperties->内容->证书可以查看已经安装在本机的证书:

 

分析数字签名如何进行发送者的身份认证

首先对发送消息进行hash摘要,然后用自己的私钥对hash摘要加密,将加密后的内容+原始消息一并发送给接受方。

接受方收到内容后,用发送者的公钥解密加密后的hash摘要,得到hash摘要的明文,再将发送过来的原始消息使用相同的hash算法,求得hash摘要。

将求得的hash摘要与解密得到的hash摘要进行匹配,若一样,则证明是发送者发送的,否则,不是发送者发送的。

上图选中项为阿里巴巴的证书的公钥。

3.强签名程序集

3.1强签名程序集简介

强名称是由程序集的标识加上公钥和数字签名组成的。

其中,程序集的标识包括简单文本名称、版本号和区域性信息(如果提供的话)。

强名称是使用相应的私钥,通过程序集文件(包含程序集清单的文件,并因而也包含构成该程序集的所有文件的名称和散列)生成的。

Microsoft®VisualStudio®.NET和在.NETFrameworkSDK中提供的其他开发工具能够将强名称分配给一个程序集。

强名称相同的程序集应该是相同的。

3.2强名称程序集的功能

强名称依赖于唯一的密钥对来确保名称的唯一性,只有强名称的程序集可以加入到GAC中;强名称保护程序集的版本沿袭;强名称提供可靠的完整性检查。

强名称就如同证书一样,帮助两个程序集之间建立信任关系。

3.3强名称程序集的实现方案

请参看:

强名称方案

ClickOnce应用程序的强名称签名

对应用程序和部署清单进行签名

对程序集进行签名

3.4延迟程序集签名

为程序集签名时,您可能不会始终具有对私钥的访问权限。

在这种情况下,可以使用“延迟签名”或“部分签名”来提供公钥,从而将私钥的添加推迟到交付程序集时。

参考。

4.强签名程序集实践

4.1新建测试项目StrongNameAssembly,为其添加一个类TestClass:

namespaceStrongNameAssembly

{

   publicclassTestClass

   {

   }

}

4.2在项目属性的签名选项卡设置强签名:

 生成项目后,用.NETReflector打开程序集,我们可以发现,程序集的的名称包含了公钥标志:

//AssemblyStrongNameAssembly,Version1.0.0.0

Location:

D:

\Raymond'sDocuments\VisualStudio2005\Projects\StrongNameAssembly\StrongNameAssembly\bin\Debug\StrongNameAssembly.dll

Name:

StrongNameAssembly,Version=1.0.0.0,Culture=neutral,PublicKeyToken=79dbc45bc8054239

Type:

Library

如果不进行强签名,那么公钥标志为null。

4.3新建测试项目ConsoleApplication1

添加对StrongNameAssembly的引用,并且更改Program.cs内容为:

usingSystem;

usingSystem.Collections.Generic;

usingSystem.Text;

namespaceConsoleApplication1

{

   classProgram

   {

       staticvoidMain(string[]args)

       {

           Console.Write(newStrongNameAssembly.TestClass().ToString());

           Console.ReadLine();

       }

   }

}

生成解决方案,用Reflector打开控制台应用程序,查看其Reference中包含了对StrongNameAssembly的完整引用:

//AssemblyReferenceStrongNameAssembly

Version:

1.0.0.0

Name:

StrongNameAssembly,Version=1.0.0.0,Culture=neutral,PublicKeyToken=79dbc45bc8054239

 运行解决方案:

4.4更改强签名程序集的密钥为新的签名密钥或者取消强签名而不改变ConsoleApplication1

随意修改了强签名的密钥,查看到公钥标识变为

//AssemblyStrongNameAssembly,Version1.0.0.0

Location:

D:

\Raymond'sDocuments\VisualStudio2005\Projects\StrongNameAssembly\StrongNameAssembly\bin\Debug\StrongNameAssembly.dll

Name:

StrongNameAssembly,Version=1.0.0.0,Culture=neutral,PublicKeyToken=b03b8e071332d29f

Type:

Library

 直接将程序集复制到ConsoleApplication1运行目录下,如Debug目录下,运行会得到错误提示,未能加载程序集trongNameAssembly,Version=1.0.0.0,Culture=neutral,PublicKeyToken=79dbc45bc8054239。

4.5修改ConsoleApplication1.exe的应用程序清单

用Reflector或者ILDASM可以查看到ConsoleApplication1.exe的清单Manifest中,引用StrongNameAssembly的公钥标识依然为之前的版本公钥标识:

.assemblyexternStrongNameAssembly

{

.ver1:

0:

0:

0

.publickeytoken=(79DBC45BC8054239)

}

如果我们修改此标识为新的密钥签名的公钥标识(b03b8e071332d29f)会是怎样呢?

用ILDASM打开ConsoleApplication1.exe,转储为.il文件,用记事本打开:

红色框注部分则为需要修改的地方,修改为:

.assemblyextern/*23000002*/StrongNameAssembly

{

 .publickeytoken=(b03b8e071332d29f)                        //y..[..B9

 .ver1:

0:

0:

0

}

保存,并且用重新编译为应用程序(参考MSIL汇编程序):

 ilasm/resource=ConsoleApplication1.resConsoleApplication1.IL/exe

@pause

如上图编译成功。

运行也成功:

在Reflector中也可以看到修改后的引用:

//AssemblyReferenceStrongNameAssembly

Version:

1.0.0.0

Name:

StrongNameAssembly,Version=1.0.0.0,Culture=neutral,PublicKeyToken=b03b8e071332d29f

由此可以看到,通过强名称对应用程序集进行保护是很脆弱的,或者说没有太大的用途;往往我们还需要借助代码混淆来实现源码保护,而此话题不在本文讨论范围之内。

5.几点补充

在强命名方案一文中,有提到开发环境或工具使用开发人员私钥对包含程序集清单的文件哈希签名。

该数字签名存储在包含程序集的清单的可移植可执行(PE)文件中。

这一点通过ILDASM可以查看其公钥、HASH算法、以及公钥标志:

.assemblyexternmscorlib

{

 .publickeytoken=(B77A5C561934E089)                        //.z\V.4..

 .ver2:

0:

0:

0

}

.publickey=(00240000048000009400000006020000  //.$..............

               00240000525341310004000001000100  //.$..RSA1........

               63AE3B85F42294FF18F87C9D4F7479CA  //c.;.."....|.Oty.

               213278FACD10E7F368D80097C4CF4DF8  //!

2x.....h.....M.

               E1002DE855B551E8BA91829D3EDA618A  //..-.U.Q.....>.a.

               7B4EA0FB2D1FBF5F7D179AA13AA42CF7  //{N..-.._}...:

.,.

               30FABC73ED39B164B91574E725898DB8  //0..s.9.d..t.%...

               0794C578E52C22C6A28DD2644D2B18B2  //...x.,"....dM+..

               392618DE33718EB587C159E52F83A08C  //9&..3q....Y./...

               A5EFB9FC8312D80A1D6A91BD3D811FD3)//.........j..=...

 .hashalgorithm0x00008004

 .ver1:

0:

0:

0

而以上代码为IL格式即为EXE或者DLL格式的PE文件反编译为IL后的内容,它需要在我们的.NET环境CLR中才可以被解释执行;在其CLRHeader中也定义了.NET的版本:

//-----CLRHeader:

//Headersize:

                       0x00000048

//Majorruntimeversion:

             0x0002

//Minorruntimeversion:

             0x0005

//0x00002074[0x00000558]address[size]ofMetadataDirectory:

       

//Flags:

                             0x00000001

//Entrypointtoken:

                 0x06000001

//0x00000000[0x00000000]address[size]ofResourcesDirectory:

      

//0x00000000[0x00000000]address[size]ofStrongNameSignature:

    

//0x00000000[0x00000000]address[size]ofCodeManagerTable:

        

//0x00000000[0x00000000]address[size]ofVTableFixupsDirectory:

   

//0x00000000[0x00000000]address[size]ofExportAddressTable:

     

//0x00000000[0x00000000]address[size]ofPrecompileHeader:

   

关于.NETPE结构请参考The.NETFileFormat,本文不涉及此内容。

 

数字摘要MD5与数字签名RSA简要原理

2009-05-1210:

03:

41|  分类:

技术|  标签:

|字号大中小 订阅

        数字签名是一种给以电子形式存储的消息签名的方法。

通过这种方法签名之后的消息可以通过网络传输。

数字签名基于非对称密钥加密算法,如DSA/RSA算法。

从公钥系统可以立即取得的一个好处是解决了密钥的管理问题,公钥系统中的一个新成员仅需要一张公开密钥表的拷贝,并把他选择的加密密钥公布给大家就可以了。

而在许多应用中给发送的消息附上一个数字签名的能力,则是公钥系统更加重要的好处。

数字签名的原理如图所示:

图中m表示明文。

        发送者首先用自己的私有密钥对消息m进行编码,产生了中间的密码电文cl。

这一步对m未提供任何保护,只不过印上了发送者本人所特有的标记而已(因为用的是只有他本人才知道的属于他本人解密使用的私有密钥)。

接着再来第二次的加密,这次使用接收者的公开密钥,以产生密码电文c2,它可在开放的通信信道上予以传送。

接收者收到c2后,先使用他的私有密钥对此消息解密,这和通常的处理过程是一样的,但所得到的结果不是m而是c1,所以还得再用发送者的公开密钥来解密,这样就得到了原来的消息m。

        一般而言,所谓的m不应该是所需传递的完整信息,而只是完整信息的一个摘要。

这里要涉及到一个MD5数字摘要算法。

MD5数字摘要是目前最流行的一个数字摘要算法,通过一定的运算,将不等长度的数据加密成一个固定长度的数值,该数值就是此信息的摘要。

数字信息的摘要再加上公钥系统,就形成一个完整的数字签名体系。

        MD5(全称:

messagedigestalgorithm5)算法是麻省理工学院(MIT)计算机科学实验室的R.Rvest于上个世纪90年代提出来的,它被互联网电子邮件保密协议(PEM)指定为消息压缩值算法(MessageDigestAgorithm)之一,用于数字签名前对消息进行安全的压缩(securehashing)。

该算法可以将任意长度的消息压缩为128比特,然后再进行数字签名。

在最初的几年里,MD5被认为是安全的,因为当时还没有可行的方法在有效的时间内计算出两个有相同压缩值的消息,或在有效时间内计算出某个具有给定压缩值的消息。

      MD5的典型应用是对一段Message(字符串)产生Fingerprint(指纹),以防止被“篡改”。

举个例子,你将一段话写在一个叫readme.txt文件中,并对这个readme.txt产生一个MD5的值并记录在案,然后你可以传播这个文件给别人,别人如果修改了文件中的任何内容,你对这个文件重新计算MD5值时就会发现它被修改过。

如果再有一个第三方的认证机构,用MD5还可以防止文件作者的“抵赖”,这就是所谓的数字签名的应用。

       这个过程中重要的是发送者的签名防止了冒充和否认!

这是因为在第一步中建立起来的cl是一个用发送者的私有密钥编码的签名消息。

任何第三方,如果他不知道发送者的私有密钥,他就不可能伪造声称由发送者发送的消息。

如果他使用别的密钥,则在最后再解密的阶段将不能工作。

同样,发送者也无法在事后否认他发送了消息m。

因为,一个消息若能成功地使用发送者的公开密钥来译解,则原来就必然是用发送者的私有密钥编码的。

许多公钥算法都可以用于数字签名。

实际用得最广泛的算法是美国国家技术标准局(NlsT)在1991年提出的数字签名算法DSA(DigitalsignatureAlgorithm)。

工作原理

  1.A要向B发送信息,A和B都要产生一对用于加密和解密的公钥和私钥。

  2.A的私钥保密,A的公钥告诉B;B的私钥保密,B的公钥告诉A。

  3.A要给B发送信息时,A

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 军事

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1