基于Windows平臺(tái)的加密傳輸庫設(shè)計(jì)與實(shí)現(xiàn)

袁梁

基于Windows平臺(tái)的加密傳輸庫設(shè)計(jì)與實(shí)現(xiàn)

袁梁

（無錫城市職業(yè)技術(shù)學(xué)院 師范學(xué)院，江蘇 無錫 214000）

在Windows端和Linux端之間采用非對稱算法進(jìn)行數(shù)據(jù)加密傳輸時(shí)，為有效避免由于引入第三方代碼庫而增加程序體積和安全風(fēng)險(xiǎn)，提出了一種基于Windows平臺(tái)的加密傳輸庫winSSL設(shè)計(jì)與實(shí)現(xiàn)方法．winSSL的實(shí)現(xiàn)思路是在Windows平臺(tái)下利用Windows安全服務(wù)接口實(shí)現(xiàn)SSL/TSL協(xié)議的初始化、握手認(rèn)證、數(shù)據(jù)傳輸、結(jié)束傳輸?shù)冉涌诤瘮?shù)．采用winSSL庫實(shí)現(xiàn)的客戶端程序可與OpenSSL服務(wù)端程序無縫對接．實(shí)驗(yàn)表明，winSSL程序體積相比OpenSSL程序，文件壓縮比率達(dá)到了1/19，相比其他OpenSSL替代庫，程序體積也有明顯改善，而在傳輸效率上卻沒有損失．

加密傳輸；winSSL；OpenSSL；Schannel；SSL/TSL

在采用非對稱算法對數(shù)據(jù)傳輸進(jìn)行加密方面，目前最流行的加密庫是OpenSSL[1]．OpenSSL是一個(gè)開放源代碼的SSL/TSL安全套接字層密碼庫，其函數(shù)庫以C語言寫成，實(shí)現(xiàn)了傳輸層數(shù)據(jù)加密功能，對SSL和TLS各流行版本均支持．目前，絕大多數(shù)Linux發(fā)行版都有集成OpenSSL套件，在Linux平臺(tái)采用OpenSSLAPI進(jìn)行數(shù)據(jù)加密傳輸開發(fā)和運(yùn)行都相當(dāng)方便．然而對于師范院校教學(xué)機(jī)房學(xué)生Windows終端上網(wǎng)行為的無感監(jiān)控項(xiàng)目來說，OpenSSL就顯得力不從心了，該項(xiàng)目的目的是將加密程序以遠(yuǎn)程線程方式注入到瀏覽器主進(jìn)程中，實(shí)時(shí)回傳學(xué)生課堂上網(wǎng)瀏覽痕跡到后臺(tái)服務(wù)器．在Windows平臺(tái)下，采用OpenSSL進(jìn)行加密數(shù)據(jù)傳輸時(shí)，需要重新編譯OpenSSL源代碼，在項(xiàng)目工程中引入編譯生成的頭文件和庫文件，最終完成的加密程序運(yùn)行時(shí)需要附帶libeay32.dll和ssleay32.dll２個(gè)動(dòng)態(tài)庫．但是當(dāng)加密程序注入進(jìn)瀏覽器主進(jìn)程后，當(dāng)前路徑發(fā)生改變，并不能調(diào)用到動(dòng)態(tài)庫，導(dǎo)致程序運(yùn)行失敗；如果采用靜態(tài)編譯方式將2個(gè)動(dòng)態(tài)庫編譯進(jìn)加密程序，最精簡編譯后，程序體積也將有1.14 M左右，這對遠(yuǎn)程線程注入技術(shù)來說，體積過于龐大，將直接影響瀏覽器的穩(wěn)定運(yùn)行．因此，OpenSSL顯然是不合適本項(xiàng)目的．為有效避免由于引入第三方代碼庫而增加的程序體積，以及第三方代碼庫帶來新的安全風(fēng)險(xiǎn)，本文提出了一種基于Windows安全服務(wù)接口的加密傳輸庫winSSL設(shè)計(jì)與實(shí)現(xiàn)方法，該技術(shù)的主要思路是在Windows平臺(tái)下利用Windows安全服務(wù)接口實(shí)現(xiàn)SSL/TSL協(xié)議的初始化、握手認(rèn)證、數(shù)據(jù)傳輸、結(jié)束傳輸?shù)冉涌诤瘮?shù)．經(jīng)實(shí)驗(yàn)測試，在Windows客戶端對程序采用winSSL加密，在Linux服務(wù)端對程序采用OpenSSL加密，兩者可實(shí)現(xiàn)無縫對接．

1　相關(guān)研究

1.1　SSL/TSL及OpenSSL

SSL/TSL協(xié)議是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議，用于建立服務(wù)器和客戶端之間的加密連接．SSL/TSL通過雙向身份認(rèn)證確保數(shù)據(jù)的完整性，通過協(xié)商加密算法確保數(shù)據(jù)的私密性[2]．SSL/TSL協(xié)議實(shí)現(xiàn)過程大致包括3個(gè)階段，即初始握手、應(yīng)用對話和結(jié)束握手．初始握手階段，進(jìn)行SSL/TSL庫上下文環(huán)境的初始化，載入證書私鑰，進(jìn)行密鑰交換與協(xié)商，建立安全通信環(huán)境；應(yīng)用對話階段，對數(shù)據(jù)進(jìn)行加解密和傳輸，SSL/TSL通過這一過程為應(yīng)用程序的數(shù)據(jù)傳輸提供了安全通道；結(jié)束握手階段，結(jié)束數(shù)據(jù)傳輸，關(guān)閉并釋放套接字，釋放上下文環(huán)境[3]．

根據(jù)SSL/TSL協(xié)議原理，OpenSSL庫同時(shí)實(shí)現(xiàn)了客戶端與服務(wù)器的編程開發(fā)接口，客戶端和服務(wù)端均采取OpenSSL API進(jìn)行加密通信的大致流程見圖1[4]．

圖1 使用OpenSSL API建立SSL/TSL通信的流程

1.2　OpenSSL替代庫

在致力于OpenSSL輕巧性方面，近年來國外的研究機(jī)構(gòu)、企業(yè)、學(xué)者都在這個(gè)方向的研究取得了顯著的成績．其中比較著名的替代庫有Google公司的boringSSL，OpenBSD開發(fā)者的LibreSSL，ARM 公司的mbedTLS（前身 PolarSSL）以及美國wolfSSL公司的wolfSSL（前稱CyaSSL）．然而boringSSL并不能保證API或ABI的穩(wěn)定性，可用性較差[5]．LibreSSL是對OpenSSL代碼的重構(gòu)，刪除了一些陳舊或無用的代碼，同時(shí)對一些比較罕見的操作系統(tǒng)的支持代碼也被移除了，但代碼體積依然龐大[6]．mbedTLS和wolfSSL是目前最流行、最成熟的輕量級OpenSSL替代庫，都是基于C語言的開源SSL/TLS庫，專門針對OpenSSL難以涉及的嵌入式環(huán)境[7-8]．然而在Windows下依賴默認(rèn)mbedTLS和wolfSSL靜態(tài)庫編譯的加密程序依然在100 K以上，必須對mbedTLS和wolfSSL的功能模塊進(jìn)行相應(yīng)的裁剪，才能滿足項(xiàng)目幾十KB的要求，然而由于在Windows平臺(tái)下引入了第三方開源庫，且進(jìn)行了模塊裁剪，必將進(jìn)一步增加項(xiàng)目的安全風(fēng)險(xiǎn)系數(shù)．近年來，黑客組織不斷爆出mbedTLS和wolfSSL的安全漏洞，如mbedTLS的CVE-2017-2784，CVE-2018-1000520，CVE-2018-0498等漏洞，以及wolfSSL的CVE-2020-24613，CVE-2020-15309，CVE-2020-11735等漏洞[9]．因此，為避免由于引入第三方加密庫增加的程序體積和安全風(fēng)險(xiǎn)問題，本文提出了一種基于Windows安全服務(wù)接口的加密傳輸庫winSSL．winSSL通過對Windows安全服務(wù)接口的二次封裝，實(shí)現(xiàn)SSL/TSL協(xié)議的初始化、握手認(rèn)證、數(shù)據(jù)傳輸、結(jié)束傳輸?shù)认盗薪涌诤瘮?shù)，極大地縮小了加密程序體積．

2　Windows安全服務(wù)接口

2.1　Schannel及CryptoAPI

Schannel又稱Secure Channel，是SSPI（Security Support Provider Interface）的一個(gè)子集，是一個(gè)Win32 API接口，用于為傳輸層應(yīng)用程序和網(wǎng)絡(luò)安全服務(wù)提供安全接口．其主要特性是為應(yīng)用程序提供一個(gè)公用的API接口來使用不同的安全包，包括Windows NTLM驗(yàn)證、Kerberos安全驗(yàn)證提供器以及SSL/PCT公用密鑰密碼技術(shù)提供器[10]，從而使程序開發(fā)者能夠直接調(diào)用SSPI函數(shù)來集成WindowsNT的安全性．這個(gè)組件集成于微軟所有Windows平臺(tái)中，并且大多數(shù)Windows服務(wù)和軟件都在使用它，如IIS，OWA，Exchange，tive Directory，IE，WindowsUpdate等[11]．

CryptoAPI（Cryptography API）是Windows加密服務(wù)提供程序（CSP）的應(yīng)用程序編程接口，是Windows系統(tǒng)中的 PKI 的編程接口，CryptoAPI提供了一組函數(shù)功能，包括加密、解密、編碼、解碼、哈希、數(shù)字證書、證書存儲(chǔ)和證書管理等功能．CryptoAPI函數(shù)允許程序開發(fā)者以靈活的方式對數(shù)據(jù)進(jìn)行加解密或數(shù)字簽名，而實(shí)際的加解密操作是由CSP執(zhí)行，CSP完成數(shù)據(jù)加密、解密以及密鑰存儲(chǔ)管理等工作，CSP中的功能模塊相互獨(dú)立，調(diào)用相當(dāng)方便．Schannel使用CryptoAPI進(jìn)行加解密、公/私鑰存儲(chǔ)以及證書管理等操作．

2.2　winSSL客戶端接口設(shè)計(jì)

要在Windows平臺(tái)下利用Windows安全服務(wù)接口實(shí)現(xiàn)SSL/TLS加密傳輸開發(fā)接口，并且可與OpenSSL加密通信無縫對接，需要用Windows安全服務(wù)接口實(shí)現(xiàn)與OpenSSL建立加密通信所需API一一對應(yīng)的接口函數(shù)．以winSSL客戶端接口函數(shù)為例，利用Windows安全服務(wù)接口，主要是利用Schannel和CryptoAPI接口實(shí)現(xiàn)winSSL客戶端接口函數(shù)．接口函數(shù)和主要流程過程見圖2．

圖2 OpenSSL服務(wù)端和Windows客戶端建立SSL/TSL通信過程

本文將winSSL客戶端通信細(xì)分為4個(gè)階段，即初始化安全通信準(zhǔn)備階段、建立交互握手階段、安全通信階段、結(jié)束階段．主要接口函數(shù)包括InitSSL，SSL_W_SET，ClientHandshake，SSLSend、SSLReceive，SSLClose等API．為了保證編程實(shí)現(xiàn)的winSSL加密傳輸庫具有足夠的版本適應(yīng)性和輕巧性，本文以VC6.0+Platform SDK為開發(fā)環(huán)境，以C+API的方式進(jìn)行開發(fā)．

3　winSSL客戶端接口實(shí)現(xiàn)

3.1　全局變量定義

除了定義標(biāo)識(shí)、字符串常量PBYTE pbIoBuffer、DWORD cbIoBuffer、DWORD cbIoBufferLength外，本文需要定義HCERTSTORE hCertStore，PSecurityFunctionTable g_pSSPI，Schannel_CRED SchannelCred 3個(gè)重要的全局變量．HCERTSTORE是CryptoAPI的數(shù)據(jù)結(jié)構(gòu)，用于實(shí)現(xiàn)對Windows客戶端證書和公私鑰的存儲(chǔ)與訪問；PSecurityFunctionTable是一個(gè)函數(shù)分派表，包含指向SSPI中定義的函數(shù)的指針；Schannel_CRED定義了Schannel憑證數(shù)據(jù)結(jié)構(gòu)．

typedef struct _Schannel_CRED {

DWORD dwVersion；

DWORD cCreds；

PCCERT_CONTEXT* paCred；

HCERTSTORE hRoot Store；

DWORD cMappers；

struct _HMAPPER** aphMappers；

DWORD cSupportedAlgs；

ALG_ID* palg Supported Algs；

DWORD grbit Enabled Protocols；

DWORD dw Minimum Cipher Strength；

DWORD dw Maximum Cipher Strength；

DWORD dw Session Lifespan；

DWORD dw Flags；

DWORD reserved；

} Schannel_CRED， *PSchannel_CRED．

Schannel憑據(jù)在內(nèi)部表示為CERT_CONTEXT結(jié)構(gòu)．Schannel使用證書的CERT_KEY_ PROV_ INFO_

PROP_ID屬性來定位與特定證書上下文相關(guān)聯(lián)的私鑰，使用此屬性，Schannel通過調(diào)用CryptAcquireContext函數(shù)訪問私有密鑰．客戶端私鑰由正在使用的加密服務(wù)提供程序（CSP）管理，客戶端私鑰通常由類型為PROV_RSA_FULL或PROV_RSA_SIGNATURE的CSP存儲(chǔ)．

3.2　初始化安全通信準(zhǔn)備階段

InitSSL接口函數(shù)用于實(shí)現(xiàn)winSSL的安全通信初始化，主要包括LoadSecurityLibrary和CreateCredentials 2個(gè)函數(shù)，LoadSecurityLibrary主要是實(shí)現(xiàn)對所有的Schannel和SSPI的安全庫進(jìn)行加載并初始化安全接口，核心代碼為：

HMODULE g_hSecurity=LoadLibrary（"Secur32.dll"）；

INIT_SECURITY_INTERFACE pInitSecurityInterface =（INIT_SECURITY_INTERFACE）GetProcAddress（g_hSecurity，"Init Security InterfaceA"）；

g_pSSPI = pInitSecurityInterface()；

CreateCredentials用于實(shí)現(xiàn)全局變量SchannelCred的初始化，并將結(jié)構(gòu)體傳遞給函數(shù)AcquireCredentialsHandleA，以獲取使用Schannel的安全主體的預(yù)先存在憑據(jù)的句柄phCreds，此句柄是InitializeSecurityContext函數(shù)所必需的，核心代碼為：

PCCERT_CONTEXT pCertContext = NULL；

PCredHandle phCreds=NULL；

hCertStore = CertOpenStore（CERT_STORE_PROV_MEMORY，0，NULL，0，NULL）；

SchannelCred.dwVersion = Schannel_CRED_VERSION；

if（pCertContext）

{

SchannelCred.cCreds = 1；

SchannelCred.paCred= &pCertContext；

}

SchannelCred.grbitEnabledProtocols = SP_PROT_SSL3；

SchannelCred.dwFlags |= SCH_CRED_MANUAL_CRED_VALIDATION；

SECURITY_STATUS Status = g_pSSPI->AcquireCredentialsHandleA（NULL，UNISP_NAME_A， SECPKG_CRED_OUTBOUND，NULL，&SchannelCred，NULL，NULL，phCreds，NULL）．

3.3　建立交互握手階段

建立交互握手階段包含SSL_W_SET和ClientHandshake2個(gè)接口，SSL_W_SET接口函數(shù)用于將TCP套接字與SSL套接字上下文進(jìn)行關(guān)聯(lián)．ClientHandshake接口函數(shù)用于實(shí)現(xiàn)符合標(biāo)準(zhǔn)的SSL/TSL三次握手過程，主要包括Windows客戶端獲取Linux服務(wù)端含有公鑰的證書和確定雙方數(shù)據(jù)加密的會(huì)話密鑰．ClientHand-

shake接口函數(shù)包含２個(gè)主要函數(shù)，PerformClientHandshake和ClientHandshakeLoop，PerformClientHandshake用于向服務(wù)器發(fā)起握手請求，函數(shù)核心代碼為：

SecBufferDesc OutBuffer；

SecBuffer OutBuffers[1]；

SecBuffer pExtraData

OutBuffers[0].BufferType = SECBUFFER_TOKEN；

OutBuffers[0].cbBuffer = 0；

OutBuffer.cBuffers = 1；

OutBuffer.pBuffers = OutBuffers；

OutBuffer.ulVersion = SECBUFFER_VERSION；

scRet = g_pSSPI->InitializeSecurityContextA（phCreds，NULL，pszServerName，dwSSPIFlags，0，

SECURITY_NATIVE_DREP，NULL，0，phContext，&OutBuffer，&dwSSPIOutFlags，NULL）；

send（Socket，OutBuffers[0].pvBuffer，OutBuffers[0].cbBuffer，0）；

return ClientHandshakeLoop（Socket，phCreds，phContext，TRUE，pExtraData）．

其中ClientHandshakeLoop函數(shù)內(nèi)部是一個(gè)循環(huán)過程，用于實(shí)現(xiàn)三次握手的后續(xù)幾次交互，其實(shí)現(xiàn)過程與PerformClientHandshake函數(shù)流程基本類似，主要是增加了receive函數(shù)過程InBuffer的安全數(shù)據(jù)結(jié)構(gòu)，以及在握手過程中利用InBuffer，OutBuffer，pExtraData對包括phContext在內(nèi)的結(jié)構(gòu)體和上下文進(jìn)行初始化．

3.4　安全通信階段

安全通信階段實(shí)現(xiàn)了SSLSend和SSLReceive接口函數(shù)，SSLSend負(fù)責(zé)對通信數(shù)據(jù)加密，并將加密數(shù)據(jù)發(fā)送給服務(wù)器，SSLReceive負(fù)責(zé)從服務(wù)器接受數(shù)據(jù)，并對數(shù)據(jù)進(jìn)行解密，SSLSend核心代碼為：

SecBufferDesc Message；

SecBuffer Buffers[4]；

PBYTE pbMessage；

DWORD cbMessage；

g_pSSPI->QueryContextAttributes（phContext，SECPKG_ATTR_STREAM_SIZES，&Sizes）；

Buffers[0].pvBuffer = pbIoBuffer；

Buffers[0].cbBuffer = Sizes.cbHeader；

Buffers[0].BufferType = SECBUFFER_STREAM_HEADER；

Buffers[1].pvBuffer = pbMessage；

Buffers[1].cbBuffer = cbMessage；

Buffers[1].BufferType = SECBUFFER_DATA；

Buffers[2].pvBuffer = pbMessage + cbMessage；

Buffers[2].cbBuffer = Sizes.cbTrailer；

Buffers[2].BufferType = SECBUFFER_STREAM_TRAILER；

Buffers[3].BufferType = SECBUFFER_EMPTY；

Message.ulVersion = SECBUFFER_VERSION；

Message.cBuffers = 4；

Message.pBuffers = Buffers；

g_pSSPI->EncryptMessage（phContext，0，&Message，0）；

cbData = send（Socket，pbIoBuffer，Buffers[0].cbBuffer + Buffers[1].cbBuffer + Buffers[2].cbBuffer，0）.

SSLReceive函數(shù)實(shí)現(xiàn)過程可參照SSLSend，變量定義基本一致，唯一不同的是SSLReceive先接受數(shù)據(jù)，再對加密數(shù)據(jù)進(jìn)行安全結(jié)構(gòu)體賦值，最后解密數(shù)據(jù)．

3.5　結(jié)束階段

在結(jié)束階段，SSLclose接口函數(shù)通過構(gòu)造安全結(jié)構(gòu)體向服務(wù)器發(fā)送關(guān)閉連接信號，斷開與服務(wù)器的連接；通過調(diào)用CertFreeCertificateContext釋放證書上下文環(huán)境；通過調(diào)用g_pSSPI->DeleteSecurityContext刪除hContex結(jié)構(gòu)體，通過調(diào)用g_pSSPI->FreeCredentialsHandle釋放SSPI憑證；調(diào)用CertCloseStore關(guān)閉證書庫，最后釋放安全上下文環(huán)境．

4　實(shí)驗(yàn)

不同SSL/TSL庫在Windows平臺(tái)下，對同一個(gè)傳輸程序加密實(shí)現(xiàn)的客戶端程序體積對比實(shí)驗(yàn)見圖3．其中winSSL客戶端程序在VC6.0編譯環(huán)境默認(rèn)設(shè)置下，Release版本只有60 k；OpenSSL在Windows下生成的最精簡的控制臺(tái)程序是1.14 M；mbedTLS和wolf SSL默認(rèn)靜態(tài)鏈接依賴庫生成的客戶端程序分別達(dá)到了120 k和148 k．winSSL程序相比OpenSSL程序，文件壓縮比率達(dá)到了1/19，程序體積得到量級壓縮，輕巧性大大提高，相比mbedTLS和wolfSSL程序，程序體積也有明顯改善．同時(shí)經(jīng)過測試winSSL客戶端程序可在從Windows XP至Windows Server 2022的所有個(gè)人版和服務(wù)器版的Windows平臺(tái)上獨(dú)立運(yùn)行，通用性很強(qiáng)．

圖3 不同SSL/TSL庫實(shí)現(xiàn)的程序體積對比

不同SSL/TSL庫在Windows平臺(tái)下，對同一對傳輸程序進(jìn)行的4組加密傳輸效率對比實(shí)驗(yàn)見圖4．第1組是在Windows7上運(yùn)行winSSL客戶端程序，在Linux上運(yùn)行OpenSSL服務(wù)器程序；第2組是在Windows7上運(yùn)行OpenSSL 客戶端程序，在Linux上運(yùn)行OpenSSL服務(wù)器程序；第3組是在Windows7上運(yùn)行mbedTLS 客戶端程序，在Linux上運(yùn)行mbedTLS服務(wù)器程序；第4組是在Windows7上運(yùn)行wolfSSL客戶端程序，在Linux上運(yùn)行wolfSSL服務(wù)器程序．實(shí)驗(yàn)所用Windows7虛擬機(jī)配置均為雙核CPU，2 G內(nèi)存，Linux虛擬機(jī)配置均為Ubuntu 18.04，雙核CPU，2G內(nèi)存．每組實(shí)驗(yàn)分別進(jìn)行體積約為１，1.5，2，2.5，3 G5個(gè)大文件的傳輸并記錄時(shí)間．以2.5 G文件傳輸為例，winSSL傳輸時(shí)間約為141 s，OpenSSL傳輸時(shí)間約為143 s，mbedTLS傳輸時(shí)間約為140 s，wolfSSL傳輸時(shí)間約為145 s．實(shí)驗(yàn)表明，4種SSL/TSL庫在數(shù)據(jù)傳輸效率上很接近，winSSL略遜于mbedTLS，略好于OpenSSL和wolfSSL．

圖4 不同SSL/TSL庫實(shí)現(xiàn)的程序傳輸效率對比

5　結(jié)論

在本項(xiàng)目進(jìn)行過程中，同時(shí)也實(shí)現(xiàn)了winSSL加密傳輸庫的服務(wù)端接口，主要接口函數(shù)包括InitSSL，SSL_W_SET，ServerHandshake，SSLSend，SSLReceive，SSLClose等API．然而由于本項(xiàng)目的主要應(yīng)用場景是針對Windows客戶端與Linux服務(wù)端的加密傳輸，以及篇幅限制問題，沒有在此展開一一敘述，其實(shí)現(xiàn)過程與利用OpenSSL實(shí)現(xiàn)SSL/TSL服務(wù)端程序是對等的．但是積極的意義是，通過該項(xiàng)目實(shí)現(xiàn)了完整的基于Windows平臺(tái)的加密傳輸庫winSSL．winSSL由于是利用Windows安全服務(wù)接口實(shí)現(xiàn)的二次接口封裝庫，其本身沒有專注于加密算法和數(shù)據(jù)傳輸?shù)倪壿嫾?xì)節(jié)，而是集成了Winsows系統(tǒng)自身提供的非對稱加密算法和數(shù)據(jù)傳輸服務(wù)，代碼量得到了極大縮減．因此，winSSL實(shí)現(xiàn)的程序在體積上要遠(yuǎn)遠(yuǎn)小于OpenSSL，相比mbedTLS和wolfSSL，體積也有明顯改善．同時(shí)也避免了在Windows平臺(tái)下由于引入第三方代碼庫而增加的安全風(fēng)險(xiǎn)問題．winSSL今后可廣泛應(yīng)用于涉及Windows平臺(tái)的數(shù)據(jù)加密傳輸．

[1] 楊柳，王耀青，張劍龍．基于Linux的文件加密傳輸技術(shù)[J]．計(jì)算機(jī)測量與控制，2015，23（12）：4161-4163，4167．

[2] 何文才，關(guān)少華，薛晗，等．一種基于網(wǎng)絡(luò)的文件加密方法的研究與實(shí)現(xiàn)[J]．通信技術(shù)，2014，47（8）：946-950．

[3] 王志海．OpenSSL與網(wǎng)絡(luò)信息安全[M]．北京：清華大學(xué)出版社，2007．

[4] 宋敬彬．Linux網(wǎng)絡(luò)編程[M]．2版．北京：清華大學(xué)出版社，2021．

[5] ERBSEN A，PHILIPOOM J，GROSS J，et al．Simple High-Level Code For Cryptographic Arithmetic：With Proofs，Without Compromises[J]．Operating systems review，2020，54（1）：23-30．

[6] Floeter R．Introducing OpenBSD′s new httpd[C]//The Technical BSD Conference，2015：62-70．

[7] wolfSSL．wolfSSL embedded SSL/TLS library[EB/OL]．[2022-04-01]．https:// www.Wolfssl.com/products/wolfssl/ Cve.cve.

[8] NCC Group．漏洞信息庫[EB/OL]．[2021-03-10]．http：//cve.scap.org.cn/

[9] Yosifovich P，lonescu A，Russinovich M，et al．深入解析windows操作系統(tǒng)[M]．7版．北京：人民郵電出版社，2021．

[10] Jeffrey Richter，Christophe Nasarre．Windows核心編程[M]．5版．北京：清華大學(xué)出版社，2008．

[11] 段鋼．加密與解密[M]．4版．北京：電子工業(yè)出版社，2018．

Design and implementation of encryption transmission library based on Windows platform

YUAN Liang

（Teachers College，Wuxi City College of Vocational Technology，Wuxi 214000，China）

When using asymmetric algorithm for data encryption transmission between Windows and Linux，in order to effectively avoid the increase of program volume and security risk due to the introduction of third-party code base，a design and implementation method of encrypted transmission library winSSL based on Windows platform is proposed．The implementation idea of winSSL is to use the Windows security service interface to realize the interface functions of SSL/TSL protocol，such as initialization，handshake authentication，data transmission，end transmission and so on．The client program implemented by winSSL library can be seamlessly connected with the OpenSSL server program．Experiments show that compared with OpenSSL program，the file compression ratio of winSSL program is 1/19．Compared with other OpenSSL alternative libraries，the program volume is also significantly improved，but there is no loss in transmission efficiency．

encrypted transmission；winSSL；OpenSSL；Schannel；SSL/TSL

1007-9831（2022）09-0032-07

TP393

A

10.3969/j.issn.1007-9831.2022.09.008

2022-04-13

無錫市教育科學(xué)“十三五”規(guī)劃課題（H/B/2018/003）

袁梁（1981-），女，江蘇無錫人，講師，碩士，從事計(jì)算機(jī)網(wǎng)絡(luò)和數(shù)據(jù)庫系統(tǒng)研究．E-mail：zhangailing0403@163.com