C毕业设计——基于C+Tuxedo+Mysql的数字签名在Tuxedo中间件中的运用设计与实现（毕业论文+程序源码）——数字签名

基于C+Tuxedo+Mysql的数字签名在Tuxedo中间件中的运用设计与实现（毕业论文+程序源码）

大家好，今天给大家介绍基于C+Tuxedo+Mysql的数字签名在Tuxedo中间件中的运用设计与实现，文章末尾附有本毕业设计的论文和源码下载地址哦。需要下载开题报告PPT模板及论文答辩PPT模板等的小伙伴，可以进入我的博客主页查看左侧最下面栏目中的自助下载方法哦

文章目录：

1、项目简介

1. 目前Internet是主要的通讯网络，对于我们通过其传输的信息都需要进行加密与认证来确保信息的安全性和唯一性。

2. 数字签名技术是目前主要的加密与认证手段。结合数字签名技术对Tuxedo进行安全性上的保障显得十分有必要。

3. 基于开源的OpenSSL对我们的Tuxedo应用进行设计加密方案，显的十分有必要。不仅保护了我们的程序的安全性，同时OpenSSL也是一款自由软件，我们不需要额外支付任何费用。
   企业内部大部分服务器使用的操作系统是Unix系统，所以我们讲在Unix系统上进行一个案例的设计。对不同安全性级别要求的程序与信息进行设计与开发。

---

2、资源详情

项目难度：中等难度
适用场景：相关题目的毕业设计
配套论文字数：12621个字24页
包含内容：全套源码+配整论文
开题报告、论文答辩、课题报告等ppt模板推荐下载方式：

---

3、关键词

Tuxedo OpenSSL Gtk 中间件 数字签名

---

4、毕设简介

提示：以下为毕业论文的简略介绍，项目完整源码及完整毕业论文下载地址见文末。

第一章 绪论
1.1数字签名对于Tuxedo的意义
1.1.1Tuxedo运用的领域特点
中间件产品TUXEDO的特点
分布式交易治理：BEATuxedo使客户机和服务器可参与涉及多个数据库协调更新的分布式交易。并确保所有数据库的 正确更新或恢复到初始状态，从而在任何组件出现故障时均能保证数据的完整性；

高可用性：BEATuxedo的一个主要性能是保证对系统组件进行持续的监 视，查看应用系统、交易、网络及硬件是否出现故障。一旦出现故障，BEATuxedo会从逻辑上把故障组件从系统中排除，治理必要的恢复程序并重新为消息 和交易选择路由，以使系统继续运行。对于最终用户而言，所有这些都是完全透明的，且不需要中断服务；

动态负载均衡：BEATuxedo可以根据系统的负 载指示，自动开启和关闭应用服务，以满足对应用系统的高强度使用需求。同时还可以均衡所有可用系统的负载，以确保无论服务是在同一个节点还是分布在节点之 间系统都能被平均使用资源，达到负载均衡；

数据依靠路由：BEATuxedo可按照消息的传输的关键路由信息来选择消息路由。这样就能够实现交易的高效 处理，并发挥最佳性能；
安全性：BEATuxedo支持加密，当跨网络部署BEATuxedo应用系统时，这些安全性机制可确保用户数据的保密性。 Tuxedo还提供了插件程序机制，支持公共密钥和数字签名，以及连接应用系统的非BEA安全产品，保证了系统的安全性。
应用系统并行化：BEATuxedo通过动态复制整个网络中的分布式应用系统，可使电子商务应用系统发挥最佳性能。同时Tuxedo答应应用系统并行处理请求，并发处理位于不同分布式节点上的业务请求，提高开发效率。

提供ApplicationToTransactionManagerInterface— ATMI：BEATUXEDO提供的ATMI支持为50多种硬件平台和操作系统提供了一致的应用编程接口。ATMI让开发人员不用考虑程序所在的硬件环 境，直接编写BEATuxedo应用系统。3中间件产品TUXEDO开发TUXEDO应用开发主要包括到客户端程序、服务端程序的开发。 BEATuxedo提供了一个其于C语言的编程接口，即应用程序事务监控接口ATMI，以便用于开发客户程序和服务程序。除了C语言接口 外，BEATuxedo还提供了COBOL接口。在BeaTuxedo系统中的客户端到服务端的通信过程都是通过类型缓冲区来完成的，BeaTuxedo 系统提供了大量的类型缓冲区来供使用。所有类型缓冲区都必须通过BeaTuxedo的tpalloc，tprealloc，tpfree这些公共ATMI 来分配回收。

中间件产品TUXEDO的主要应用行业
银行金融业：银行网点的终端机通过Tuxedo处理客户帐务活动。而Tuxedo三层CS架构，使得客户终端机程序不必要拥有业务逻辑，将业务逻辑抽离在了Tuxedo中，使得部署、升级变得容易。Tuxedo优秀的集群负责控制，日志控制，灾难恢复及安全性也使得大量商业银行成为了Tuxedo的主要用户。
电信通讯业：比如中国电信也是Tuxedo的主要用户。中国电信的主要SP接口都是使用的Tuxedo的作为底层系统的。C语言开发使得整个系统的性能大大提高，而与客户端语言无关的特点也使得，第三方开发商可以很轻易的使用中国电信提供的服务接口进行自己业务的拓展。

1.2研究内容及目的
1.2.1研究背景
随着大型企业管理软件的发展，其应用越来越广泛，企业数据平台涉及局域网、广域网、Internet等，在各类系统中保存的企业关键数据量也越来越大，许多数据需要保存数十年以上，甚至是永久性保存。于是关键业务数据成了企业生存的命脉和宝贵的资源，数据安全性问题越来越突出。如何增强企业软件系统的安全性、保密性、真实性、完整性，成为每一位软件开发人员关注的焦点。
　　为了解决关键业务的数据安全问题，首先对数据系统进行全面、可靠、安全和多层次的备份是必不可少的，除此以外，各种安全产品，无论防火墙、防病毒、防黑客、防入侵等等，都或多或少地肩负着一些保护数据的责任。从保护数据的角度讲，对数据安全这个广义概念，可以细分为三部分：数据加密、数据传输安全和身份认证管理。
　　数据加密就是按照确定的密码算法将敏感的明文数据变换成难以识别的密文数据，通过使用不同的密钥，可用同一加密算法将同一明文加密成不同的密文。当需要时，可使用密钥将密文数据还原成明文数据，称为解密。这样就可以实现数据的保密性。数据加密被公认为是保护数据传输安全惟一实用的方法和保护存储数据安全的有效方法，它是数据保护在技术上最重要的防线。
数据传输安全是指数据在传输过程中必须要确保数据的安全性，完整性和不可篡改性。

1.2.2研究目的
通过使用Tuxedo中间件，构建一个基于Linux系统的的银行帐户管理系统基础模型。客户端与服务端通讯时对部分机密的字段可以进行加密处理、数字签名防止被第三方窃听。
银行帐户管理系统使用CS架构进行实现，同时也对BS的拓展留有部分设计的余地。
系统环境为Linux Ubuntu804发行版，数据库为Mysql 5.0,BEA Tuxedo版本为9.0、开发许可证类型为试用型。
1.2.3研究内容
银行帐户系统的基础业务及其需求分析
基础Tuxedo的三层应用程序设计
Tuxedo中间系统与数据库系统的通讯
基于C语言的数字签名的部分算法
使用Tuxedo-ATMI构建帐务系统服务端程序
使用GTK-GNOME构建帐务系统的客户端程序
使用数字签名技术使客户端与服务端程序的通讯进行加密
基于Tuxedo的CS架构系统如何扩展成BS系统
操作系统
根据Tuxedo的主要运用行业的特点，其部署环境多为Unix系统。因Unix的特殊性，故使用Linux系统作为服务端操作系统环境。
数据库系统
在企业中Oracle为主要的数据库系统，但由于费用及版权问题，故使用同样拥有C语言API的Mysql系统作为替换。
案例场景
服务器端为银行数据中心网络，客户端为一般网络，两者使用internet互相通讯。

第二章 Tuxedo与数字签名基础介绍
2.1中间件服务器简介
2.1.1Tuxedo中间件在C/S架构体系中的作用
介于客户机与服务器之间的夹层，它突破了二层C/S结构的局限性，为构建大规模、高性能、分布式C/S应用程序提供了通信、事务、安全、容错等基础服务，它屏蔽了底层技术细节，使应用程序开发不必再从底层做起，以自身的复杂性换来了应用程序开发的简单。

图2.1 传统CS两层体系

传统的两层CS体系体系中，由客户端直接连接服务器，每次一次操作都要获取一个连接，操作结束后又要负责关闭连接。客户端可以直接感知到数据库服务器的地址与端口。无论在服务器的负载上，还是安全上都有所缺失。

图2.2 Tuxedo在三层CS架构中

由图1.2可见，在CS三层体系中，在客户端与数据库服务中增加了中间件服务器（Tuxedo）这一层。Tuxedo服务器变成两者通讯的中间人——负责转发处理客户端对数据库服务器的请求。中间件一次便由此而来。
使用Tuxedo中间件的三层CS架构有以下几点好处：
在负载方面，获取连接的操作又中间件服务器统一管理成一个数据库连接池。和数据库的通讯也又中间件服务器代为发起。企业应用中最大连接数的瓶颈被中间件服务器轻易解决。
在开发方面，可以将大量的业务逻辑代码冲客户端中抽离出来放置在中间件服务器上进行处理。大大简化了开发客户端的难度。而服务端的程序员也可以专注于业务数据、业务逻辑上而不专注于客户端对于数据的呈现方式。
在安全方面，客户端程序是与中间件服务器通讯，从而感知不到数据库服务器的地址与端口。
在维护方面，本来在客户端中处理的业务逻辑可以被抽离至中间件服务器上的服务端程序行，从而减少了每一次更新需要全部更新客户端的弊端。
在客户端多样化方面，只要可以兼容Tuxedo的通讯协议便可以调用服务。将业务做成了一个与语言无关的服务平台。方便二次开发时的调用。

2.2 数字签名简介
2.2.1数字签名概念
所谓"数字签名"就是通过某种密码运算生成一系列符号及代码组成电子密码进行签名，来 代替书写签名或印章，对于这种电子式的签名还可进行技术验证，其验证的准确度是一般手工签名和图章的验证而无法比拟的。"数字签名"是目前电子商务、电子 政务中应用最普遍、技术最成熟的、可操作性最强的一种电子签名方法。它采用了规范化的程序和科学化的方法，用于鉴定签名人的身份以及对一项电子数据内容的 认可。它还能验证出文件的原文在传输过程中有无变动，确保传输电子文件的完整性、真实性和不可抵赖性
2.2.2数字签名标准
数字签名在ISO7498-2标准中定义为：“附加在数据单元上的一些数据，或是对数据单元所作的密码变换，这种数据和变换允许数据单元的接收者用以确认 数据单元来源和数据单元的完整性，并保护数据，防止被人（例如接收者）进行伪造”。美国电子签名标准（DSS，FIPS186-2）对数字签名作了如下解 释：“利用一套规则和一个参数对数据计算所得的结果，用此结果能够确认签名者的身份和数据的完整性”。按上述定义PKI（Public Key Infrastructino 公钥基础设施）提供可以提供数据单元的密码变换，并能使接收者判断数据来源及对数据进行验证。
2.2.3关于PKI-CA
PKI的核心执行机构是电子认证服务提供者，即通称为认证机CA（Certificate Authority），PKI签名的核心元素是由CA 签发的数字证书。它所提供的PKI服务就是认证、数据完整性、数据保密性和不可否认性。它的作法就是 利用证书公钥和与之对应的私钥进行加/解密，并产生对数字电文的签名及验证签名。数字签名是利用公钥密码技术和其他密码算法生成一系列符号及代码组成电子 密码进行签名，来代替书写签名和印章；这种电子式的签名还可进行技术验证，其验证的准确度是在物理世界中对手工签名和图章的验证是无法比拟的。这种签名方 法可在很大的可信PKI域人群中进行认证，或在多个可信的PKI域中进行交叉认证，它特别适用于互联网和广域网上的安全认证和传输。

第三章 Tuxedo的安全模型
3.1 Tuxedo中的安全性
3.1.1可信域与非可信域

图3.1通过Internet通讯网络模型

如今网络化已经成为了当今社会的共识。客户端程序往往和服务器端程序不同在一个网络之中。
在服务端网络中，由于我们可以对网络的进入进行控制，并部署安全策略，部署硬件级软件级防火墙。则在服务端网络的网络域中安全性可以通过保证。则我们可以认为是一个“可信域”，在域中的通讯都不会被第三方窃听，篡改。则在域名中的通讯报文我们都可以选择对其不进行加密解密。
而客户端网络在某些特定的情况下，我们也能够构成一个安全域，但大多数情况下客户端的网络安全状况并不是软件开发、维护者可以保证的。所以对客户端网络中传输的报文需要进行一定加密。而客户端接收的数据需要进行解密。
联系客户端网络与服务器端网络通常都是Internet，而Internet网络安全控制是非常不可控的。我们无法百分之百的屏蔽、阻挡第三方用户进入Internet，而从通过Internet传输的报文都是有被第三方窃听、篡改的危险的。则Internet网络域可以认为是一个“不可信域”。通过该域的报文都有加密的必要。

3.2.1 Tuxedo加密传输模型分析
一般情况下，一个利用Internet通讯的Tuxedo应用通讯模型为下图：

图3.2 Tuxedo加密传输模型
在可信网络域中，Tuxedo应用服务器与数据库服务器通讯是整个系统的核心，在更短的时间内处理更多的交易是所有系统追求的。所以额外的进行加密解密势必影响整个系统的性能。而由于在可信网络域中，我们可以认为所有的通讯都是安全的，所以我们在域中的通讯不需要进行额外的加密操作。
Tuxedo服务器在进行数据库服务器进行了完了操作，对数据进行了业务逻辑上的加工，并准备将报文发出到一个非可信网络域中、通常这个非可信域就是指Internet，而我们无法保证数据报文在非可信域中的安全，所以我们需要对报文进行加密并将密文进行传输。
加密后的报文经过非可信网络域，达到客户端。客户端因为拥有解密协议，所以可以正确的解析出明文，并进行操作。
客户端产生新的请求报文，因为报文需要经过一个非可信网络域，所以对其使用与服务端约定的加密协议对报文进行加密。并将加密后的密文进行传输。
客户端传来的密文请求，到达服务端后，Tuxedo应用服务器使用约定的解密协议进行解密，并进行相应的操作。

3.2 加密方案
3.2.1 对称加密
　　　对称加密算法是应用较早的加密算法，技术成熟。在对称加密算法中，数据发信方将明文（原始数据）和加密密钥一起经过特殊加密算法处理后，使其变成复杂的加密密文发送出去。收信方收到密文后，若想解读原文，则需要使用加密用过的密钥及相同算法的逆算法对密文进行解密，才能使其恢复成可读明文。在对称加密算法中，使用的密钥只有一个，发收信双方都使用这个密钥对数据进行加密和解密，这就要求解密方事先必须知道加密密钥。对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。此外，每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量成几何级数增长，密钥管理成为用户的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。在计算机专网系统中广泛使用的对称加密算法有DES、IDEA和AES。
　　传统的DES由于只有56位的密钥，因此已经不适应当今分布式开放网络对数据加密安全性的要求。1997年RSA数据安全公司发起了一项“DES挑战赛”的活动，志愿者四次分别用四个月、41天、56个小时和22个小时破解了其用56位密钥DES算法加密的密文。即DES加密算法在计算机速度提升后的今天被认为是不安全的。
　　AES是美国联邦政府采用的商业及政府数据加密标准，预计将在未来几十年里代替DES在各个领域中得到广泛应用。AES提供128位密钥，因此，128位AES的加密强度是56位DES加密强度的1021倍还多。假设可以制造一部可以在1秒内破解DES密码的机器，那么使用这台机器破解一个128位AES密码需要大约149亿万年的时间。（更深一步比较而言，宇宙一般被认为存在了还不到200亿年）因此可以预计，美国国家标准局倡导的AES即将作为新标准取代DES。

图3.3对称加密模型
3.2.2 非对称加密
不对称加密算法使用两把完全不同但又是完全匹配的一对钥匙—公钥和私钥。在使用不对称加密算法加密文件时，只有使用匹配的一对公钥和私钥，才能完成对明文的加密和解密过程。加密明文时采用公钥加密，解密密文时使用私钥才能完成，而且发信方（加密者）知道收信方的公钥，只有收信方（解密者）才是唯一知道自己私钥的人。不对称加密算法的基本原理是，如果发信方想发送只有收信方才能解读的加密信息，发信方必须首先知道收信方的公钥，然后利用收信方的公钥来加密原文；收信方收到加密密文后，使用自己的私钥才能解密密文。显然，采用不对称加密算法，收发信双方在通信之前，收信方必须将自己早已随机生成的公钥送给发信方，而自己保留私钥。由于不对称算法拥有两个密钥，因而特别适用于分布式系统中的数据加密。广泛应用的不对称加密算法有RSA算法和美国国家标准局提出的DSA。以不对称加密算法为基础的加密技术应用非常广泛。

图3.4非对称加密模型

第四章 基于Tuxedo与数字签名技术的程序案例设计
4.1案例分析
4.4.1案例介绍
银行的帐务系统属于典型的使用Tuxedo的客户端与服务端跨过一个不可信网络域的案例。
我们将对其进行分析并对几种加密传输方案以及架构方案提出问题并解答。

4.4.2业务分析

图2.5账户自助系统用例图

我们的柜员（客户端）可以通过登录“账户自主系统”查询指定账户的相关信息，比如用户的姓名，证件号、地址、账户金额等；给指定的账户客户办理存款业务、办理取款业务。
在操作中，需要安全性、可靠性是最主要的评测指标。在对诸如设计金钱的操作的时候，我们需要对操作人员的身份进行验证。对于登录系统报文则更需要进行加密操作，数据库中的敏感字段也需要进行不可逆的加密工作。
4.4.3系统架构模型
一般而已，银行业务都有一个BOSS核心系统来连接数据库服务器，但是为了研究方便我们简单的过滤掉这层，让我们的Tuxedo应用服务器直接使用数据库服务器。主要情况为客户端程序直接与Tuxedo应用服务器通讯，使用的Tuxedo自带的FML32传输协议。同时也对使用Socket进行通讯的模型进行进一步扩展分析。
Tuxedo应用服务器使用数据库的API对其进行SQL操作，新增、更新、删除、查找数据库中的信息、数据。负责组织主要的业务逻辑，比如通过验证登录名与密码、查找相应的帐号信息、存款、取款、记录日志等业务。并将回复信息以FML32传输协议发回给客户端。
客户端程序负责主要的对FML32中 数据进行图形界面化的显示，以及控制客户的输入输出的响应，对服务器的数据请求等功能。
如今BS架构已经成为企业级开发的主要架构模式，当然我们也可以通过改造原先的CS三层架构应适配成BS架构。比如我们可以使用Tuxedo中自带对Corba良好的支持，直接使用CorbaClinet将在架构之中多增加一个从Tuxedo-FML32到Corba-IDL协议的转换，利用Corba平台与客户端无言无关、对主流BS架构开发语言Java良好的支持等特性进行二次开发。
我们也可是使用最底层的Socket将Tuxedo-FML32协议转换为Socket流进行通讯。此方法在于建立一个从FML32到Stream的桥应用，虽然这样的适用面非常广：几乎所有的web开发语言、注入PHP、Java、C#没有不支持Socket编程的。但是socket属于比较低级的应用开发，需要对协议报文进行非常严格的约定。

图4.1账户自助系统架构预想图
4.2详细设计及分析
4.2.1安全性分析
系统登录操作
登录是整个应用的最主要入口，通常来说，一个登录对话框主要包括“用户名”和“密码”两个字段。然后进行验证。
一般流程，我们首先在客户端收集用户在登录对话框中输入的“用户名”与“密码”字段，此时候两个字段都是处于明文状态。然后通过网络发送给服务端，服务端进行一系列验证操作。这个一系列的认证操作可能包扩，对客户端的私有信息进行判断，对客户端发来的请求的IP进行验证，但最主要的还是验证客户发送的用户名与密码是否与数据库、或者列表中一致。进行判断后然后将结果发送给客户端。
这一系列操作如果都是以明文状态处理，显然是是非不安全的。我们可以通过一系列手段窃听到客户端发送给服务端真正的密码。或者直接侵入数据库服务器中获取客户端密码，再伪造客户端报文发送给服务端进行操作。

对于此操作我们可以分别对其安全性的要求进行不同级别的安全性加密操作。
对于客户端发送给服务端的报文：由于客户端是暴露在一个我们不可控的PC上，有着被反编译的风险。我们在客户端程序中编写大量加密算法的可靠性也十分低，如果被反编译了往往导致了一批次的加密算法都失效了。我们就必须一次更新，而一次CS架构的更新操作成本显得非常高。
所以，我们对于客户端段到服务端中间的加密解密模型使用非对称的加密模型显的比较合理：
 非对称的加密模型主要使用RSA算法，而RSA算法进行一次更新模型的变更对于客户端来说只需要更新其加密的CA的公钥；
 非对称的加密模型代码及时被反编译了，也只是没用，因为客户端只利用公钥进行了加密报文；
 非对称的加密模型只有在被获取了通讯双发所有的公钥、密钥才能算是真正意义上的破解、相比对称加密模型而言更可靠。

对于在服务端Tuxedo应用层中，我们将客户端发来的密文通过密钥进行解密产生明文形式的用户名与密码，虽然服务端的网络可以视为一个可信域，但是密码属于敏感字段直接使用明文就进行存储安全性和可靠性显得略低。所以我们可以使用不可逆的加密方法进行加密，比如使用MD5、DES此类加密算法进行加密后再存储到数据库数据中。这样即使被侵入了数据库服务器，但是密码也是以密文形式存储。而其加密形式为不可逆运算，无法得知明文是什么。
对于某些敏感级别较高的信息使用这类加密模型是最可行的。比如在银行业务中，我们很少有查询密码这项服务，只有相应的修改密码操作。因为修改密码我们只是生成了一段新密码进行替换，而查询密码我们就需要对密文进行解密进行显示，但是由于加密算法是不可逆的这几乎是不可能的。
而对于那些敏感度不怎么高的信息，我们也可以选择不进行特殊的加密，或者使用一种可逆的对称加密，当然额外的再使用一次基于CA的非对称加密也是可行的方案之一。

系统相关操作安全性
通过登录之后，我们便可执行其他相关操作，诸如查询账户信息，存款，取款等业务。
如果所有的操作都是通过我们的客户端程序发送而来的话，我们便没有什么需要特殊进行安全性再认证的步骤了。但是因为大部分操作底层都是基于TCP/IP的，完全是有可能被拦截、仿造的。
所有我们在客户登录之后也需要对其发送的报文相关信息进行验证，但是每次操作都需要输入密码显然显得是非笨拙。
通常我们也可以使用诸如此类的方案进行解决：在客户端登录后，服务端维护一张链接表，链接表中可以维护登录人员的账户名并对其随机产生一个类似Session Key的字符串，并让客户端在每次交易时候都携带这个字符串在报文中发送至服务端；在所有报文中都携带一些由客户端程序生成的信息以备服务端程序进行校验其有效性。
而对于一些安全性要求较高的操作，比如销户操作还是需要进行相关的密码验证操作。

4.3使用Open SSL进行数字签名认证
4.3.1 Open SSL简介
SSL 是一个缩写，代表的是 Secure Sockets Layer。它是支持在 Internet 上进行安全通信的 标准，并且将数据密码术集成到了协议之中。数据在离开您的计算机之前就已经被加密，然后只有 到达它预定的目标后才被解密。证书和密码学算法支持了这一切的运转，使用 OpenSSL，您将 有机会切身体会它们。
理论上，如果加密的数据在到达目标之前被截取或窃听，那些数据是不可能被破解的。不过， 由于计算机的变化一年比一年快，而且密码翻译方法有了新的发展，因此，SSL 中使用的加密协议 被破解的可能性也在增大。
可以将 SSL 和安全连接用于 Internet 上任何类型的协议，不管是 HTTP、POP3，还是 FTP。还可以用 SSL 来保护 Telnet 会话。虽然可以用 SSL 保护任何连接，但是不必对每一类连接都使用 SSL。 如果连接传输敏感信息，则应使用 SSL。
众多的密码算法、公钥基础设施标准以及SSL协议，或许这些有趣的功能会产生实现所有这些算法和标准的想法。这是一个令人望而生畏的过程。这个工作不再是简单的读懂几本密码学专著和协议文档那么简单，而是要理解所有这些算法、标准和协议文档的每一个细节，并用很熟悉的C语言字符一个一个去实现这些定义和过程。
OpenSSL采用C语言作为开发语言，这使得Open SSL具有优秀的跨平台性能，这对于广大技术人员来说是一件非常美妙的事情，可以在不同的平台使用同样熟悉的东西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平台，这使得Open SSL具有广泛的适用性。
OpenSSL整个软件包大概可以分成三个主要的功能部分：密码算法库，SSL协议库，应用程序。
OpenSSL的目录结构自然也是围绕这三个功能部分进行规划的。

4.3.2 Open SSL支持的加密算法
作为一个基于密码学的安全开发包，OpenSSL提供的功能相当强大和全面，囊括了主要的密码算法、常用的密钥和证书封装管理功能以及SSL协议，并提供了丰富的应用程序供测试或其它目的使用。
对称加密算法
OpenSSL一共提供了8种对称加密算法，其中7种是分组加密算法，仅有的一种流加密算法是RC4。这7种分组加密算法分别是AES、DES、Blowfish、CAST、IDEA、RC2、RC5，都支持电子密码本模式（ECB）、加密分组链接模式（CBC）、加密反馈模式（CFB）和输出反馈模式（OFB）四种常用的分组密码加密模式。其中，AES使用的加密反馈模式（CFB）和输出反馈模式（OFB）分组长度是128位，其它算法使用的则是64位。事实上，DES算法里面不仅仅是常用的DES算法，还支持三个密钥和两个密钥3DES算法。
非对称加密算法
OpenSSL一共实现了4种非对称加密算法，包括DH算法、RSA算法、DSA算法和椭圆曲线算法（EC）。
DH算法一般用户密钥交换。
RSA算法既可以用于密钥交换，也可以用于数字签名。
DSA算法则一般只用于数字签名。

信息摘要算法
OpenSSL实现了5种信息摘要算法，分别是MD2、MD5、MDC2、SHA（SHA1）和RIPEMD。SHA算法事实上包括了SHA和SHA1两种信息摘要算法，此外，OpenSSL还实现了DSS标准中规定的两种信息摘要算法DSS和DSS1。

密钥和证书管理
密钥和证书管理是PKI的一个重要组成部分，OpenSSL为之提供了丰富的功能，支持多种标准。
首 先，OpenSSL实现了ASN.1的证书和密钥相关标准，提供了对证书、公钥、私钥、证书请求以及CRL等数据对象的DER、PEM和BASE64的编 解码功能。OpenSSL提供了产生各种公开密钥对和对称密钥的方法、函数和应用程序，同时提供了对公钥和私钥的DER编解码功能。并实现了私钥的PKCS#12和PKCS#8的编解码功能。OpenSSL在标准中提供了对私钥的加密保护功能，使得密钥可以安全地进行存储和分发。
在此基础上，OpenSSL实现了对证书的X.509标准编解码、PKCS#12格式的编解码以及PKCS#7的编解码功能。并提供了一种文本数据库，支持证书的管理功能，包括证书密钥产生、请求产生、证书签发、吊销和验证等功能。
OpenSSL提供的CA应用程序就是一个小型的证书管理中心（CA），实现了证书签发的整个流程和证书管理的大部分机制。

使用Open SSL API进行加密
RSA加密
RSA是一种基于最大因数的加密算法，形成一组相互匹配的公钥与密钥。RSA算法是一种非对称密码算法，所谓非对称，就是指该算法需要一对密钥，使用其中一个加密，则需要用另一个才能解密。 RSA的算法涉及三个参数，n、e、d。 其中，n是两个大质数p、q的积，n的二进制表示时所占用的位数，就是所谓的密钥长度。e和d是一对相关的值，e可以任意取，但要求e与(p-1)(q-1)互质；再选择d，要求(de)mod((p-1)*(q-1))=1。 (n及e),(n及d)就是密钥对。
RSA加解密的算法完全相同,设A为明文，B为密文，则：A=B^e mod n；B=A^d mod n； e和d可以互换使用，即：
A=B^d mod n；B=A^e mod n；
通过OpenSSL中对RSA的支持，我们可以十分简单、方便、快速地编写出一个通过RSA加密的程序。
首先，在RSA中主要涉及的参数是n.e,d。所以我们需要在程序的初始化部分进行初始化。代码如下（c语言）：

	  /*声明部分*/
   BIGNUM *bnn, *bne, *bnd;

    bnn = BN_new();

    bne = BN_new();

    bnd = BN_new();

		/*初始化*/
    BN_hex2bn(&bnn, MODULUS);

    BN_set_word(bne, PUBLIC_EXPONENT);

    BN_hex2bn(&bnd, PRIVATE_EXPONENT);

/*设置RSA算法中的三个基本参数*/
RSA *r = RSA_new();

r->n = bnn;

r->e = bne;

 r->d = bnd;

在设置完成基本设置完成后，我们就可以通过调用OpenSSL的api进行快速的加密，设置我们需要加密的明文。我们的明文为“abc”，目标密文的字符串为out变量。
unsigned char *in = “abc”;
unsigned char *out;
然后，我们调用加密函数。该函数返回一个int变量 ，当变量数值小于0时，表示加密发生错误，通常为位长不足、有必要的参数没有设置；其他情况则表示成功。
ret = RSA_private_encrypt(flen, in, out, r, RSA_NO_PADDING);

编译后的程序加密运行结果图

4.4 在Tuxedo中使用OpenSSL进行数字签名及加密应用
4.4.1 Tudexo中主要使用的传输协议
在CS的结构中，在底层是通过socket套接字，使用字节流进行通讯的。这就涉及到了对于富有业务信息的报文的装包拆包过程。通常来说，我们可以直接约定好报文流的格式，对其进行定制的装拆包过程。
而在Tuxedo中，我们则不需要关心这些，因为Tuxedo作为一款强大的CS基础的应用服务器框架，内置常用的集中报文格式。比如用于简单的字符串传递的STRING BUFFER、传输用于显示信息的VIEW BUFFER、功能强大且和语言无关的FML32 BUFFER。

4.4.2 STRING BUFFER简介
STRING BUFFER简介
STRING类型buffer是主要用于面向行、变长度的文本信息类型buffer。STRING类型buffer要求必须以NULL作为结束符的。如果 系统采用STRING类型，那么在配置ubbconfig文件时，必须在*MACHINE部分配置TYPE，指明buffer类型为STRING类型。在 两种不同类型架构的机器进行buffer传输时候，TUXEDO对STRING类型buffer进行加码、解码过程。无论系统申请了多少长度的 buffer，系统自动按着NULL所在的位置决定STRING类型的buffer长度。
STRING类型buffer如何申请

char *SndBuf;
SndBuf = (char *) tpalloc("STRING",NULL,1024)
STRING类型使用方法和调用方法

strcpy(SndBuf,"Bea Tuxedo");
tpcall("TOUPPER",SndBuf,0,&RcvBuf,&len,0);

4.4.3 FML32详细说明
FML32类型简单
FML类型buffer简介
FML类型buffer允许存取多个命名的字段。每一个命名的字段可以在buffer中存放零个或更多个的值.
FML支持的数据类型：
• Short
• Char
• Long
• Float
• Double
• String
• Carray
FML类型buffer使用方法
使用FML类型数据步骤：
• 建立FML文件
• 设置环境变量
• 编译FML文件
• 在代码中包含FML头文件，在程序中使用FML API函数
• 编译程序
• 运行程序
FML类型的优点及其意义
单一的使用STRING BUFFER组织起来的报文信息可读性较差，导致了程序中必须耦合大量报文组织逻辑。
而使用FML BUFFER的报文信息，其报文组织的逻辑写在了FML文件中，而程序中只是使用FML文件编译出来的头文件而已，而其使用方式是利用C语言中的结构体。这样的设计在C语言中可以充分的利用menset函数，而不是傻傻的每次去将报文信息存在一个固长的数组中，然后循环调用strcpy去进行复制解析。大大加快了开发的进度以及减轻了后期维护的压力。
而FML BUFFER拥有多个语言的实现。我们可以使用原生C语言的API进行开发，更可以使用DELPHI之类强大的桌面开发语言实现桌面图形程序的开发。FML BUFFER报文与客户端语言无关的特点也使其应用平台多种多样。与后来普及的COM、COBRA技术的主导思想是一致的。将网络应用程序开发带入了一个新的领域阶段。

4.5 使用OpenSSL对Tuxedo的报文进行加密
在实际应用中，一些具有业务意义的详细可以通过字段的长度、业务的复杂程度而使用不同的BUFFER进行开发应用。
基于敏感字段加密
我们将每个报文中的每个字段进行分析，分析出所需要的加密级别分别进行加密后再通过字节流实行传输。优点是不同的字段有定制的加密方案，不容易被整体破译，不需要加密的字段也不需要进行特殊的加密，提高性能。缺点是如果系统过于庞大则每个模块都如此分析工作量巨大，且维护时候非常麻烦，客户端开发也需要对每个字段进行特定的解密方案。
比如在登录系统的功能模块中，用户名和密码可以的报文因为报文中的信息比较少，可以通过STRING BUFFER进行加密。

表1.用户账户登录中的报文字段

而对于查看账户信息的功能模块中由于，一个账户的基本信息字段较多，所以我们将账户对应的BUFFER类型选用FML32进行传输。并且对账户的某些关键字段进行RSA加密。

表2.用户账户基本信息中的报文字段

基于整体报文加密方案
按照报文来进行加密方案的设定，不关心其内部字段结构，降低了分析每个字段的成本，将分析的高度放在业务领域中进行。其优点是节约了维护和开发时候对于加密的感知度，可以将加密与业务代码分离，加密层变成了一个服务。在不必要的时候可以拆卸。缺点所有通过加密层的代码都会被加密解密，降低了性能。

表3.基于整体报文的加密方案

基本用例分析
／／TODO 全局用例图

发起人 用例编号 备注介绍
客户 UC101 客户通过用户名与密码登录
客户 UC102 客户通过系统自主的取款（如果余款不足，则不允许取款)
客户 UC103 客户通过系统自主的存款
客户 UC104 客户只能查询自己的帐户信息
相关数据库建模
T_USER用户帐户表
名称 类型 备注
Id Long 自增PK
Account String Unique
Password Int 6位
Money Double 帐户金额
detail_id Long FK-T_USER_INFO.ID
Category Int 帐户类型（标识位）
T_USER_INFO
Id Long 自增PK
Name String 用户姓名
age Int 用户年龄
id_card String 用户身份证号
sex Int 用户性别(0男1女）

T_TRANSCATION_HISTORY
名称 类型 备注
Id Long 自增PK
Init String 交易发起方
Accept String 交易接受方
over_date Date 交易日期
Account Double 交易金额
Category Int 交易类型

参考文献
William Stallings．密码编码学与网络安全[M]．孟庆树等，译.北京：电子工业出版社，2006．P185－195
http://baike.baidu.com/view/1347211.html. 对称加密系统
http://www.openssl.org/docs/ Open SSL Document

---

5、资源下载

本项目源码及完整论文如下，有需要的朋友可以点击进行下载。如果链接失效可点击下方卡片扫码自助下载。

序号	毕业设计全套资源（点击下载）
本项目源码	基于C+Tuxedo+Mysql的数字签名在Tuxedo中间件中的运用设计与实现（源码+文档）_C__数字签名在Tuxedo中间件中的运用.zip

---

6、更多C#毕业设计项目

精选C#毕业设计83套——源码+论文完整资源