專利名稱：接入虛擬專用網(wǎng)(vpn)的數(shù)據(jù)加密方法
技術領域：
本發(fā)明涉及一種用于接入虛擬專用網(wǎng)(以下稱之為“VPN”)的數(shù)據(jù)加密方法，其中當VPN的訂戶接入其公司的VPN時，為了數(shù)據(jù)安全執(zhí)行數(shù)據(jù)加密。
背景技術：
專用網(wǎng)是一種用于企業(yè)或集團等之間快速通信的獨立通信網(wǎng)，并且可以為同一專用網(wǎng)的內(nèi)部提供單個的數(shù)字計劃而不考慮本地的條件。此外，專用網(wǎng)具有多個有關安全性和可靠性的強項。不過，存在的不便之處在于每一個企業(yè)應當直接管理相關的網(wǎng)絡。VPN業(yè)務是一種用于解決這種不便性并通過公共通信網(wǎng)提供專用網(wǎng)所有功能的業(yè)務。
這種VPN業(yè)務提供相同的效果，就好像諸如分布于多個區(qū)域的企業(yè)之類的許多需求者通過其本身的局域網(wǎng)(LAN)，基于公共網(wǎng)進行他們通信需求的互通。此外，這種VPN業(yè)務具有通過契約(contract)關系非常易于執(zhí)行其本身專用網(wǎng)擴展或結(jié)構(gòu)重建的優(yōu)點。由于實際中使用的物理網(wǎng)絡是公共網(wǎng)，且整體上由公共網(wǎng)絡運營商執(zhí)行物理網(wǎng)絡的管理，因此這是可能的。
目前可以根據(jù)下列不同類型將VPN技術進行分類并加以說明。
在第一種情況下，根據(jù)網(wǎng)絡類型將VPN技術進行如下分類—接入VPN總部與遠端區(qū)域授權用戶之間的網(wǎng)絡；使用客戶到LAN類型。
—內(nèi)聯(lián)網(wǎng)VPN總部與分支部門之間的網(wǎng)絡；使用LAN到LAN類型。
—外聯(lián)網(wǎng)VPN總部與商業(yè)伙伴或客戶之間的網(wǎng)絡，是安全策略不同的交互連接網(wǎng)絡；其安全性容易受到攻擊。
此外，可以根據(jù)連接方法將VPN網(wǎng)絡技術進行如下分類—客戶到LAN接入企業(yè)和遠端區(qū)域工作者或移動工作者之間。使用了不同類型的接入設備，諸如調(diào)制解調(diào)器、綜合業(yè)務數(shù)字網(wǎng)(ISDN)以及x數(shù)字訂戶線(xDSL)。遠端用戶在通過電話接入本地接入服務提供點(POP)之后使用VPN功能。
—LAN到LAN存在著各種類型的VPN設備。將VPN模塊安裝于主計算機。在遠端區(qū)域支持VPN。
本發(fā)明使用的接入VPN主要指客戶到LAN類型的VPN，其中移動用戶使用諸如隧道協(xié)議層2(L2TP)或點對點隧道協(xié)議(PPTP)之類的點對點協(xié)議(PPP)隧道協(xié)議，通過調(diào)制解調(diào)器或xDSL接入其自己公司的專用網(wǎng)。
L2TP是一種合并了PPTP以及轉(zhuǎn)發(fā)協(xié)議層2(L2F)的協(xié)議，并由因特網(wǎng)工程任務組意見2661(IETFRFC2661)定義。L2TP的特征在于它是一種兩層的隧道協(xié)議，直接對PPP分組進行包封(capsule)，并且針對每一個PPP分組類型，在一個隧道的內(nèi)部可以建立多個會話。
在用于接入VPN協(xié)議的情況下，只提供了使用PPP的用戶認證方法，而并沒有提供單獨用于保障用戶數(shù)據(jù)的方法。同時，在因特網(wǎng)協(xié)議安全協(xié)議(IPSec)的情況下，其中所述協(xié)議是一種用于LAN到LAN類型VPN構(gòu)造的協(xié)議，提供了多種散列函數(shù)(hash function)及加密算法，從而保證了安全的信息交換。
因此，迫切需要一種單獨的措施，用于對關于接入VPN的PPP標準操作算法獲得的數(shù)據(jù)進行加密。

發(fā)明內(nèi)容
為了解決上述問題，因此本發(fā)明的目的是提供一種方法，該方法通過將用于執(zhí)行數(shù)據(jù)加密的項目加入到PPP標準操作算法的LCP協(xié)商條件中，能夠向接入VPN用戶提供數(shù)據(jù)的安全發(fā)送和接收，其中通過用于接入VPN的隧道協(xié)議層2對PPP分組進行包封，然后發(fā)送。
通過提供一種用于接入VPN數(shù)據(jù)加密的方法能夠?qū)崿F(xiàn)前述及其它優(yōu)點和目標，所述方法包括步驟執(zhí)行鏈路控制協(xié)議(LCP)協(xié)商，所述協(xié)商關于認證方法、數(shù)據(jù)壓縮、最大可接收數(shù)據(jù)量、鏈路狀態(tài)監(jiān)視以及是否執(zhí)行數(shù)據(jù)加密；當兩個終端根據(jù)執(zhí)行LCP協(xié)商步驟的LCP協(xié)商條件，做出認為有必要相互認證的協(xié)商時，檢查用戶標識(ID)和密碼；當兩個終端根據(jù)執(zhí)行LCP協(xié)商步驟的LCP協(xié)商條件，做出認為要執(zhí)行數(shù)據(jù)加密的協(xié)商時，執(zhí)行數(shù)據(jù)加密；根據(jù)執(zhí)行LCP協(xié)商步驟的LCP協(xié)商條件，在兩個終端執(zhí)行協(xié)商以使不執(zhí)行用戶認證和數(shù)據(jù)加密，或執(zhí)行用于協(xié)商層3通信信息(IP地址分配、域名系統(tǒng)(DNS)服務器地址分配)的網(wǎng)絡控制協(xié)議(NCP)協(xié)商，從而在數(shù)據(jù)加密之后執(zhí)行用戶和專用網(wǎng)之間的接入；以及當執(zhí)行用戶和專用網(wǎng)之間的NCP協(xié)商時，通過形成用戶和專用網(wǎng)之間的會話，發(fā)送并接收數(shù)據(jù)。
在上述LCP協(xié)商中，預先將一個項目加入用戶及LNS的LCP協(xié)商選項表中，通過該項目可以選擇是否執(zhí)行數(shù)據(jù)加密，從而可以執(zhí)行包括數(shù)據(jù)加密的協(xié)商。


當通過參考以下結(jié)合了附圖的詳細描述，其中附圖中的相似參考符號表示相同或相似元件，對本發(fā)明更完全的理解以及本發(fā)明的多個附屬優(yōu)點將顯而易見，其中圖1是使用普通L2TP接入VPN的設置框圖；圖2是示出了用戶使用L2TP接入其公司專用網(wǎng)過程的流程圖；圖3是普通PPP操作的流程圖；圖4是應用于本發(fā)明的PPP分組數(shù)據(jù)格式；以及圖5是根據(jù)本發(fā)明的優(yōu)選實施例，包括加密步驟的PPP操作流程圖。
具體實施例方式
圖1是使用普通L2TP接入VPN的設置框圖，且圖2是示出了用戶使用LTP接入其公司專用網(wǎng)過程的流程圖。
參考圖1和圖2，為了接入作為用戶公司專用網(wǎng)的L2TP網(wǎng)絡服務器(LNS)，接入VPN訂戶使用用戶終端10，使得PPP通過公共交換電話網(wǎng)(PSTN)20接入ISP30(T1)。當接入了ISP30時，通過使用質(zhì)詢握手認證協(xié)議/密碼認證協(xié)議(CHAP/PAP)，執(zhí)行用戶認證過程(T2)，其是兩個獨立主機之間的認證方法(點對點)。
如果成功執(zhí)行了該用戶認證過程，則ISP30形成一個L2TP隧道以連接用戶和LNS(T3)。
當形成了L2TP隧道時，在用戶終端10和LNS50之間再次執(zhí)行認證過程(T4)，然后開始網(wǎng)絡控制協(xié)議(PPP NCP)協(xié)商(T5)。
當正常執(zhí)行了NCP協(xié)商時，在用戶終端10和LNS50之間形成PPP會話(T6)，并執(zhí)行數(shù)據(jù)的發(fā)送和接收(T7)。
將上述步驟大體上分為在用戶終端10和ISP30之間交換了鏈路相關參數(shù)的鏈路控制協(xié)議(LCP)步驟(T1)、用戶認證步驟(T2、T4)以及在用戶終端10和LNS50之間交換了上層協(xié)議相關參數(shù)的NCP步驟(T5、T6)。
下文中將結(jié)合PPP操作對上述過程進行說明。
圖3是普通PPP操作的流程圖。參考圖3，在未接入(dead)步驟S10，用戶根據(jù)接入嘗試信號建立接入，并在建立步驟S20執(zhí)行接入。在步驟S20，執(zhí)行有關相互認證方法、最大接收字節(jié)數(shù)目以及是否執(zhí)行數(shù)據(jù)壓縮的LCP協(xié)商。此外，如果根據(jù)LCP協(xié)商條件選擇了相互認證，則在步驟S30執(zhí)行認證。如果在步驟S30認證失敗，則取消連接并執(zhí)行結(jié)束步驟S50。
如果在步驟S30成功進行了認證，或者在LCP協(xié)商條件中沒有選擇相互認證，則執(zhí)行網(wǎng)絡步驟(S40)，從而協(xié)商了用于層3通信的信息(IP地址分配、域名系統(tǒng)(DNS)服務器地址分配)，然后相互執(zhí)行數(shù)據(jù)的發(fā)送和接收。
下面的表1給出了PPP LCP協(xié)商選項表。下面的表2給出了加入一個項目的PPP LCP協(xié)商選項表，從而使在PPP標準操作算法的LCP協(xié)商條件中能夠選擇數(shù)據(jù)加密。
<表1>

<表2>

如表2所示，由于加入了用于數(shù)據(jù)加密處理的選項，如果在LCP協(xié)商過程中進行了協(xié)商，從而執(zhí)行數(shù)據(jù)加密，則執(zhí)行PPP操作，其中將執(zhí)行數(shù)據(jù)加密的過程與用戶認證的過程加到一起。
此時，同時發(fā)送多個選項，且不發(fā)送用于這些選項的默認值。
圖4是應用于本發(fā)明的PPP分組數(shù)據(jù)格式。參考圖4，將對PPP分組的每一個字段進行說明。配置請求分組(代碼＝1)中包括了多個LCP協(xié)商選項，并將這些選項分發(fā)到每一個對等實體中。在此方面，將這些選項分為“Type”、“Length”以及“Data”字段。
下面對根據(jù)本發(fā)明的優(yōu)選實施例包括加密步驟并反映了上述選項字段結(jié)構(gòu)的PPP操作進行說明。
圖5是根據(jù)本發(fā)明的優(yōu)選實施例，包括加密步驟的PPP操作流程圖。參考圖5，在未接入步驟(S100)，用戶根據(jù)接入嘗試信號建立接入，并執(zhí)行在建立步驟(S200)。在步驟S200，執(zhí)行有關相互認證方法、最大接收字節(jié)數(shù)目以及是否執(zhí)行數(shù)據(jù)壓縮的LCP協(xié)商。此外，如果根據(jù)LCP協(xié)商條件，有必要建立兩個終端之間的相互認證和數(shù)據(jù)加密，則首先執(zhí)行認證步驟(S300)。在步驟S300，通過使用PAP/CHAP執(zhí)行相互認證，并且如果該認證正常完成，執(zhí)行用于執(zhí)行數(shù)據(jù)加密的加密步驟(S350)。
根據(jù)運營商的策略，加密步驟(S350)選擇并使用最合適的加密協(xié)議，通常應當使用被廣泛使用的數(shù)據(jù)加密標準(DES)。
為了完全理解，下面對DES進行說明。
下列公式1給出了DES的基本原則[公式1]文本(原始文本)+密鑰(密碼)+加密算法＝加密后的原始文本就上式而言，將用戶密碼用作加密的密鑰值。
在第一種情況下，加密算法將一個要加密的消息分為64比特的塊，并準備固定大小為56比特的密鑰。從原始文本中分出的這64比特的塊與密鑰值設置在一起，并執(zhí)行用另一個比特組代替一個比特組的處理，并且將該塊混合成無法識別的數(shù)據(jù)。
因此，以加密的形式發(fā)送和接收使用前述方法在用戶終端10和LNS50之間發(fā)送和接收的數(shù)據(jù)，從而使數(shù)據(jù)不可能暴露于外界。
此時，由于用戶認證是考慮到加密目的的絕對必要項目，因此當選擇了數(shù)據(jù)加密時，絕對必須執(zhí)行認證過程。
當然，在取決于網(wǎng)絡的特性確定不需要用戶認證的情況下，可以不選擇用戶認證處理。
當執(zhí)行了步驟S350時，在進行數(shù)據(jù)加密，從而協(xié)商用于層3通信的信息(IP地址分配、域名系統(tǒng)(DNS)服務器地址分配等等)的狀態(tài)下，執(zhí)行網(wǎng)絡步驟S400，然后相互執(zhí)行數(shù)據(jù)的發(fā)送和接收。
在相互認證時，PAP是一種雙向類型的信號交換，其中主請求認證以普通的文本形式發(fā)出用戶ID和用戶密碼，從而非常容易發(fā)生認證信息暴露于外界。因此，在需要認證的情況下，應當執(zhí)行三向信號交換類型CHAP，從而不暴露用戶密碼。
CHAP方法以下列方式保持安全性如果認證服務器向主機發(fā)送了質(zhì)詢信號，則主機為了安全性，發(fā)送通過散列函數(shù)計算的值，并且如果接受了該值，則認證服務器同意認證。
如上所述，當使用PPP隧道協(xié)議(L2TP，PPTP)接入其公司的專用網(wǎng)絡時，用戶通過了諸如因特網(wǎng)之類不支持安全性的網(wǎng)絡。此時，根據(jù)本發(fā)明，將用于數(shù)據(jù)加密的項目加到LVP協(xié)商選項中，從而使數(shù)據(jù)加密處理能夠與PPP標準操作算法中的用戶認證處理同時進行。因此，不會容易地暴露數(shù)據(jù)，且使得保證了安全性的通信成為可能。
盡管對本發(fā)明的優(yōu)選實施例進行了說明，本領域的技術人員應當理解本發(fā)明并不限于所述的優(yōu)選實施例。相反地，可以在所附權利要求確定的本發(fā)明精神和范圍內(nèi)，進行各種變化和修改。
權利要求
1.一種用于在接入虛擬專用網(wǎng)VPN中加密數(shù)據(jù)的方法，其特征在于包括步驟執(zhí)行鏈路控制協(xié)議(LCP)協(xié)商，所述協(xié)商至少關于認證方法、數(shù)據(jù)壓縮、最大可接收數(shù)據(jù)量、鏈路狀態(tài)監(jiān)視以及是否執(zhí)行數(shù)據(jù)加密的其中之一；當LCP協(xié)商確定需要相互認證時，檢查用戶標識(ID)和密碼，所述協(xié)商由兩個終端根據(jù)執(zhí)行LCP協(xié)商步驟的LCP協(xié)商條件做出；當LCP協(xié)商的結(jié)果導致要執(zhí)行數(shù)據(jù)加密的決定時，執(zhí)行數(shù)據(jù)加密；為了協(xié)商用于用戶和專用網(wǎng)之間層3通信接入的信息，執(zhí)行網(wǎng)絡控制協(xié)議(NCP)協(xié)商；以及當執(zhí)行用戶和專用網(wǎng)之間的NCP協(xié)商時，通過形成用戶和專用網(wǎng)之間的會話，發(fā)送并接收數(shù)據(jù)。
2.根據(jù)權利要求1所述的方法，其特征在于在執(zhí)行了數(shù)據(jù)加密之后執(zhí)行NCP協(xié)商。
3.根據(jù)權利要求1所述的方法，其特征在于在執(zhí)行LCP協(xié)商過程中，當確定了不需要進行認證和數(shù)據(jù)加密時，執(zhí)行NCP協(xié)商。
4.根據(jù)權利要求1所述的方法，其特征在于在所述執(zhí)行LCP協(xié)商的步驟之前，預先將一個用于選擇是否執(zhí)行數(shù)據(jù)加密的項目加入用戶及專用網(wǎng)的LCP協(xié)商選項表中。
5.根據(jù)權利要求1所述的方法，其特征在于檢查用戶ID及密碼的步驟包括通過以文本格式發(fā)出用戶ID和密碼，使用密碼認證協(xié)議(PAP)提供用戶認證。
6.根據(jù)權利要求1所述的方法，其特征在于檢查用戶ID及密碼的步驟包括使用質(zhì)詢握手認證協(xié)議(CHAP)提供使用了散列函數(shù)的用戶認證。
7.根據(jù)權利要求1所述的方法，其特征在于執(zhí)行數(shù)據(jù)加密的步驟包括使用數(shù)據(jù)加密標準(DES)。
8.根據(jù)權利要求1所述的方法，其特征在于執(zhí)行數(shù)據(jù)加密的步驟包括使用用戶密碼作為加密的密鑰值。
9.根據(jù)權利要求1所述的方法，其特征在于執(zhí)行LCP協(xié)商與認證方法和是否執(zhí)行數(shù)據(jù)加密都有關。
10.根據(jù)權利要求9所述的方法，其特征在于執(zhí)行數(shù)據(jù)加密的步驟包括使用用戶密碼作為加密的密鑰值。
全文摘要
在接入虛擬專用網(wǎng)(VPN)中加密數(shù)據(jù)的方法中，當接入其公司專用網(wǎng)時，訂戶執(zhí)行用于數(shù)據(jù)安全性的數(shù)據(jù)加密步驟。在此方法中，在未接入步驟，用戶根據(jù)接入嘗試信號建立接入。執(zhí)行有關相互認證方法、最大接收字節(jié)數(shù)目以及是否執(zhí)行數(shù)據(jù)壓縮的鏈路控制協(xié)議(LCP)協(xié)商。當LCP協(xié)商確定相互認證和數(shù)據(jù)加密必要時，則首先執(zhí)行認證步驟，并通過使用質(zhì)詢握手認證協(xié)議/密碼認證協(xié)議(CHAP/PAP)執(zhí)行相互認證。如果認證正常完成，則執(zhí)行數(shù)據(jù)加密。因此，數(shù)據(jù)家沒與用戶認證一起執(zhí)行，從而不容易暴露數(shù)據(jù)并執(zhí)行了安全性有保證的通信。
文檔編號H04L29/06GK1523808SQ20041000700
公開日2004年8月25日 申請日期2004年2月20日 優(yōu)先權日2003年2月20日
發(fā)明者李仁柱 申請人:三星電子株式會社