亚洲免费av电影一区二区三区,日韩爱爱视频,51精品视频一区二区三区,91视频爱爱,日韩欧美在线播放视频,中文字幕少妇AV,亚洲电影中文字幕,久久久久亚洲av成人网址,久久综合视频网站,国产在线不卡免费播放

        ?

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

        2022-10-20 05:48:38袁梁
        高師理科學(xué)刊 2022年9期
        關(guān)鍵詞:程序

        袁梁

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

        袁梁

        (無(wú)錫城市職業(yè)技術(shù)學(xué)院 師范學(xué)院,江蘇 無(wú)錫 214000)

        在Windows端和Linux端之間采用非對(duì)稱(chēng)算法進(jìn)行數(shù)據(jù)加密傳輸時(shí),為有效避免由于引入第三方代碼庫(kù)而增加程序體積和安全風(fēng)險(xiǎn),提出了一種基于Windows平臺(tái)的加密傳輸庫(kù)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庫(kù)實(shí)現(xiàn)的客戶(hù)端程序可與OpenSSL服務(wù)端程序無(wú)縫對(duì)接.實(shí)驗(yàn)表明,winSSL程序體積相比OpenSSL程序,文件壓縮比率達(dá)到了1/19,相比其他OpenSSL替代庫(kù),程序體積也有明顯改善,而在傳輸效率上卻沒(méi)有損失.

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

        在采用非對(duì)稱(chēng)算法對(duì)數(shù)據(jù)傳輸進(jìn)行加密方面,目前最流行的加密庫(kù)是OpenSSL[1].OpenSSL是一個(gè)開(kāi)放源代碼的SSL/TSL安全套接字層密碼庫(kù),其函數(shù)庫(kù)以C語(yǔ)言寫(xiě)成,實(shí)現(xiàn)了傳輸層數(shù)據(jù)加密功能,對(duì)SSL和TLS各流行版本均支持.目前,絕大多數(shù)Linux發(fā)行版都有集成OpenSSL套件,在Linux平臺(tái)采用OpenSSLAPI進(jìn)行數(shù)據(jù)加密傳輸開(kāi)發(fā)和運(yùn)行都相當(dāng)方便.然而對(duì)于師范院校教學(xué)機(jī)房學(xué)生Windows終端上網(wǎng)行為的無(wú)感監(jiān)控項(xiàng)目來(lái)說(shuō),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)目工程中引入編譯生成的頭文件和庫(kù)文件,最終完成的加密程序運(yùn)行時(shí)需要附帶libeay32.dll和ssleay32.dll2個(gè)動(dòng)態(tài)庫(kù).但是當(dāng)加密程序注入進(jìn)瀏覽器主進(jìn)程后,當(dāng)前路徑發(fā)生改變,并不能調(diào)用到動(dòng)態(tài)庫(kù),導(dǎo)致程序運(yùn)行失??;如果采用靜態(tài)編譯方式將2個(gè)動(dòng)態(tài)庫(kù)編譯進(jìn)加密程序,最精簡(jiǎn)編譯后,程序體積也將有1.14 M左右,這對(duì)遠(yuǎn)程線程注入技術(shù)來(lái)說(shuō),體積過(guò)于龐大,將直接影響瀏覽器的穩(wěn)定運(yùn)行.因此,OpenSSL顯然是不合適本項(xiàng)目的.為有效避免由于引入第三方代碼庫(kù)而增加的程序體積,以及第三方代碼庫(kù)帶來(lái)新的安全風(fēng)險(xiǎn),本文提出了一種基于Windows安全服務(wù)接口的加密傳輸庫(kù)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)測(cè)試,在Windows客戶(hù)端對(duì)程序采用winSSL加密,在Linux服務(wù)端對(duì)程序采用OpenSSL加密,兩者可實(shí)現(xiàn)無(wú)縫對(duì)接.

        1 相關(guān)研究

        1.1 SSL/TSL及OpenSSL

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

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

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

        1.2 OpenSSL替代庫(kù)

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

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

        2.1 Schannel及CryptoAPI

        Schannel又稱(chēng)Secure Channel,是SSPI(Security Support Provider Interface)的一個(gè)子集,是一個(gè)Win32 API接口,用于為傳輸層應(yīng)用程序和網(wǎng)絡(luò)安全服務(wù)提供安全接口.其主要特性是為應(yīng)用程序提供一個(gè)公用的API接口來(lái)使用不同的安全包,包括Windows NTLM驗(yàn)證、Kerberos安全驗(yàn)證提供器以及SSL/PCT公用密鑰密碼技術(shù)提供器[10],從而使程序開(kāi)發(fā)者能夠直接調(diào)用SSPI函數(shù)來(lái)集成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ù)字證書(shū)、證書(shū)存儲(chǔ)和證書(shū)管理等功能.CryptoAPI函數(shù)允許程序開(kāi)發(fā)者以靈活的方式對(duì)數(shù)據(jù)進(jìn)行加解密或數(shù)字簽名,而實(shí)際的加解密操作是由CSP執(zhí)行,CSP完成數(shù)據(jù)加密、解密以及密鑰存儲(chǔ)管理等工作,CSP中的功能模塊相互獨(dú)立,調(diào)用相當(dāng)方便.Schannel使用CryptoAPI進(jìn)行加解密、公/私鑰存儲(chǔ)以及證書(shū)管理等操作.

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

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

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

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

        3 winSSL客戶(hù)端接口實(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)對(duì)Windows客戶(hù)端證書(shū)和公私鑰的存儲(chǔ)與訪問(wèn);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使用證書(shū)的CERT_KEY_ PROV_ INFO_

        PROP_ID屬性來(lái)定位與特定證書(shū)上下文相關(guān)聯(lián)的私鑰,使用此屬性,Schannel通過(guò)調(diào)用CryptAcquireContext函數(shù)訪問(wèn)私有密鑰.客戶(hù)端私鑰由正在使用的加密服務(wù)提供程序(CSP)管理,客戶(hù)端私鑰通常由類(lèi)型為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)對(duì)所有的Schannel和SSPI的安全庫(kù)進(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三次握手過(guò)程,主要包括Windows客戶(hù)端獲取Linux服務(wù)端含有公鑰的證書(shū)和確定雙方數(shù)據(jù)加密的會(huì)話(huà)密鑰.ClientHand-

        shake接口函數(shù)包含2個(gè)主要函數(shù),PerformClientHandshake和ClientHandshakeLoop,PerformClientHandshake用于向服務(wù)器發(fā)起握手請(qǐng)求,函數(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)過(guò)程,用于實(shí)現(xiàn)三次握手的后續(xù)幾次交互,其實(shí)現(xiàn)過(guò)程與PerformClientHandshake函數(shù)流程基本類(lèi)似,主要是增加了receive函數(shù)過(guò)程InBuffer的安全數(shù)據(jù)結(jié)構(gòu),以及在握手過(guò)程中利用InBuffer,OutBuffer,pExtraData對(duì)包括phContext在內(nèi)的結(jié)構(gòu)體和上下文進(jìn)行初始化.

        3.4 安全通信階段

        安全通信階段實(shí)現(xiàn)了SSLSend和SSLReceive接口函數(shù),SSLSend負(fù)責(zé)對(duì)通信數(shù)據(jù)加密,并將加密數(shù)據(jù)發(fā)送給服務(wù)器,SSLReceive負(fù)責(zé)從服務(wù)器接受數(shù)據(jù),并對(duì)數(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)過(guò)程可參照SSLSend,變量定義基本一致,唯一不同的是SSLReceive先接受數(shù)據(jù),再對(duì)加密數(shù)據(jù)進(jìn)行安全結(jié)構(gòu)體賦值,最后解密數(shù)據(jù).

        3.5 結(jié)束階段

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

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

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

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

        不同SSL/TSL庫(kù)在Windows平臺(tái)下,對(duì)同一對(duì)傳輸程序進(jìn)行的4組加密傳輸效率對(duì)比實(shí)驗(yàn)見(jiàn)圖4.第1組是在Windows7上運(yùn)行winSSL客戶(hù)端程序,在Linux上運(yùn)行OpenSSL服務(wù)器程序;第2組是在Windows7上運(yùn)行OpenSSL 客戶(hù)端程序,在Linux上運(yùn)行OpenSSL服務(wù)器程序;第3組是在Windows7上運(yùn)行mbedTLS 客戶(hù)端程序,在Linux上運(yùn)行mbedTLS服務(wù)器程序;第4組是在Windows7上運(yùn)行wolfSSL客戶(hù)端程序,在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,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庫(kù)在數(shù)據(jù)傳輸效率上很接近,winSSL略遜于mbedTLS,略好于OpenSSL和wolfSSL.

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

        5 結(jié)論

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

        [1] 楊柳,王耀青,張劍龍.基于Linux的文件加密傳輸技術(shù)[J].計(jì)算機(jī)測(cè)量與控制,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.漏洞信息庫(kù)[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

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

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

        猜你喜歡
        程序
        給Windows添加程序快速切換欄
        試論我國(guó)未決羈押程序的立法完善
        失能的信仰——走向衰亡的民事訴訟程序
        “程序猿”的生活什么樣
        英國(guó)與歐盟正式啟動(dòng)“離婚”程序程序
        基于VMM的程序行為異常檢測(cè)
        偵查實(shí)驗(yàn)批準(zhǔn)程序初探
        我國(guó)刑事速裁程序的構(gòu)建
        創(chuàng)衛(wèi)暗訪程序有待改進(jìn)
        恐怖犯罪刑事訴訟程序的完善
        久久久亚洲一区二区三区| 成年女人永久免费看片| 一本大道久久a久久综合| 国产精品成人有码在线观看| 视频在线观看免费一区二区| 人人爽久久涩噜噜噜丁香| 在线a免费观看| 天堂av在线一区二区| 亚洲一二三四区免费视频| 国产草草影院ccyycom| 亚洲 都市 校园 激情 另类| 久久国产亚洲中文字幕| 亚洲最大一区二区在线观看| 在线看无码的免费网站| 国产喷水福利在线视频| 中文字幕乱码亚洲无线| 免费av日韩一区二区| 消息称老熟妇乱视频一区二区| 青青在线精品2022国产| 俺来也三区四区高清视频在线观看| 日本道免费一区二区三区日韩精品| 水蜜桃精品一二三| 日韩av在线毛片| 中文字幕视频一区二区| 中文亚洲av片不卡在线观看| 亚洲色无码播放| 两个人免费视频大全毛片| 日本a级黄片免费观看| 国产高潮视频在线观看| 亚洲综合国产精品一区二区99| 偷拍与自偷拍亚洲精品| 人人妻人人澡人人爽欧美一区| 久久无码人妻精品一区二区三区| 免费无码又爽又刺激又高潮的视频 | 97色伦综合在线欧美视频| 国产福利酱国产一区二区| 色综合久久人妻精品日韩| 丰满大爆乳波霸奶| 精品推荐国产精品店| 日韩精品国产一区在线| www国产亚洲精品|