加/解密范文

加/解密范文（精选7篇）

加/解密 第1篇

关键词：openssl,硬件引擎,漏洞

0 引言

openssl是一个开源的SSL协议实现,它采用C语言作为开发语言,因此openssl具有优秀的跨平台性能,并被广泛使用。openssl支持Linux、Windows、BSD、Mac、VMS等平台,这使得openssl具有广泛的适用性。openssl目前最新的版本是1.0.0d。有很多系统都是用openssl来构建安全的通信,比如apache的httpd中的ssl模块、openldap等优秀的开源软件。

openssl主要由三部分组成:crypto库、ssl库以及openss命令。其中crypto库中实现了大量的对称算法、非对称算法和摘要算法,并且这些算法都支持硬件引擎。

1 openssl硬件引擎

openssl是一个自包含的软件,它不依赖于第三方库,它实现了各种软算法。为了支持硬件以提高性能,openssl通过引擎机制来支持硬件算法。当用户调用上层的对称加解密函数时,如何没有注册对应算法的引擎,openssl使用默认的软算法;当用户注册了某个算法的硬件引擎时,openssl将会调用该硬件引擎的算法。下面简要介绍对称计算中,openss如何使用硬件引擎。

openssl的对称计算主要crypto/evp/evp_enc.c中实现,调用接口和主要数据结构在evp.h中定义。对称计算主要有两个数据结构,如下所示:

对称计算调用接口主要有:

(1)对称计算初始化

(2)进行对称计算

(3)获取余下的对称计算结果

从接口可以看出,用户调用openssl进行对称计算时,主要使用的数据结构为EVP_CIPHER_CTX,该结构主要包括了对称算法信息以及硬件引擎。如果无硬件引擎,将使用软算法。openssl进行对称计算时,使用的是EVP_CIPHER结构中的do_cipher函数指针。硬件引擎的加载是在EVP_Cipher Init_ex中完成的。在EVP_CipherInit_ex的实现中,如果指定了对称计算引擎,EVP_CIPHER_CTX中的cipher将指向硬件引擎所实现的EVP_CIPHER,后续的update操作和final操作都将使用硬件引擎提供的函数。

do_cipher函数对数据进行对称计算,其参数主要有:输入缓冲区、输出缓冲区以及输入长度。输入缓冲区和输出缓冲区可以是不同的内存地址。该函数返回非0时表示成果,返回0表示对称计算失败。不过对于软算法,基本上不可能出现计算失败的情况,而如果用硬件来做对称计算,由于硬件以及硬件接口的原因,则有可能出现对称计算失败。

2 openssl硬件引擎加解密漏洞

在openssl的各个SSL协议版本实现中(包括当前的1.0.0d),无论在ssl握手阶段还是数据发送和接收阶段,对于数据的加解密运算都会调用函数EVP_Cipher进行运算(分别对应文件d1_enc.c、s2_enc.c、s3_enc.c和t1_enc.c)。s3_enc.c中调用方式如下:

该函数将对称计算直接调用了do_cipher。

在openssl运行时,该函数的输入缓冲区rec->data与输出缓冲区rec->input指向相同的内存地址,并且不判断其返回值,由此会带来安全问题。

特定情况下,openssl采用硬件引擎进行ssl握手和通信时,当客户端和服务端因为某种硬件原因导致加解密失败时,由于它没有检查EVP_Cipher函数的返回值(硬件引擎加解密函数会有返回值,但上层并不判断),数据的传输将变成明文通信。即使仅仅因为一方硬件原因导致加密失败,当前发出的数据也将是明文。SSL通信一旦变成明文通信,用户将很难察觉。

此漏洞虽然被利用的概率较低,但一旦出现上面描述的特定情况,将会带来巨大的安全问题。

修补该漏洞很简单,仅仅判断返回值,如果出错立即终止SSL连接即可。

3 漏洞的验证

作者在两台linux操作系统上对该漏洞进行了验证,为了便于抓包,其中一台装在虚拟机上。硬件引擎替换了RC4算法,并进行了加解密故障模拟,引擎名称为TestEngine,openssl版本为1.0.0a。

在服务端运行命令:

在客户端运行命令:

然后通过wireshark进行抓包,服务端中的Hello消息如图1所示。

服务Hello消息表明加密使用RC4算法。

发送的应用数据如2所示。

图2中,传输的数据是明文。不仅仅传输的数据是明文,其他的握手数据也是明文。

参考文献

[1]rfc2246,The TLS Protocol Version 1.0.2009.

加/解密 第2篇

关键词：矩阵；PKI；电子政务；加密解密

中图分类号：TP301.6

经济越发展，信息技术的安全性越重要，如何利用网络功能来实现虚拟的、全球性的数字体系进行信息数据的安全传输便成为了目前最紧迫又最具有现实意义的研究课题。政务文档在应用中普遍采用离线密码加密方式、证书加密和智能电子钥匙等技术。其中公钥基础设施PKI（Pubic Key Infrastructure）在电子政务、网络交易中是最常见的，比如政府安全保障局利用PKI建立的电子邮件收发系统、金融界运用PKI实现的网上证券、网上银行交易业务等。但是，PKI仍然存在许多问题，它的算法本身将受到计算机的属性和数学的快速发展等因素的限制；同时私钥如果被黑客恶意窃取，那么发送者的身份将无法得到确认，可靠性较弱。故本文提出基于转置矩阵的算法将有效地改进以上问题，提高计算速度，保证数据的可靠性和完整性。

1 一般的電子政务公文传输系统

通常电子公文传输系统由文件传输终端、电子公文交换服务器、数字签名和密钥管理等子系统构成。用户通过文件传输终端进行政务公文的发送与接收，其中对公文的加密和解密、数字签名和认证等一系列操作都是在文件传输终端上来完成的；当文件到达文件服务器时，便通过电子公文交换服务器来实现对政务公文的中转，完成上级与下级单位间文件的下发、同级单位之间的转发工作；此系统内的所有用户在访问服务器上的证书账号时，都需上传本用户的证书，实现“单一的上传，集中的下载”的交换方式，以下载其他需要的用户相关证书。图1为电子政务公文传输系统结构示意图，其中包含电子政务文件的在系统传输过程中的加密解密以及认证步骤（共7步）。

2 电子政务公文的加密方法

本文将电子政务公文的加密方法分为以下三个步骤：密钥的生成、数据加密、数据解密。

2.1 密钥的生成。将所有矩阵涉及到的维数都记为n，通常在实际的应用中，可以取n=4。一般情况下，密钥中所包含的公钥和私钥可以按照以下方法获取：随机选择一个1024bitRSA模数N，其中N=pq，p和q都是素数，并且|p|=|q|=512。另外随机选择一个n维矩阵A= ，并且矩阵A在实数域R上是可逆的，因此本文将逆矩阵记作 ，其中| |取59。再随机选取3个n维可逆矩阵B、C、D，其中 、 、 ，使其满足 、 、 、 ，并且条件等式为：

以上矩阵都必须是可逆矩阵，保证该加密算法所对应的解密准确，故可以计算：

综上可知，矩阵E、F和模数N是该算法的公钥，则D、 以及p、q构成了私钥。

2.2 数据加密。将需要加密的电子政务公文M的长度记作|M|=L，同时将M划分成若干个等长的小块m，其中 =490，并将其记作向量 ，以此形成加密明文M，发送者可以随机选取2n个整数，记为 ； ，此时可计算出发送者的密文为：

故： ，此时：W便为密文。

2.3 数据解密。当电子政务文件传送到接收方时，此时接收方收到了密文W，因此接收方可计算： ，并且

故明文可得：

3 密钥的分配

为了保证密钥的安全性，通常情况下处理方法就是不断地更换密钥，但是如今电子时代这将会是一个复杂而不现实的问题。在本文研究的电子政务公文传输系统中，通常是以一对多的传输-转发方式，因此需要多人共同管理密钥。本文将采取Shamir方法解决密钥的管理问题，它本身提出了关于密钥共享的概念，提出了门限体制理论，解决了频繁更换密钥的问题。

利用Shamir的密钥共享理论基础，本文假设有一个含n项的多项式P（x）=α0+α1*x+α2*x2+…+αt-1*xt-1，并假定（x1，y1），（x2，y2），…，（x1，y1）是p（x）上的已知点，并且 ≠ ，i ≠ j。那么，这些已知点就可以唯一的确定p（x），并且能够得到α0、α1、…、αt-1的值，其中多项式的系数αi就是加密密钥，p（x）图上能够保证这些数据都没有相同的坐标，因此所有数据点的集合确定对应的密钥。

4 性能的分析

本文前面所述可知，就公钥和私钥的长度而言，因为公钥是由矩阵E、F和模数N构成，而私钥则由D、A-1以及p、q组成。它们分别对应的长度约为（2n2+1）*1024比特、2n2*1024+2*512比特。但是RSA算法中，其密钥长度从40到2048比特可变，由此可见本文的公私钥长度都要大于RSA的密钥长度，而密钥越长，加密效果就更好。

本文中所选取的安全大素数跟RSA是一样的方法，所以密钥生成复杂度基本相同，但在本文的加解密过程中，明文跟密文的长度分别设定为490n和1024n比特，因此密文扩展为2.08：1，相比较RSA算法而言，它是一种陷门单向性置换算法，它的密文扩展为1：1，故比较本文的密文扩展程度，比RSA算法要大。综上可见，本文所提出的方法要优于RSA的算法。

5 结束语

本文从广泛使用的PKI技术进行了讨论分析，比较了目前电子政务公文在实际应用中还存在的相关问题，借鉴RSA生成密钥的复杂程度，并根据Shamir门限密钥分割体制的优越性，明确给出了基于矩阵算法的具体步骤。为保证传送电子公文的保密性，在本文的算法中设计都要复杂于RSA算法，也弥补了PKI技术的一些缺陷，有效的提高了电子政务公文在传输过程中的效率，极大的促进电子政务公文在信息化社会的广泛运用。

参考文献

[1]毋梦勋.电子公文加密传输系统的技术研究[D].西安电子科技大学，2009.

[2]史伟奇.PKI技术的应用缺陷研究[J].中国人民公安大学学报，2007（03）.

加/解密 第3篇

在国内外有关ECC的研究方面,主要集中在ECC的时间复杂度和空间复杂度上[2,3,4]。参考文献[2]研究模逆和标乘的快速算法,参考文献[3]针对KP算法将改进的Booth算法嵌入传统算法,极大地降低了迭代次数和有限域运算量。参考文献[4]将所有的模运算全转化为模乘运算和模加运算,并改进了LSD乘法器,利用该单元进行模运算,从而其硬件实现了具有面积小、速度快等优点。目前国内的密码技术还是落后于国外,特别是在生活应用中,国内的企业基本上是引用国外的密码技术进行二次开发。如果要将实现的椭圆曲线密码系统应用到实际中,则需要通过系统集成芯片设计(SOC),将FPGA上实现的椭圆曲线密码系统集成实用性的加密芯片。一旦设计过程中所需的资源和条件不够完善,将导致加密芯片的制作难以实现。为此,本文借助Xilinx公司提供的强大的系统级硬件仿真工具System Generator[5],研究并设计ECC加解密系统。

1 椭圆曲线密码体制

由于最终是要在硬件上实现椭圆曲线密码体制[6],所以本文选择的有限域是特征为2的GF(2n),选择的椭圆曲线方程如式(1)所示。

首先,建立椭圆曲线密码的基础结构(m,f(x),a,b,G,n,h),参数f(x)、a2、a6、G、n公开。设要加密的明文为M,将M划分为较小的数据块,M=[m1,m2,…,mi],(0≤mi≤n)。设A方将M加密发给B方。

加密过程描述如下:

(1)用户A去查公钥库PKDB,查到B的公开密钥Qb;

(2)用户A选择一个随机数k,且k∈{0,1,2,…,n-1};

(3)用户A计算点X1(x1,y1)=k G;

(4)用户A计算点X2(x2,y2)=k Qb。若X2=0,则转到步骤(2);

(5)用户A计算点C=m2_mod f(x);

(6)用户A发送加密数据(X1,C)给用户B;

解密过程描述如下:

(1)用户B用自己的私钥d求点X;

(2)对C进行解密:

可见椭圆曲线密码体制涉及到GF(2n)上的模加运算、模乘运算、求逆运算,还有椭圆曲线的KP点乘运算,下面对几个主要算法进行分析。

1.1 GF(2n)域上的模乘运算

模乘模块是整个设计中最关键的模块,模乘的过程包括多项式相乘和取模两个过程。传统的乘法器是将两个m位操作数相乘,然后对其进行f(x)求模。这样的缺点就是需要一个2m位的寄存器来存储中间结果,势必会浪费资源。本文采用全串行移位相加法来实现模乘运算[6]。该算法只有简单的移位和“异或”运算,但是需要大量的移位运算,如果A、B具有m位,则需要进行m-1次移位运算,这是比较耗时的。但是本文使用的FPGA工作在61.44 MHz时钟下,m一般取值在200左右,因此全串行移位相加法大概需要的是ns级的时间,而且全串行移位算法也是最节省资源的算法。通过Modelsim仿真该模块,得到图1所示结果。其中,clk是系统时钟61.44 MHz;reset是系统复位信号;en是使能端口;din是乘数输入端口,低位在前;dout是输出结果;rdy是输出结果有效指示。

选取参数:

仿真结果为:

1.2 GF(2n)域上的模逆运算

对于GF(2n)域上的模逆运算,当今最有效的算法就是扩展欧几里德算法和基于费马定理的模逆算法。扩展欧几里德算法用时会比基于费马定理的模逆算法用时短很多,但是相应地是以牺牲硬件资源为代价,在后面的点乘算法和最后的椭圆曲线密码体制的实现耗用资源很大。扩展欧几里德算法还要去另外设计一个多项式模块,而基于费马定理的模逆算法只需要反复调用先前做好的模乘模块就行,再加上本文用的FPGA时钟频率本身就高,因此本文选择费马定理来做模逆算法。通过Modelsim仿真该模块,得到图2所示结果。其中,clk是系统时钟61.44 MHz;reset是系统复位信号;en是模逆使能;din是输入数据;a_inv是输出结果;rdy是输出结果有效指示。

选取参数:

仿真结果:

1.3 GF(2n)域上的点乘运算

椭圆曲线密码体制中最核心、最关键的算法就是点乘运算,即KP运算。Montgomery算法是现今被验证过的求KP的高效算法,其最大优势就是在算法的过程中只求两次模逆算法,尽管在每一次求点加和倍加时多用了几个模乘运算,但是模逆算法消耗的时间和资源要比模乘算法多得多。而对于其他算法,例如2进制取幂法,则每一次的点加和倍加运算中都要进行一次求逆运算,效率显然比不上Montgomery算法。因此本文采用射影坐标下的Montgomery算法进行KP运算。通过Modelsim仿真该模块,得到图3所示结果。其中,clk是系统时钟61.44 MHz;reset是系统复位信号;en是KP使能;din是输入数据;doutx是输出结果;kx、douty是输出结果;ky、rdy是输出结果有效指示。

选取参数:

仿真结果:

2 System Generator搭建ECC加密系统

System Generator是业内领先的高级系统级FPGA开发工具。其作用是借助FPGA设计高性能DSP系统并和Simulink实现无缝链接,快速建模并自动生成代码[5]。System Generator最大的特点就是可利用Simulink建模和仿真环境来实现FPGA设计,无需了解和使用RTL级硬件语言,让DSP设计者能够发挥基于FPGA的DSP的最大性能和灵活性,并缩短整个设计周期。前文用FPGA实现了ECC的各个关键模块,下面用先前生成的各个模块代码通过System Generator的黑盒子生成各自相应的模块。再将这些模块搭建成完整的ECC模块,以便在Matlab工作空间中输入相应的参数、明文和相应的使能端口就可以实现加密;输入相应的参数、密文和相应的使能端口就可以实现解密。但是本文所涉及的参数较大,输入的过程很耗费时间,因此本文将参数都固定在一个ROM中间,只要控制相应的使能信号,就可以达到一个加解密的模拟过程。

2.1 数据输入模块的搭建

本文中的端口有使能端口和参数端口,其中,使能端口是1 bit的,就可以用计数器来实现。对于191个bit位的参数,可先将其分解成6组的32 bit系数,存在如图4所示的ROM中,只要改变ROM中的值就可以控制输入参数的值,改变3个常数模块就可以控制参数输入的时刻。

2.2 ECC系统的搭建与仿真结果

利用代码生成的KP模块、求逆模块和乘法模块搭建成ECC加解密系统。由于ECC加解密系统的各个子模块有很多的反馈端口,搭建起来的图显得比较乱,因此可以在ECC系统中的m文件添加this block.add File()。把各个子模块添加到ECC顶层模块中,这样就相当于把各个子模块集成在统一的黑盒子中。

设置运行时间为4 000 000个时钟周期,将加解密指示信号设置为加密,点击运行,进行加密仿真,在工作区间可以看到,明文输入和对应的密文输出。例如,当输入的明文为“4129534493046158328227537522838960054530294419451055575666”时,输出的密文为“3625519732263338515328819742424233936313311718087”。

设置运行时间为4 000 000个时钟周期,将加解密指示信号设置为解密,点击运行,进行解密仿真,在工作区间可以看到密文输入和对应的的明文输出。例如,当输入的密文为“3625519732263338515328819742424233936313311718087”,则输出的明文为“4129534493046158328227537522838960054530294419451055575666”。

ECC模块加解密运算输出有效数据的时钟周期是第3274550,使能信号则是在第11个时钟周期输入,因此整个运算过程中数据的输入输出所耗费的时间是3274550-11=3 274 539个时钟周期,所以对于采用时钟频率为61.44 MHz的FPGA来说,只要用3 274 539/61.44μs就可以完成一次加密算法,或者一次解密算法。总共用的时间为3274539/61.44 ns=53.3 ms,而若单单只用Matlab仿真运行,大概需要时间为20 min。因此采用硬件实现椭圆曲线密码系统的优越性不言而喻。

摘要：根据椭圆曲线密码体制的几种关键算法,采用Modelsim仿真工具设计相应的算法模块。然后将各模块代码通过System Generator生成对应的系统模块,再将这些模块搭建成完整的ECC系统。最后对整个ECC系统进行仿真,实验数据进一步验证了该设计的正确性。

关键词：System Generator,椭圆曲线,有限域

参考文献

[1]HANKERSON D,MENEZES A,VANSTONE S.Guide toelliptic curve cryptography[M].Springer Verlag New YorkInc,2004:25-147.

[2]MA S W,HAO Y L,PAN Z Q.Fast implementation formodular inversion an d scalar multiplication in the ellipticcurve cryptography[C].IITA’08,Beijing,China,2008:488-492.

[3]龚书,刘文江,戎蒙恬.一种椭圆曲线密码加密算法及实现[J].高技术通讯,2004(3):25-28.

[4]唐薛峰,沈海斌,严晓浪.GF(2^m)上椭圆密码体制的硬件实现[J].计算机工程与应用,2004,40(11):96-98.

[5]田耕,徐文波,胡彬.Xilinx ISE Design Suite10.x FPGA开发指南[M].北京:人民邮电出版社,2008.

加/解密 第4篇

目前国外在混沌保密通信方面的研究较为成熟, 而国内在该领域虽做了大量的研究工作, 但大多数停留在软件层面上, 存在着信息易被攻击和窃取等问题。而基于硬件层的加解密在专用硬件中进行, 加解密信息存储在专用设备中[4]。因此, 相比于软件加解密技术, 硬件加解密更加安全可靠。

本文提出了一种基于FPGA和PSo C的混沌音频加解密系统硬件实现方案。FPGA采用流水线技术和并行运算[3], 在数据处理速度上比单片机和DSP更具优势。可编程片上系统PSo C (Programmable System-on-Chip) 是一种可编程的混合信号阵列构架, 采用图形化编程方式, 接口资源丰富, 方便用户开发。因此, 本文采用FPGA和PSo C开发板构建混沌音频加解密系统。

本文首先介绍了系统工作原理, 然后给出硬件及软件实现方案, 并从时域和频域的角度对系统进行了测试和分析。

1 混沌加解密原理

1.1 混沌伪随机序列

系统采用线性反馈移位寄存器 (LFSR) [5]产生混沌序列Qm-1…Q1Q0, m级LFSR电路由m个D触发器和若干个异或门构成, 在脉冲CP的上升沿到来时, 输出m bit混沌序列Qm-1…Q1Q0, 因LFSR的输出序列具有周期性, 故被称作混沌伪随机序列。LFSR电路结构如图1所示, 其中gi表示反馈系数, 若反馈支路存在, 则gi取值为1, 否则gi为0。

用 表示LFSR第i级触发器的第n种状态, 如式 (1) 所示:

混沌伪随机序列Qm-1…Q1Q0的产生从种子 (以Dm-1…D1D0表示) 开始。当种子Dm-1…D1D0=0…00时, 输出序列Qm-1…Q1Q0将保持全零状态;当种子Dm-1…D1D0≠0…00, 且反馈系数gm…g1g0满足一定条件[5]时, 输出序列周期T取最大值2m-1。本系统处理的数字音频信号为8 bit, 故设计的混沌伪随机序列为8级LFSR, 反馈系数g0g1…g8取值为100011101。经实测, 输出序列周期T=28-1=255。

1.2 加解密原理

异或是一种简单的逻辑运算, 如果变量A与变量B连续进行2次异或运算, 则输出F等于A本身, 其数学原理[6]如式 (2) 所示:

依据式 (2) 可知, 异或是一种初级的加解密方案, 因其实现速度快, 已成为目前较流行的加解密方法之一。本系统加解密逻辑框图如图2所示。

在生成混沌序列DCHAOS后, 系统开始加密, 将数字音频信号DADC与其做异或运算 (Xor_1) , 便生成被打乱的序列即密文DXOR1;解密只需将密文DXOR1再次与混沌序列DCHAOS进行异或 (Xor_2) , 从而可得明文DXOR2, 理论上明文DXOR2与音频信号DADC一致。

2 系统方案设计

混沌音频加解密系统由同步控制模块、ADC模块、DAC模块、混沌序列发生模块、信号加密与解密模块及输出切换模块等组成。其中同步控制模块是系统加解密的关键, 该模块产生3个分频脉冲fS、PEDC及PXOR, fS控制混沌序列的产生和音频信号的ADC转换, PEDC、PXOR分别触发加密和解密的启动。系统逻辑框图如图3所示。

在同步脉冲的控制下, 音频信号Vin经ADC模块转换为数字信号DADC, 与混沌序列DCHAOS依次进行加密和解密, 生成的密文DXOR1和明文DXOR2可通过输出切换模块选择输出, 然后DAC模块将输出结果DXOR1或DXOR2转化为模拟信号Vo。混沌加解密系统的具体过程可用图4中的时序图来描述。

混沌音频加解密系统的工作过程具有周期性, 其一周期内的工作原理如下:

(1) 在t1时刻, 时钟源CLK的上升沿到来, 产生脉冲fS, 紧接着在fS的作用下, 混沌序列DCHAOS开始产生, 同时音频信号ADC转换启动;

(2) 混沌序列DCHAOS和音频信号DADC均稳定后, 在t2时刻时钟源CLK的上升沿到来时, 数据加密启动脉冲PEDC产生, 密文DXOR1开始生成;

(3) 密文DXOR1处于稳定状态期间, 分频脉冲PXOR在t3时刻CLK上升沿的触发下产生, 解密过程启动, 即可得明文DXOR2;

(4) 明文DXOR2稳定后, 在t4时刻开始进行DAC转换, 最终输出模拟信号Vo。

3 系统实现

3.1 硬件平台构建

本系统采用的FPGA开发板是Altera公司的DE2-115。开发板采用Cyclone IV EP4CE115芯片, 芯片含有114 480个逻辑单元、3.9 Mbit随机存储器、266个乘法器。开发板的外围接口资源丰富, 满足用户对视频、音频、高品质图像等多类型的开发需求。

本系统采用的PSo C开发板是CYPRESS公司的CY8-CKIT-050。开发板采用基于ARM Cortex-M3内核的芯片CY8C5868AXI-LP035, 该芯片整合可组态的模拟和数字电路阵列, 模拟电路包括ADC、DAC、放大器等, 数字电路包括PWM、定时器、计时器、UART等。

系统硬件模块间的连接关系如图5所示。

因音乐播放器输出的音频信号约为-0.5~0.5 V, 而PSo C的ADC模块仅支持0~2.048 V电压输入, 故需对音乐播放器输出的信号进行调理。系统中采用串联一节1.5 V干电池的方法提高输入信号偏移量, 可达到ADC模块电压输入标准。

3.2 软件设计

FPGA端的软件流程如图6所示。

FPGA端负责混沌序列的产生、同步控制及数据加解密, 其开发环境是Altera公司QUARTUSⅡ。软件采用自顶向下的设计方法及模块化的编程思想, 开发方式采用Verilog HDL硬件描述语言和模块/原理图 (Block Diagram/Schematic) 两种方式, 各模块采用Verilog HDL进行设计, 模块间集成运用模块/原理图方式。经仿真验证后将程序下载到开发板中。

PSo C端完成音频信号的ADC和DAC转换, 其开发环境是CYPRESS公司PSo C Creator 2.2, 软件采用图形化编程方式, 即从元件库中选择相应的模数器件进行配置, 然后调用相关API函数。与传统的编程模式相比, 该开发环境简化了大量底层代码的编写, 缩短了项目开发周期。PSo C端软件流程如图7所示。

4 系统测试与结果分析

4.1 数字域测试

由于PSo C的ADC模块转换时间最快为10μs, 为使混沌序列DCHAOS与音频信号DADC保持同步, 分频脉冲fS的周期应大于10μs。本系统中FPGA时钟CLK周期设置为1μs, 分频脉冲fs、PEDC及PXOR的周期均为13μs。对数字域内的加解密数据进行实测, 其结果如图8所示。

由图8可得出如下结论:

(1) 混沌序列DCHAOS与音频信号DADC基本保持同步。

(2) 信号加密运算正确, 由图8 (a) 可知, 混沌序列DCHAOS与音频信号DADC进行异或运算, 可得密文DXOR1。

(3) 信号解密运算正确, 由图8 (b) 可知, 数字域内解密输出的明文DXOR2与输入的音频信号DADC延时2~3μs, 数值上则完全一致。

(4) 经实测, 混沌序列DCHAOS、音频信号DADC、密文DXOR1与明文DXOR2等信号与分频脉冲fS、PEDC及PXOR的周期均为13μs, 频率均为77 k Hz左右。

4.2 模拟域测试

实际测试发现, 加密后的声音发出刺耳的“滴”声, 解密后声音的听觉效果良好。对录制的音频信号波形进行测试与频谱分析, 其波形及频谱如图9所示。

由图9可知, 加密信号的频谱在各个频段的分布均匀, 类似噪声;解密信号与原始信号的频谱分布规律基本一致, 因DAC转换输出的电压是原始信号的2倍, 故二者的幅度略有差异。

本文介绍了一种基于FPGA和PSo C的混沌音频加解密硬件实现方案。该方案采用LFSR的方法产生混沌伪随机序列, 并结合FPGA和PSo C开发板实现了音频信号的加解密。

摘要：针对软件加解密易被攻击、硬件加解密开发难度大的问题, 提出了一种基于FPGA和PSoC的混沌保密通信的硬件实现方案。该方案采用线性反馈移位寄存器 (LFSR) 产生混沌伪随机序列, 利用PSoC完成模/数、数/模转换, 并采用FPGA实现了混沌伪随机序列产生、同步控制及音频信号加解密等功能。介绍了混沌伪随机序列的产生方法和加解密原理, 并给出了系统设计思想和实现方案。测试证明, 该系统实现了混沌音频加解密功能, 对混沌保密通信领域的应用开发具有一定的参考价值。

关键词：FPGA,PSoC,混沌保密通信,音频加解密

参考文献

[1]袁小于.数字图像非线性加密算法研究[D].重庆:重庆师范大学, 2001.

[2]赵耿, 方锦清.现代信息安全与混沌保密通信应用研究的进展[J].物理学进展, 2003, 23 (2) :212-214, 232-233.

[3]刘景亚, 季晓勇.基于FPGA的CPRS混沌加解密算法高效实现[J].电子测量技术, 2008, 31 (11) :175-176.

[4]贾立恺, 黄国庆, 赵敬, 等.基于FPGA的PCI硬件加解密卡设计[J].电子设计工程, 2010, 18 (5) :142-145.

[5]束礼宝, 宋克柱, 王砚方.伪随机数发生器的FPGA实现与研究[J].电路与系统学报, 2003, 8 (3) :121-122.

加/解密 第5篇

云计算利用虚拟化技术将海量的计算和存储能力纳入统一的资源池,并以服务的形式提供给用户。云存储服务提供商为了基于有限的资源为更多用户提供服务,通常采用明文形式存储数据并且缺乏不同用户数据之间的隔离机制,一旦云服务提供商遭到攻击,脆弱的防护机制将导致大量用户数据的泄漏。在云存储的模式中,数据所有权和管理权分离,作为数据所有者的用户不再拥有数据的管理权,云服务提供商可以完全控制用户的数据,如何防范云服务提供商对用户数据的滥用也是一个重要的安全挑战。

本文提出一种基于透明加解密技术的密文云存储系统实现方法,并研发了基于Hadoop分布式文件系统(Hadoop Distributed File System,HDFS)的服务器端以及Windows和Android平台的客户端。在该系统中,用户数据在终端存储、传输过程和云端存储均为密文形式,用户通过控制密钥掌握数据的管理权,可有效的防止云服务商以及恶意第三方对数据的窃取,即使终端丢失或服务商停止运营,用户存储在终端和云端的密文数据仍然不会泄露隐私信息。此外,透明加解密技术的应用,保证用户不必更改原有的文件操作习惯,提供了良好的用户体验。

2背景与相关工作

目前,国内外很多企业都致力于云存储的研究和推广,提供的云存储服务包括Amazon S3、Dropbox、百度云盘、360云盘等。云存储客户端工具将云端文件元信息映射到本地,用户可通过客户端直接访问和操作云端文件、实现文件的上传和下载。但上述服务中,用户数据在本地和云端均为明文形式,存在着数据泄露和篡改的安全隐患。

为保护用户数据的安全性和隐私性,一种解决方案是由用户在本地预先加密数据,再将密文数据上传至云端[1],如Chen M Y等提出的SecureDropbox[2]以及国内一款文件加密工具CryptSync。这两个方案均是基于本地加解密工具实现,即将本地明文文件夹中的数据加密写入对应的密文文件夹,用户需手动将密文数据上传至云端,此类工具与云存储系统结合可有效解决云端数据明文存储和服务商不完全可信的问题,但由于数据加解密阶段和云存储同步阶段都需要用户介入,改变了用户的使用习惯。

郝斐等提出的云存储安全增强系统[3]基于Amazon云存储服务器S3实现,系统客户端对上传的数据自动进行加密,对下载的数据进行完整性校验,若文件与上传时一致则立即进行解密。该方案可有效保护云端隐私数据安全,但由于对下载到本地的文件立即进行解密,导致本地文件以明文形式存储,同样存在着数据泄露的风险。

候清铧等提出的方案[4]从保护云端分布式文件系统数据私密性的角度出发,基于SSL连接和Daoli虚拟监控系统实现,通过虚拟监控系统将用户数据和操作系统隔离开,防范传统攻击以及来自操作系统管理员的攻击。然而,2014年10月Google发布研究报告公布了SSL3.0协议存在的一个安全漏洞POODLE (Padding Oracle On Downgraded Legacy Encryption Vulnerdoility),该漏洞可被黑客用于截取客户机和服务器间传输的数据。方案中使用的Daoli系统需要对操作系统内核进行修改,且在服务器端引入了一定的性能损失,此外该方案同样未解决本地存在明文数据的问题。

部分提供云存储服务的厂商同样为保护用户数据安全做出了努力,例如:苹果公司的iCloud采用了云端数据加密存储模式,该方案可有效防止恶意攻击者对云端数据的盗取,但由于加密密钥未掌握在用户手中,这一方案并不能解决服务商滥用权限的问题。

3透明加解密技术

透明加解密是指不改变用户对文件的访问习惯和上层应用程序,在后台采用事先设定的加密算法和密钥自动完成文件加解密,在规定环境中用户感觉不到加解密过程的存在,但一旦离开该环境,数据则因无法自动解密而不能使用,从而达到保护数据安全的目的。透明加密技术可分为加密文件系统(Encrypting File System,EFS)、过滤驱动层透明加解密和API Hook透明加解密。

EFS是Windows提供的基于非对称公钥加密算法RSA和对称加密算法DESX的混合加密机制。首先,操作系统根据用户的安全标识符生成公私钥对。加密文件时,系统生成一串伪随机数作为加密密钥 (File Encryption Key,FEK),采用DESX算法加密文件并删除明文,最后用公钥加密FEK并存储。解密文件时,系统利用当前用户私钥解密得FEK,再用FEK解密出明文。

过滤驱动层透明加解密基于文件过滤驱动技术实现,工作于内核层。过滤驱动属于内核中的一种特殊驱动,它依附于宿主驱动,可以拦截并修改宿主驱动的请求。该方案在文件系统驱动层和I/O管理器之间加入过滤驱动层,过滤驱动层拦截用于传递消息的输入输出请求包(I/O Request Package,IRP),分析IRP包的属性,若为读/写操作,则在数据读/写前分别调用解密/加密算法。

API Hook透明加解密基于钩子技术实现,工作于应用层。应用程序在Windows平台或Android平台一般处于用户态,该级别程序不能随意操作地址空间,若要执行文件操作必须调用系统API,该方案就是通过修改API函数入口地址实现。方案大致流程:将钩子程序注入到目标进程,修改文件读写函数的入口地址使其指向加解密函数,加解密完成后再调用原函数完成文件读写。

上述透明加解密方案中,EFS与操作系统结合,无需安装额外软件,但该方案对操作系统版本和文件系统格式均有严格要求,通用性较差。过滤驱动层透明加解密基于动态加密,无需一次性处理整个文件,实现效率高。但该方案涉及到驱动层开发,开发难度大,且加入过滤驱动层可能与其他驱动产生冲突,操作系统升级后易引发兼容性问题。API Hook透明加解密方案工作于应用层,系统兼容性、稳定性好,开发维护成本低, 在Windows系统和Android系统均有比较成熟的实现方案。但该方案基于静态加密实现,对大文件的操作效率较低。综合考虑安全性、系统兼容性、稳定性和开发难度,本系统选用API Hook透明加解密方案。

4系统设计与实现

4.1设计目标与系统架构

密文云存储系统的设计目标在于为用户提供云存储服务的同时保障其数据安全,核心思想是采用密文形式存储和传输数据,并由用户掌握密钥以掌控数据管理权。系统的运行环境适用以下假定:首先,云存储平台是部分可信的,即云存储平台忠实地执行数据存取功能,但存在管理员滥用用户数据和恶意第三方窃取数据的可能性;其次,用户接入云存储的终端设备是异构的并且是易失的,但客户端在通过身份认证后是可信的。系统实现的具体目标包括:

(1)数据的机密性。透明加解密技术保障用户数据在终端、传输过程和云端均为密文形式,为用户数据提供机密性安全防护。

(2)数据的可用性。基于云平台的数据同步,用户可通过网络随时访问存储于云端的数据。

(3)支持异构终端。终端至少支持Windows桌面系统和Android桌面系统,在传统PC和移动智能终端上提供统一的数据视图。

(4)支持云平台扩展。系统可对接第三方云平 台,提供可选 的底层存 储资源。

图1为密文云存储系统架构图,系统包括客户端、服务器和数据存储平台三大部分。客户端为用户提供交互界面,在后台完成数据透明加解密和数据同步。服务器对系统进行配置管理,与客户端交互实现用户管理、密钥管理和数据同步,与数据存储平台对接实现数据存取。数据存储平台为系统提供底层存储资源,包括HDFS分布式存储平台和第三方云平台。

4.2Windows客户端透明加解密

Windows客户端包括用户管理模块、加解密模块、密钥管理模块和同步模块,其中加解密模块和密钥管理模块配合实现数据透明加解密,是本系统的核心模块。

(1)加解密模块。API Hook的核心是 修改API函数入口,但Windows系统中各个进程的内存空间相互独立,在一个进 程中无法 直接修改另一 进程的函 数入口地 址。 然而Windows系统提供 一种名为 钩子(Hook)的消息处理机制,它允许应用程序在其他程序中安装子程序,并对目标程 序中指定 类型的消 息进行监控,在消息到 达目标窗 口前,钩子程序捕 获该消息 并获得其控制权,此时钩子程序可修改消息后继续传递,也可直接终止消息的传递。Windows系统API Hook透明加解密的基本原理如图2,其实现流程为:打开目标进程,获取LoadLibrary函数地址;在目标进程中申请内存并写入要注入的Dll路径;启动远程线程,入口地址为LoadLibrary函数地址,参数为要注入的Dll路径; 注入的Dll代码在被加载时运行,找到读写函数所在的函数库以及导出表;修改导出表,将系统读写函数入口地址改为自己写的加解密函数的入口地址;在加解密函数中调用原读写函数。

(2)密钥管理模块。实现对主密钥和加密密钥的管理,包括密钥产生、认证、更新、备份和重置等子模块。在透明加解密系统中,一般选用对称加密算法,其加密速度快、加密效率高,但由于算法公开,其安全性便依赖于密钥。为保障密钥安全,本系统采用二级密钥方案,一级密钥为主密钥,二级密钥为加密密钥。其中,主密钥为用户设置,用于对加密密钥进行加密;加密密钥为系统产生,用于数据加解密。二级密钥管理机制有效保障密钥安全,无论是特权用户还是恶意攻击者均无法在系统中获取用户密钥。

4.3Android客户端透明加解密

Android客户端的加解密模块同样基于API Hook实现,但具体实现与Windows端有所区别。

Android系统根据编程语言的不同,可分为Java层、NativeC层和Linux Kernel层,在NativeC层通过JNI可直接使用Linux提供的函数,基于API Hook的透明加解密即在NativeC层实现。Android系统中, 文件的打开和关闭操作分别通过JNI方式的open函数和close函数实现,函数对应动态库为libnativehelper.so,实现透明加解密的关键就在于对该动态库进行Hook,使文件读写操作执行新注入的带有加解密功能的open函数和close函数。NativeC层的程序处于Linux用户态,每个进程均有独立的进程空间,要对其进行Hook则必须进入其进程空间修改内存中代码,Linux提供的进程跟踪函数ptrace可实现该功能。该函数可绑定某一目标进程,查询并修改该进程的内存空间和寄存器。

具体实现时若将所有代码注入目标进程,其构造将十分复杂难以实现。因此,将带有加解密功能的open和close函数放在名为mylib.so的共享库中,注入目标进程的代码只负责加载该.so文件,这样.so文件就和目标进程处于同一进程空间,目标进程可加载并调用其中的函数,具体流程如图3。

4.4服务器端

服务器端包括用户管理模块、密钥管理模块、同步模块和对接模块,各模块在数据库中分别维护数据表用于存储用户信息、密钥信息、文件元信息和云平台挂载信息。

用户管理模块实现用户注册、账户激活、用户登录、口令重置等基本功能。该模块中的口令仅用于用户的身份认证,与密钥管理模块中的密钥相互独立。

密钥管理模块密钥管理主要在客户端实现,服务器端仅实现密钥备份和密钥恢复。用户首次设置密钥或进行密钥重置时,客户端向服务器端发送请求对密钥进行备份。用户非首次登录但客户端没有密钥信息时,客户端向服务器请求恢复密钥。

同步模块采用集中式同步机制基于WebDav协议实现数据同步。以文件上传为例,文件的上传包括文件内容上传和文件元信息写入数据库。当服务器收到客户端请求时,首先初始化WebDav的Server并启动执行,检查客户端请求的WebDav方法和路径,上传文件为PUT方法,相应地调用httpPut函数,其中依次调用执行createFile函数创建文件、streamCopy函数将文件写入文件系统、scanFile函数获取文件元信息并写入数据库,最后将操作结果反馈给客户端。

(4)对接模块。实现数据存储平台的挂载,通过统一的文件操作接口访问存储平台中的数据。该模块分为挂载子模块和通用操作接口子模块两部分,后者提供统一的抽象数据访问接口,并针对不同的云平台具体实现接口函数。以对接Amazon S3云平台为例,服务器收到来自客户端的挂载请求和相应配置信息,首先调用构造函数创建存储实例对象,然后在Amazon S3验证用户身份,若验证通过则将挂载信息写入系统数据库,完成云平台挂载。服务器收到来自客户端的文件操作请求时,首先在数据库中查询挂载点信息,再根据请求信息调用对应云平台的接口函数,实现文件操作。对用户而言,一旦完成云平台挂载配置,即可通过客户端直接访问云平台中的资源,系统通过对接模块屏蔽了不同云平台文件访问方式的差异。

4.5数据存储平台

系统搭建了HDFS作为默认存储平台,也可对接第三方云平台如Amazon S3扩展底层存储资源。

Hadoop是Apache开源组织的一个分布式计算平台,HDFS为Apache Nutch的基础架构,具有高可靠性、高容错性和低成本等优点,适用于大规模分布式数据的处理。HDFS采用主/从架构,由一个主节点 (NameNode)和多个数据节点(DataNode)组成。NameNode为中心服务器,负责管理文件系统的元数据以及命名空间操作,如打开、关闭、重命名等,同时决定数据块到数据节点的映射。DataNode管理本节点上的数据存储,在NameNode的统一调度下对数据块进行创建、复制、删除等,并处理来自客户端的读写请求。 对外部而言,HDFS就如同一个传统的分级文件系统,可对文件进行创建、删除、重命名等操作。从内部看, 一个文件则被分为了一个或多个数据块分布存储于各个数据节点以实现容错。

Amazon S3(Amazon Simple Storage Service)是亚马逊公司提供的公开网络存储服务,用户根据实际使用的存储空间和数据流量支付费用。它基于Bucket存储数据文件,一个用户可以创建多个Bucket,每个Bucket名称都是全局唯一的。Bucket中的文件称为Object,一个Bucket可以存放多个Object。S3系统并不区分Object类型,均使用统一资源标识符(URI)进行查找和访问,每个Object均有一个唯一的URL,用户可通过该URL访问数据文件。Amazon S3没有操作界面,但提供了可编程的函数接口供应用程序在其基础上进行开发,实现对数据文件的上传、删除、重命名等基本操作。

5系统测试

5.1运行效果

依据本文方法研发的加密云存储系统已经上线运行,并向用户提供免费试用,下载链接为http:// pcloud.sklois.cn。系统的开发环境和运行环境如下。

服务器端 : CentOS release 6.4 , PHP 5.3.3 + Apache 2.2.15 + MySQL 5.1.73 +JDK 1.7.0 _ 40 。

Windows客户端 : 开发工具QT , 开发语言C++ , 运行环境Win7 / Win8 。

Android客户端:开发工具Eclipse,开发语言Java,运行环境Android2.2及以上版本。

使用目前常见的Win7系统PC和Android4.0版本手机对系统运行效果进行说明。用户登录并完成主密钥认证后进入系统主界面,如图4所示,不同终端提供了统一的数据视图。

在本系统中,用户数据在终端、传输过程和云端均以密文形式存在,当用户对文件进行打开操作时,系统后台对文件透明解密后再以明文形式呈现给用户。以PC客户端为例,当用户通过系统终端打开文件时正确显示文件内容,且用户可对其进行编辑修改,如图5(左);若不经过系统终端,直接打开本地文件则因未正确解密而显示乱码,如图5(右)。

5.2性能测试

实验测试了加密时间对文件传输的影响,测试环境:网络环境为100Mbps以太网,客户端为Intel(R)Core(TM) i7-2600CPU @ 3.40GHz、4G内存、900G硬盘,服务器为Intel(R)Xeon(R)E5-2620CPU @2.00GHz、16G内存、1T硬盘。实验统计不同大小文件的加密时间和文件上传完成的总时间,对比结果如图6所示。实验结果表明,加密时间相对于总的传输时间所占的比例很小,基本维持在2%~4%,因加密文件而引入的性能损失是可以接受的。

6结束语

加/解密 第6篇

本文研究的问题来源于黑龙江省高等教育学会“十一五”规划课题“‘财务分析’课程辅助教学专家系统的研究” (下文简称“课题”) 项目, 拟解决企业财务数据在数据库中存储时的加密和解密问题。

在课题中, 企业的财务数据在数据库中存储时有保密性的要求, 需要在软件开发过程中给以解决, 本文重点探讨在.NET平台下利用Rijndael算法实现数据加密和解密的基本原理和编程思路, 并给出基本源码解决方案。

二、Rijndael算法在.NET名称空间中的类层次结构

Rijndael算法由比利时计算机科学家Vincent Rijmen和Joan Daemen开发, 它可以使用128位、192位或者256位的密钥长度, 使得它比56位的DES算法更健壮可靠。下面介绍Rijndael算法在.NET框架名称空间中的类层次结构。

要使用Rijndael算法, 需要导入System.Security.Cryptography名称空间。图1描述了Rijndael算法在该名称空间中的类层次结构, 该层次结构分三层:

Ⅰ层的Symmetric Algorithm类是一个抽象类 (以斜体表示) , 对称算法的实现都从该抽象基类继承。

Ⅱ层的Rijndael类是基类, Rijndael对称加密算法的所有实现必须从它继承。

Ⅲ层是实现类, Rijndael Managed类访问Rijndael算法的托管版本。

三、Rijndael算法加解密实现过程

1、Rijndael算法加密实现过程

在Rijndael算法进行的加密过程中, 数据的实际流动方向是:原始数据→Rijndael加密→Base64编码→底层数据流。但是, 实际的编码过程是逆向的, 也就是说, 它要按照如下的步骤进行编码。

(1) 建立底层数据流

底层数据流通常代表我们要的输出结果, Crypto Stream类有一个很大的优势就是它可以包装多个底层数据流, 包括文件访问的File Stream、内存访问的Memory Stream和网络访问的Network Stream等。

(2) 进行Base64编码

想要加密的字符串通常要先转换成二进制数据, 得到一个字节数组, 由于该字节数组使用任何的有效值 (0~256) , 所以产生一个不良后果, 那就是我们不能把加密数据安全地嵌入到HTML页面或XML文档中, 因为它可能包含特殊的字符。为了解决这个问题, 我们需要执行执行Base64编码。

在Base64编码中, 将每个3字节序列 (共24位) 按照6位一组分成4块, 每块的取值就限制为64个字符, 它们是A~Z、a~z、0~9、+和/ (这些字符既可以显示, 又可以打印) , 然后将这些字符转换成4字节序列。Base64编码获得的好处是消除了欲加密字符串中的特殊字符, 但这是有代价的, 代价就是欲加密字符串的长度增加了33%, 因为3个源字节变成了4个输出字节。

(3) 执行Rijndael加密

要想执行Rijndael算法加密, 先要创建一个CryptoStream对象, 该对象的stream参数就是经过Base64编码的Crypto Stream对象;真正执行加密操作的是transform对象, transform对象调用Create Encryptor方法创建对称Rijndael加密器对象以完成加密操作;mode参数用来设置Crypto Stream对象的工作模式为Write (写) 模式, 即在将数据写到底层数据流之前执行Rijndael加密操作。

(4) 获取原始数据

要加密的字符串需要转换成二进制格式, 我们通常将它转换成字节数组, 具体的转换方法是通过.NET框架中某个编码类的Get Bytes方法。

(5) 源码解决方案

2、Rijndael算法解密实现过程

在Rijndael算法进行的解密过程中, 数据的实际流动方向是:欲解密数据→Base64解码→Rijndael解密→底层数据流。但是, 实际的编码过程是逆向的, 也就是说, 它要按照如下的步骤进行编码。

(1) 建立底层数据流

底层数据流通常代表我们要的输出结果, Crypto Stream类有一个很大的优势就是它可以包装多个底层数据流, 包括文件访问的File Stream、内存访问的Memory Stream和网络访问的Network Stream等。

(2) 执行Rijndael解密

要想执行Rijndael算法解密, 先要创建一个CryptoStream对象, 该对象的stream参数就是底层数据流对象, 此处就是Memory Stream对象;执行解密操作的是transform对象, transform对象调用Create Decryptor方法创建对称Rijndael解密器对象以完成解密操作;mode参数用来设置Crypto Stream对象的工作模式为Write (写) 模式, 即在将数据写到底层数据流之前执行Rijndael解密操作。

(3) 进行Base64解码

如果字符串在加密前进行过Base64编码, 那么在解密后就需要进行Base64解码, 实际的解码工作通过CryptoStream类来完成。

(4) 获取欲解密数据

要解密的字符串需要转换成二进制格式, 我们通常将它转换成字节数组, 具体的转换方法是通过.NET框架中某个编码类的Get Bytes方法。

(5) 源码解决方案

四、结束语

实践表明, 本文探讨的.NET平台下Rijndael算法的编程方案很好地解决了课题研究中财务数据的加密和解密问题, 数据保密性好, 程序执行效率高, 对有关的工程实践有较高的实用价值。

参考文献

[1]Matthew MacDonald, Eric Johansson:《C#数据安全手册》.清华大学出版社, 2003[1]Matthew MacDonald, Eric Johansson:《C#数据安全手册》.清华大学出版社, 2003

加/解密 第7篇

随着网络应用的普及,人们参与网络活动的积极性越来越高。大量的客户在网络上进行电子商务,政府、企业和军队也相继在网络上开展电子公务。这些应用对网络数据信息的安全也提出了越来越高的要求。

目前,大部分Web数据库中存储的只是明文数据或者是在数据传输过程中对数据进行加密,并没有对数据库本身进行保护,少数Web数据库采用MD5加密算法对数据进行加密。随着MD5算法的破解,一旦有非法入侵者进入数据库,将会对信息的安全产生威胁。因此,对Web数据库实施基于内容的高强度加密非常必要。AES高级加密标准算法是美国国家标准与技术研究所用于加密电子数据的规范,它被预期能成为人们公认的加密包括金融、电信和政府数字信息的方法[1]。

本文在介绍AES算法原理的基础上设计并实现了一个Web数据库加解密接口,详细阐述了各子模块的功能和实现细节,并经过实验测试给出了该Web数据库加解密接口在高负荷下AES加密算法的性能参数,为Web数据库加解密的实现提供了可行的方法。

1 Web数据库加解密需求

所谓Web数据库是指基于Web模式的信息服务数据库DBMS。它充分发挥了DBMS高效的数据存储和管理能力,以Web浏览器/服务器(B/S)模式为构架,将客户端融入统一的Web浏览器,为Internet用户提供使用简便、内容丰富的服务。

1.1 Web数据库加解密的效率需求

Web数据库的特点就是用户请求数多、数据信息量大。在某一特殊时刻Web数据库的访问等候序列可能会达到数万到数百万个。针对Web数据库基于内容的加解密必须是快速的。因此,在数据库服务器硬件性能一定的条件下,选择一个快速高效的加解密算法成为提高Web数据库加解密接口运行效率的关键。

1.2 Web数据库加解密的安全需求

当更多的企业、银行、政府的办公和电子商务应用于网络后,Web数据库的信息安全需要不言而喻,数据信息的安全直接关系着企业和个人的利益。目前,大多数实行加密的Web数据库还采用MD5算法进行加解密,存在着很大的安全隐患。Web数据库加解密的安全准则与效率准则互补,要提高Web数据库加解的安全性能,就必须以牺牲运行效率为代价。因此,在使用中要根据应用环境和实际条件来在两者之间作出适当地平衡。

2 AES算法介绍

2.1 AES算法基本原理

AES算法基于排列和置换运算。排列是对数据重新进行安排,置换是将一个数据单元替换为另一个。AES 使用几种不同的方法来执行排列和置换运算。AES是一个迭代的、对称密钥分组的密码,它可以使用128、192和256位密钥,并且用128位(16字节)分组加密和解密数据。与公共密钥密码使用密钥对不同,对称密钥密码使用相同的密钥加密和解密数据。通过分组密码返回的加密数据的位数与输入数据相同。迭代加密使用一个循环结构,在该循环中重复置换和替换输入数据。

2.2 AES算法的流程

AES的加密过程包括初始一个密钥扩展,再进行一个轮密钥加法,记作AddRoundKey,接着进行Nr-1次轮变换Round,最后再使用一个轮变换FinalRound。轮变换包括字节替换SubBytes、行位移变换ShiftRows、列混合变换MixColumns和轮密钥加AddRoundKey四个变换,最后一次轮变换包括字节替换SubBytes、行位移变换ShiftRows和轮密钥加AddRoundKey三个变换。初始的密钥加法和每个轮变换均以状态State和一个轮密钥作为输入。第i轮的轮密钥记为ExpandedKey[i],初始密钥加法的输入记为ExpandedKey[0]。从CipherKey导出ExpandedKey的过程记为KeyExpansion。AES加密的高级算法伪码如下:

2.3 密钥扩展与AES算法的变换

(1) 密钥扩展

密钥扩展是指如何由密码密钥得到扩展密钥。由于该密码要求一个轮密钥用于初始密钥加法,而且每轮都需要一个轮密钥,因此扩展密钥中的全部比特数等于分组长度乘以轮数加1。在密钥扩展阶段,将密码密钥扩展成4行Nb(Nr+1)列的扩展密钥数组,这里用W[4][Nb(Nr+1)]来表示。第i轮的轮密钥ExpandedKey[i]由W中的第Nb·(i+1)-1列给出:

ExpandedKey[i]=W[·][Nb·i]||W[·][Nb·i+1]||…||W[·][Nb·(i+1)-1] 0≤i≤Nr[1]

(2) 字节替换SubBytes

SubBytes是AES加密算法中唯一的非线性变换。它是一个砖匠置换,该置换包括一个作用状态字节上的S-盒(用SRD表示)。SubBytes变换是一个代替操作,它将State矩阵中的每个字节替换成一个由S-盒决定的新字节。比如,如果State[0,1]的值是0x40,想找到它的代替者,则取State[0,1]的值(0x40),并让x等于左边的数字(4),再让y等于右边的数字(0)。然后用x和y作为索引到S-盒中寻找代替值。图1表示了SubBytes变换对于状态的影响。

(3) 行位移变换ShiftRows

行位移变换ShiftRows是一个字节换位操作,它将状态中的行按照不同的偏移量进行循环移位。第0行移动C0字节,第1行移动C1字节,第2行移动C2字节,第3行移动C3字节,从而使得第i行第j位的字节移动到(j-Ci)Mod Nb。移动偏量C0、C1、C2和C3依赖于Nb的取值。图2表示了ShiftRows变换对于状态的影响。

(4) 列混合变换MixColumns

MixColumns是一个代替操作,它用State字节列的值进行数学域加和域乘的结果代替每个字节。图3表示了MixColumns变换对于状态的影响。

(5) 轮密钥加AddRoundKey

AddRoundKey用密钥调度表中的前四行对State矩阵实行一个字节一个字节的异或(XOR)操作,并用轮密钥表w[c,r]异或输入State[r,c]。轮密钥记作ExpandedKey[i],0≤i≤Nr。轮密钥由密码密钥通过密钥编排方案导出,轮密钥长度等于分组长度。图4表示了AddRoundKey变换对于状态的影响。

3 加解密接口的设计与实现

3.1 加解密接口的结构

文献[2]中提出的数据库加密系统基本结构由六部分组成:加密字典管理程序、加密系统应用程序、数据库加脱密引擎、数据库服务器、加密字典和用户数据等。在此基础上,本文设计出的Web数据库加解密接口由Web服务程序接口、调度中心、数据字典、加解密模块、密钥管理和数据库访问接口六部分组成。其应用框架和接口的基本结构如图5所示。图中的虚框内部分为本文所设计的加解密接口结构。

3.2 加解密接口子模块功能描述

(1) Web服务程序接口的功能

提供各种Web服务程序的数据接入与输出,使得用户数据的加解密过程对用户透明,该接口的数据流向是双向的。在加密过程中用户通过终端设备将数据发送至Web服务程序,Web服务程序用指定的端口号将用户数据转交给Web服务程序接口,由加解密模块对数据进行加密。在解密的过程中,加解密模块将生成的明文通过Web服务程序接口发送给Web服务程序,Web服务程序再将数据转交给用户。

(2) 调度中心模块的功能

为特殊用户或特殊服务提供服务质量保证QoS。模块会根据用户加/解密请求中所设置的优先级对服务请求队列进行排序,这样在高负荷网络服务请求下可以保证最重要的数据信息先被加/解密。

(3) 数据字典模块的功能

将初始化接口时的一些参数在加密和解密时提供给加解密模块使用,这些参数一般是单独保存在数据字典中。数据的主要内容包括分组长度、密钥长度、加解密轮数、S-盒、优先级别、数据类型、密钥控制方式、是否加密和程序运行的其它初始化数据等等。

(4) 密钥管理模块的功能

提供给加解密模块相关的密钥验证与保护。在本文的数据库加解密接口中,采用的是数据项加密的方式来对数据库的数据进行保护,在实现时密钥管理模块提供的密钥包括表密钥Table_Key和数据项加解密密钥Item_Key。表密钥Table_Key对应任何一个需要加密的数据库表,在加密时由系统根据混沌理论自动生成[3],对用户密钥和表密钥的保护采用的是主密钥[4]方式进行保护。应用中可能使用的密钥方式有两种,一种是服务器集中控制一个统一的密钥,应用时由Web数据库管理员来在服务器端输入设置;另一种是每个用户分别拥有不种的密钥,一个用户的密钥不能对另一个用户数据进行加解密操作。管理这两种密钥控制方式也将由密钥管理模块来完成。

(5) 数据库连接模块的功能

将支持的所有访问数据库的操作封装在一起,屏蔽了各类数据库的操作特性。加解密接口工作时不必关心实际使用的是哪种数据库,提高了程序使用的通用性。此模块设计时的连接方式采用的是OLE DB的方式,这个方式的好处是连接方便,不需要注册数据源只需要连接字符串就可以连接到相应类型的数据库。

(6) 加解密模块的功能

加解密模块是整个Web数据库加解密接口的核心。在AES高级加密标准算法中,S-盒作为唯一的非线性运算,直接决定算法的安全性能[5]。本接口在设计时采用文献[5]所设计的改进后的S-盒代替了标准AES算法的S-盒,增强了加解密的安全性能。密钥的长度和轮数直接决定了算法的运行速度,加解密模块在设计的时候允许用户选择密钥长度,算法根据用户对密钥长度的选择自动选取相应的轮数来保证运算的安全指标和速度指标。加解密接口的运行流程如图6所示。

3.3 加解密接口关键部分实现

在以上理论的前提下,本文用C语言实现了该Web数据库加解密接口。在整个接口结构中调度中心模块负责服务请求调度,直接影响着接口应用的合理性,加解密模块影响着接口的运行性能。下面对这两个模块作详细阐述。

(1) 调度中心的实现

为了根据网络服务请求中的优先级对请求服务队列进行高效排序,在实现时采用了Hash表、链表和顺序表三种数据结构。采用Hash表拉链法对网络服务请求进行排序、查找、插入和删除。接口初始化运行时生成一个Hash表,网络服务请求的优先级相当于散列地址,把具有相同优先级的服务请求存放在同一个链表中。有m个优先级就有m个链表,同时用顺序表(数组t[MAX])存放各个链表的头指针,顺序表的长度就是散列表的长度,另外申请存储空间存储具有相同优先级的服务请求链表。

调度中心消耗的存储空间大小取决于Web服务器管理员对服务等待序列的限定值,服务请求链表的大小也根据服务等待序列的多少自动分配。当网络服务请求队列为100万时,假如分组大小和密钥长度均为256位,那么满链表存储空间大小约为64MB,新进服务请求插入链表的时间也是毫秒级,既能满足应用中的速度需求,又不会对存储空间构成威胁。

(2) 加解密模块的实现

为了实现有限域乘GF(28),本接口定义了两个无符号字符型数组Logtable和Alogtable数组:

typedef unsigned char word;

word Logtable[256];

word Alogtable[256];

S-盒、逆S-盒也采用无符号字符型数组,轮常量RC[j]采用无符号整型数组,在接口程序初始化时保存在数据字典中被算法后续调用。

列混合运算MixColumns和其逆运算均需调用两个元素的域乘运算函数mul,核心代码如下:

4 安全性能分析与运行效率测试

4.1 安全性能分析

本文设计的Web数据库加解密接口除了抗线性攻击能力增强外,抗其它攻击能力均与标准AES算法相同。

非线性度是衡量密码系统抗线性攻击能力强弱的指标,非线性度越高安全性能就越强,但当非线性度达到最高时,其它性能将变弱。本接口使用的S-盒[5]其代数性质与文献[1]所使用的S-盒的代数性质对比如表1所示。

4.2 运行效率测试

当前的密码分析研究表明,迭代型分组密码抗击密码分析攻击能力随着轮数的增加而增加。文献[1]设计的AES标准算法中设定当分组和密钥长度为128bit时轮数为10,当分组和密钥长度为192bit时轮数为12,当分组和密钥长度为256bit时轮数为14。经实验测试,本文设计的Web数据库加解密接口当网络服务请求等待队列为100万个时,在windows 2000 sp4、Intel CPU 2.00GHz、512MB内存实验环境下,对单位密钥长度分组的加解密速度如表2所示。

在一般商用网络服务中,由于对信息的安全性要求相对较低,用户访问量大,服务器负荷较重,可以考虑采用128位的分组长度和密钥长度,采用10轮来进行加密和解密。在军队、政府和金融领域相对要求安全性能较高的网络环境下,采用192位的分组长度和密钥长度采用12轮加密和解密,由于目前还没有任何方法可以成功攻击AES算法,所以采用较短的密钥长度既能保证数据的安全又能提供快速高效的服务;对于256位的分组和密钥长度加密方式期望用于并行处理机或者网格计算环境。

5 结 论

本文结合高级加密标准算法AES,介绍了Web数据库加解密接口的设计和和实现。对Web数据库加解密接口进行了结构设计并对各子功能模块进行了详细设计和说明,同时结合实践给出了实际应用时选取密钥长度和轮数的建议。实践应用证明本文设计的基于AES算法的Web数据库加解密接口具有良好的安全性能和运算性能。下一步的研究方向是Web数据库加解密接口与大型网络应用系统的集成。

摘要：对Web数据库基于内容的重要数据加密是保证信息可靠与安全的关键。设计实现了一个基于AES(The Advanced En-cryption Standard)高级加密标准算法的Web数据库加解密接口,并详细阐述了接口中各子功能模块的功能与实现细节,测试实验表明该接口在高负荷网络访问环境下具有良好的加解密效率,增强了Web数据库的安全性能。最后给出了应用时合理化的加密算法参数建议,为Web应用环境下的数据库加解密提供了思路和方法。

关键词：AES算法,Web数据库,加密,加解密接口

参考文献

[1]谷大武,徐胜波.高级加密标准(AES)算法——Rijndael的设计[J].北京:清华大学出版社,2003.

[2]朱鲁华,陈容良.数据库加密系统的加密和实现[J].计算机工程,2002,28(8):61-63.

[3]宋雨,赵文清.密钥管理在管理信息系统中的应用研究[J].计算机工程与应用,1990(10):95-97.

[4]余祥宣,倪晓俊.加密数据库系统中的密钥管理[J].华中理工大学学报,1995(7).