專利名稱：實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法
技術領域：
本發(fā)明涉及開放移動聯(lián)盟定義的無線數(shù)據(jù)同步規(guī)范(SyncML)技術領域，特別是指實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法。
背景技術：
開發(fā)SyncML的目的在于，使終端用戶、設備開發(fā)商、基礎構件開發(fā)商、數(shù)據(jù)提供商、使用軟件開發(fā)商以及服務提供商協(xié)同工作，真正實現(xiàn)使用任何終端設備均可隨時隨地訪問任何網(wǎng)絡數(shù)據(jù)。SyncML的典型應用是移動設備和網(wǎng)絡服務之間的數(shù)據(jù)同步。除此之外，SyncML還可用于對等的數(shù)據(jù)同步，如兩臺PC之間。現(xiàn)有技術的SyncML同步數(shù)據(jù)的交換的方法如圖1所示。
圖1所示為現(xiàn)有技術的實現(xiàn)SyncML同步傳輸?shù)牧鞒淌疽鈭D。
步驟101～步驟102，SyncML客戶端向SyncML服務器發(fā)起同步初始化請求，請求服務器進行認證；該同步初始化請求中包括認證信息以及自身的設備能力信息，認證信息中包含用戶名和密碼；SyncML服務器接收到該認證請求后，執(zhí)行初始化操作，并返回認證結(jié)果和服務器端的能力信息，SyncML客戶端根據(jù)服務器端的能力信息執(zhí)行初始化操作。至此，初始化完成。上述初始化操作包括對用戶信息進行認證、指明要同步的數(shù)據(jù)庫等。
上述步驟為流程中的初始化階段，其主要完成客戶端和服務器的相互認證、協(xié)商雙方的設備能力，如支持的同步類型、數(shù)據(jù)庫等，以及協(xié)商待同步的數(shù)據(jù)庫。
步驟103～步驟104，SyncML客戶端發(fā)送同步請求到服務器，該同步請求中包含待同步的數(shù)據(jù)，服務器接收到該請求后，進行同步處理，然后向客戶端發(fā)送同步請求響應，該響應中包含服務器端待同步的數(shù)據(jù)。
客戶端接收到該響應后，進行同步處理，之后，如果還有未處理的待同步數(shù)據(jù)，重復執(zhí)行步驟103和步驟104，至所有待同步數(shù)據(jù)處理完畢。
上述步驟為流程中的同步階段，其主要完成客戶端和服務器的之間的數(shù)據(jù)交換以實現(xiàn)數(shù)據(jù)同步。
步驟105～步驟106，SyncML客戶端向服務器發(fā)送請求確認同步完成信息，服務器確認完成后，向客戶端返回確認同步完成的信息。
上述步驟為流程中的同步完成階段，其主要用于客戶端和服務器的之間相互確認完成信息。
在上述同步交換流程中，初始化階段時，SyncML客戶端向服務器發(fā)送認證信息可以采用明文進行發(fā)送，也可以采用base64編碼或MD5加密的方式進行發(fā)送，其余的數(shù)據(jù)，包括客戶端和服務器的設備能力信息、待同步數(shù)據(jù)等均采用明文的方式發(fā)送。
SyncML客戶端和SyncML服務器之間的SyncML同步數(shù)據(jù)超文本傳輸協(xié)議(HTTP)、無線會話協(xié)議(OBEX)或?qū)ο蠼粨Q協(xié)議(WSP)等協(xié)議的支持下實現(xiàn)傳輸，雖然SyncML協(xié)議對使用的傳輸層協(xié)議進行了一些約束，但都不涉及傳輸安全方面。
現(xiàn)有的實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法有以下缺陷1)客戶端所發(fā)送的認證信息的方式不安全，認證信息易被第三方竊取。這是因為，采用明文的方式，被截取后可直接獲得，采用BASE64編碼方式，被截取后很容易解碼。在2004年8月份美國加州舉行的國際密碼學會議上已證實MD5加密的方式可破解，這樣，即使采用MD5加密的方式，被截取后也可以破解，也不十分安全，而且現(xiàn)在市場上大多數(shù)設備都不支持該種加密的認證方式。
2)對所傳輸?shù)拇綌?shù)據(jù)沒有任何保護措施。
3)對于傳輸層中的數(shù)據(jù)沒有任何保護措施。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的在于提供實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法，保證用戶數(shù)據(jù)的安全傳輸，避免被第三方竊取。
為達到上述目的，本發(fā)明的技術方案是這樣實現(xiàn)的一種實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法，該方法包括以下步驟a、SyncML服務器獲取SyncML客戶端生成的會話密鑰，并且，SyncML服務器和SyncML客戶端之間進行初始化操作；b、SyncML客戶端向SyncML服務器發(fā)送使用會話密鑰加密后的待同步數(shù)據(jù)，SyncML服務器接收到該同步數(shù)據(jù)后首先使用會話密鑰進行解密，然后再進行同步處理操作，之后，使用會話密鑰加密服務器端的待同步數(shù)據(jù)，再將加密后待同步數(shù)據(jù)發(fā)送給客戶端；c、SyncML客戶端接收到來自服務器的待同步數(shù)據(jù)數(shù)據(jù)后，先使用會話密鑰進行解密，然后再進行同步處理操作，之后，判斷是否還有待同步數(shù)據(jù)，如果有，則重復執(zhí)行步驟b，否則執(zhí)行步驟d；d、SyncML客戶端向SyncML服務器發(fā)送同步完成請求，并接收到來自SyncML服務器的同步完成確認請求后，結(jié)束本流程。
較佳地，步驟a所述SyncML服務器獲取SyncML客戶端生成的會話密鑰的過程為a1、SyncML服務器接收到來自SyncML客戶端的同步初始化請求后，判斷該請求中是否有請求加密標識，如果有，則執(zhí)行步驟a2，否則，給SyncML客戶端返回失敗原因為服務器要求加密而終端沒有發(fā)送加密請求的同步初始化請求失敗響應；a2、SyncML服務器判斷自身是否支持同步初始化請求中的會話密鑰所要求的算法類型和密鑰長度，如果支持，則獲取并保存同步初始化請求中的會話密鑰，并繼續(xù)后面的初始化操作，否則，給SyncML客戶端返回失敗原因為服務器不支持該密鑰的同步初始化請求失敗響應。
較佳地，該方法進一步包括所述SyncML服務器使用自身保存的私鑰對同步初始化請求中已經(jīng)公鑰加密后的會話密鑰進行解密，獲取客戶端生成的會話密鑰，然后再執(zhí)行步驟a2。
較佳地，所述SyncML客戶端使用的SyncML服務器端證書是預裝或預先從網(wǎng)絡側(cè)下載后安裝的，或者是與SyncML服務器交互后得到的。
較佳地，步驟a所述SyncML服務器和SyncML客戶端之間進行初始化操作的過程包括以下步驟a001、所述SyncML服務器接收到來自SyncML客戶端的包含已加密的用于初始化的用戶數(shù)據(jù)后，使用已獲取的會話密鑰對用于初始化的用戶數(shù)據(jù)進行解密，并執(zhí)行初始化操作，之后，向SyncML客戶端發(fā)送同步初始化響應，該響應中包含SyncML服務器成功接受會話密鑰的信息和使用會話密鑰加密后的自身設備能力信息；a002、SyncML客戶端接收到步驟a001所述響應，判斷出SyncML服務器已成功接受會話密鑰后，使用自身生成的會話密鑰對服務器的設備能力信息進行解密，并執(zhí)行初始化操作。
較佳地，步驟a所述SyncML服務器和SyncML客戶端之間進行初始化操作的過程包括以下步驟a01、所述SyncML服務器接收到來自SyncML客戶端的包含未加密的用于初始化的用戶數(shù)據(jù)后，執(zhí)行初始化操作，之后，向SyncML客戶端發(fā)送同步初始化響應，該響應中包含服務器成功接受會話密鑰的信息和未加密的自身設備能力信息；a02、SyncML客戶端接收到步驟a01所述響應，判斷出SyncML服務器已成功接受會話密鑰后，根據(jù)SyncML服務器的設備能力信息執(zhí)行初始化操作。
較佳地，所述用于初始化的用戶數(shù)據(jù)包括認證信息和SyncML客戶端設備的能力信息；所述認證信息至少包括用戶名和密碼。
較佳地，該方法進一步包括SyncML服務器確定自身是否支持加密信息，如果是，則繼續(xù)執(zhí)行步驟a1，否則，SyncML服務器接收到來自SyncML客戶端的同步初始化請求后，判斷該請求中是否有請求加密標識，如果有，則給SyncML客戶端返回失敗原因為服務器不支持加密請求的同步初始化請求失敗響應，否則按現(xiàn)有技術進行處理。
較佳地，SyncML客戶端接收到來自SyncML服務器的同步初始化請求失敗響應后，判斷自身是否能夠滿足失敗原因所需的條件，如果能，則重新向SyncML服務器發(fā)送同步初始化請求，該請求中包含失敗原因所對應的條件，否則，終止向SyncML服務器發(fā)送同步初始化請求，結(jié)束本流程。
較佳地，所述SyncML客戶端發(fā)送的同步初始化請求中的請求加密標識以標簽的形式承載，且該標識中表明會話公鑰所需的算法類型及密鑰長度。
較佳地，其特征在于，所述SyncML服務器給SyncML客戶端返回的響應中的狀態(tài)信息以狀態(tài)碼的方式進行標識。
較佳地，所述會話密鑰為對稱密鑰或非對稱密鑰。
較佳地，該方法進一步包括A、發(fā)送端構造好待發(fā)送的SyncML信息后，將該待發(fā)送的SyncML消息轉(zhuǎn)換為傳輸層協(xié)議的請求，并使用安全傳輸協(xié)議對該請求加密后，傳送至接收端；B、接收端接收到步驟A所述請求后，使用安全傳輸協(xié)議對接收到的請求進行解密，再將該解密后的傳輸層協(xié)議請求轉(zhuǎn)換為SyncML消息，并進行后續(xù)處理。
較佳地，所述發(fā)送端為SyncML客戶端，所述接收端為SyncML服務器，或者，所述發(fā)送端為SyncML服務器，所述接收端為SyncML客戶端。
較佳地，所述傳輸層協(xié)議為超文本傳輸協(xié)議、無線會話協(xié)議或?qū)ο蠼粨Q協(xié)議。
較佳地，如果所述SyncML客戶端為移動終端，則所使用安全傳輸協(xié)議為無線傳輸層安全性協(xié)議，如果所述SyncML客戶端為固定終端，則所使用安全傳輸協(xié)議為安全套接層協(xié)議或傳輸層安全性協(xié)議。
一種實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法，該方法包括以下步驟A、發(fā)送端構造好待發(fā)送的SyncML信息后，將該待送的SyncML消息轉(zhuǎn)換為傳輸層協(xié)議的請求，并使用安全傳輸協(xié)議對該請求加密后，傳送至接收端；B、接收端接收到步驟A所述請求后，使用安全傳輸協(xié)議對接收到的請求進行解密，再將該解密后的傳輸層協(xié)議請求轉(zhuǎn)換為SyncML消息，并進行后續(xù)處理。
較佳地，所述發(fā)送端為SyncML客戶端，所述接收端為SyncML服務器，或者，所述發(fā)送端為SyncML服務器，所述接收端為SyncML客戶端。
較佳地，所述傳輸層協(xié)議為超文本傳輸協(xié)議、無線會話協(xié)議或?qū)ο蠼粨Q協(xié)議。
較佳地，如果所述SyncML客戶端為移動終端，則所使用安全傳輸協(xié)議為無線傳輸層安全性協(xié)議，如果所述SyncML客戶端為固定終端，則所使用安全傳輸協(xié)議為安全套接層協(xié)議或傳輸層安全性協(xié)議。
本發(fā)明中，SyncML服務器獲取SyncML客戶端生成的會話密鑰，并且，SyncML服務器和SyncML客戶端之間的初始化操作完畢后；發(fā)送端將待同步數(shù)據(jù)使用會話密鑰加密后發(fā)送給接收端；接收端首先使用會話密鑰進行解密，然后再進行同步處理操作，之后再將自身的待同步數(shù)據(jù)使用會話密鑰加密后發(fā)送給對端，如此反復，至所有待同步數(shù)據(jù)處理完畢為止。最后，SyncML客戶端與SyncML服務器之間確認完成后，結(jié)束本流程。使用本發(fā)明，保證了用戶數(shù)據(jù)的安全傳輸，不被第三方竊取，而且滿足了要求加密的使用需求，同時，最大程度上保證了SyncML體系架構的完整性和合理性。
而且，SyncML客戶端可使用服務器端證書中的公鑰將會話密鑰加密后再發(fā)送給SyncML服務器，而SyncML服務器則使用自身的私有解密后，才能獲取客戶端生成的會話密鑰。使用證書機制，保證了和客戶端通信的服務器是可信任的，解決了信任問題，同時，利用非對稱加密技術很好地解決了密鑰的安全傳輸問題。使得每次同步操作均可以使用不同的會話密鑰，極大地提高了密鑰的安全性，同時也極大保證了用戶數(shù)據(jù)的安全性。
另外，用于對用戶數(shù)據(jù)進行加密的會話密鑰，可以為任何算法，如高級加密標準(AES)加密算法、基于RC4的加密算法或者其他對稱加密算法等，其能夠被大部分終端(包括但不限于手機、PDA、智能手機、PC客戶端等)支持。而且，由于加密算法實現(xiàn)的簡單性，能夠很好地在僅有有限的內(nèi)存和處理能力的終端上運行。同時，加密算法的類型可擴展，密鑰的長度可以設置，可針對不同的應用場景提供不同的安全級別。
再有，本發(fā)明對SyncML同步數(shù)據(jù)的傳輸層也進行了安全約束，保證了SyncML同步數(shù)據(jù)在傳輸層的安全。而且，對傳輸層的加密和對用戶數(shù)據(jù)的加密可同時使用，為SyncML同步數(shù)據(jù)的傳輸提供了雙層的安全保障。


圖1所示為現(xiàn)有技術的實現(xiàn)SyncML同步傳輸?shù)牧鞒淌疽鈭D；圖2所示為使用本發(fā)明一實施例的實現(xiàn)SyncML同步傳輸?shù)牧鞒淌疽鈭D；圖3所示為使用本發(fā)明的實現(xiàn)SyncML同步時傳輸層的處理流程示意圖。
具體實施例方式
下面結(jié)合附圖對本發(fā)明再做進一步地詳細說明。
本發(fā)明主要提供了兩種傳輸方式，一種是發(fā)送端對待傳輸?shù)挠脩魯?shù)據(jù)加密后再構造SyncML消息，按現(xiàn)有方式實現(xiàn)傳輸；所述的用戶數(shù)據(jù)包括但不限于認證信息，終端能力信息以及待同步數(shù)據(jù)；另一種方式是發(fā)送端在傳輸層對該待傳輸?shù)腟yncML消息進行加密后，再傳輸，接收端對接收到的傳輸層的SyncML消息解密后再進行后續(xù)處理。
下面首先說明對待傳輸?shù)挠脩魯?shù)據(jù)加密后再構造SyncML消息，然后按現(xiàn)有方式實現(xiàn)傳輸?shù)姆椒ā?br> 圖2所示為使用本發(fā)明一實施例的實現(xiàn)SyncML傳輸?shù)牧鞒淌疽鈭D。在本實施例中，SyncML服務器端要求來自客戶端用戶數(shù)據(jù)是加密的，且SyncML客戶端已預裝或從網(wǎng)絡側(cè)下載服務器端的證書，該證書為非對稱密鑰，其中的公鑰用于客戶端加密，其中的私鑰用于服務器端解密，而SyncML服務器端認為請求接入的客戶端是可信的，不要求客戶端的證書。
步驟201，SyncML客戶端確認自身已安裝服務器端的證書，且該證書處于有效期內(nèi)后，生成用于加密用戶數(shù)據(jù)的會話密鑰，使用服務器端證書的公鑰加密已生成的會話密鑰，使用已生成的會話密鑰加密待傳送的用于初始化的用戶數(shù)據(jù)，如，認證信息和客戶端自身的設備信息等，其中，認證信息中包括用戶名和密碼。
在本實施例中，上述SyncML客戶端自身生成用于加密用戶數(shù)據(jù)的會話密鑰為對稱密鑰，其算法可采用高級加密標準(AES)加密算法、基于RC4的加密算法或者其他對稱加密算法。當然，在實際應用中，會話密鑰的算法并不限于此，現(xiàn)有的加密算法都可在此實施。
當然，也可以不對會話密鑰進行加密，而直接將會話密鑰發(fā)送給SyncML服務器，只是這種方式易被第三方獲取，不夠安全。
步驟202，SyncML客戶端向SyncML服務器發(fā)送同步初始化請求，該請求中包含有請求加密標識，經(jīng)服務器端證書的公鑰加密后的會話密鑰和經(jīng)會話密鑰加密后的待傳送初始化數(shù)據(jù)。上述請求加密標識以標簽的形式承載在同步初始化請求中，且該標識中表明會話公鑰所需的算法類型及密鑰長度。
步驟203，SyncML服務器接收到來自客戶端的同步初始化請求，判斷出有加密請求標識后，使用自身的私鑰對會話標識進行解密，并根據(jù)自身的配置判斷自身是否支持該會話密鑰，即是否支持該會話密鑰所要求的算法類型，以及密鑰長度，如果支持，則繼續(xù)執(zhí)行步驟204，否則，給SyncML客戶端返回包含失敗原因的同步初始化請求響應，結(jié)束本流程。該失敗原因中指明SyncML服務器不支持該會話密鑰，即不支持該會話密鑰所要求的算法類型和或密鑰長度，同時，還可進一步指明自身所要求的算法類型和或密鑰長度。
在本步驟中，如果SyncML服務器判斷出來自客戶端的同步初始化請求中沒有加密請求標識時，直接向SyncML客戶端返回包含失敗原因的同步初始化請求響應，該失敗原因為服務器要求加密而終端沒有發(fā)送加密請求，且該響應中還可進一步包含SyncML服務器支持的算法類型和密鑰長度等信息。
如果SyncML客戶端接收到來自SyncML服務器的同步初始化請求失敗響應，則判斷自身是否能夠滿足失敗原因所需的條件，如果能，則重新向SyncML服務器發(fā)送同步初始化請求，該請求中包含失敗原因所對應的條件，否則，終止向SyncML服務器發(fā)送同步初始化請求，結(jié)束本流程。
步驟204，SyncML服務器繼續(xù)執(zhí)行初始化操作，即使用接收到的會話密鑰對來自客戶端的用于初始化的用戶數(shù)據(jù)進行解密，并應用解密后的用戶數(shù)據(jù)繼續(xù)后續(xù)處理，之后，給客戶端返回成功的同步初始化請求響應，該響應中包含服務器成功接收會話密鑰的信息，以及使用該會話密鑰對自身的設備能力進行加密后的信息。
SyncML客戶端接收到上述所述響應后，使用自身生成的會話密鑰對服務器端的設備能力信息進行解密，然后根據(jù)得到的服務器的能力信息繼續(xù)執(zhí)行初始化操作。
至此，同步初始化階段結(jié)束。
步驟205，SyncML客戶端使用自身生成的會話密鑰對待同時數(shù)據(jù)進行加密，然后向服務器發(fā)送同步請求，該同步請求中包含已加密的待同步數(shù)據(jù)。
步驟206，SyncML服務器接收到步驟205所述請求后，首先使用會話密鑰對待同步數(shù)據(jù)進行解密，之后進行同步處理，然后向客戶端發(fā)送同步請求響應，該同步請求響應中包含使用會話密鑰加密的服務器端的待同步數(shù)據(jù)。
SyncML客戶端收到步驟206所述響應后，同樣首先使用會話密鑰對待同步數(shù)據(jù)進行解密，之后進行同步處理，如果還有待同步數(shù)據(jù)則重復執(zhí)行步驟205及步驟206，直到所有待同步數(shù)據(jù)全部處理完畢為止，同步階段結(jié)束。如果沒有待同步數(shù)據(jù)，則執(zhí)行步驟207，進入同步完成階段。
步驟207～步驟208，SyncML客戶端向服務器發(fā)送請求確認同步完成信息，服務器確認后，向客戶端返回確認同步完成的信息。
至此，SyncML同步數(shù)據(jù)傳輸完成。SyncML客戶端和SyncML服務器之間的SyncML同步數(shù)據(jù)在HTTP、OBEX或WSP等協(xié)議的支持下實現(xiàn)傳輸，其在傳輸層的傳輸方式與現(xiàn)有技術相同。
針對上述實施例，也可以只使用會話密鑰對待同步數(shù)據(jù)進行加密，而不對初始化數(shù)據(jù)進行加密。此時，步驟202中SyncML客戶端向SyncML服務器發(fā)送的同步初始化請求中，包含請求加密標識，經(jīng)服務器端證書的公鑰加密后的會話密鑰和未加密的初始化數(shù)據(jù)，步驟203中SyncML服務器接收到來自客戶端的同步初始化請求，且判斷出自身支持該會話密鑰，直接執(zhí)行初始化操作，之后，向SyncML客戶端發(fā)送同步初始化響應，該響應中包含服務器成功接受會話密鑰的信息和未加密的自身設備能力信息；相應地，SyncML客戶端接收到上述所述響應，判斷出SyncML服務器已成功接受會話密鑰后，根據(jù)SyncML服務器的設備能力信息執(zhí)行初始化操作。
針對上述實施例，SyncML客戶端也可以不通過預裝或下載而獲取服務器端的證書，而是在發(fā)送同步初始化請求之前，直接向服務器發(fā)送請求服務器端證書信息。當然，服務器端也可以認為客戶端是不可信的，而要求客戶端的證書，此時，會話密鑰也可以是非對稱密鑰。
以上所述實施例中，SyncML服務器端是要求來自客戶端的用戶數(shù)據(jù)加密的。如果SyncML服務器端不支持來自客戶端的用戶數(shù)據(jù)加密，則當SyncML服務器接收到的來自客戶端的包含加密信息的同步初始化請求時，向SyncML客戶端返回失敗原因為要求客戶端發(fā)送不包含加密標識的失敗的初始化響應；相應地，SyncML客戶端接收到來自SyncML服務器的同步初始化請求失敗響應，則判斷自身是否能夠滿足失敗原因所需的條件，如果能，則重新向SyncML服務器發(fā)送同步初始化請求，該請求中包含失敗原因所對應的條件，否則，終止向SyncML服務器發(fā)送同步初始化請求，結(jié)束本流程。如果SyncML服務器接收到來自客戶端的未包含加密信息的同步初始化請求，則與現(xiàn)有處理方式完全相同。
以上所述實施例中，SyncML服務器給SyncML客戶端返回的響應中的狀態(tài)信息以狀態(tài)碼的方式進行標識，具體某一狀態(tài)碼代表哪個信息可在實際應用中根據(jù)需要指定，在此不做限制。以上實施例中的密鑰所采用的算法類型，可為現(xiàn)有的任一種對稱算法類型。
下面說明在傳輸層加密后實現(xiàn)傳輸?shù)姆椒ā?br> 圖3所示為使用本發(fā)明的對傳輸層進行加密處理后實現(xiàn)傳輸SyncML同步數(shù)據(jù)的流程示意圖。在本實施例中，使用HTTP協(xié)議作為傳輸層的傳送協(xié)議。
步驟301，發(fā)送端構造好待發(fā)送的SyncML消息后，將待送的SyncML消息轉(zhuǎn)換為HTTP請求。
步驟302，發(fā)送端使用安全傳輸協(xié)議對步驟301所述HTTP請求加密后，再傳輸該加密后的HTTP請求至接收端。
步驟303，接收端接收到步驟302所述請求后，使用安全傳輸協(xié)議對該請求進行解密，將該解密后的HTTP請求轉(zhuǎn)換為SyncML消息，再并進行后續(xù)處理。
上述僅以SyncML的傳輸層使用HTTP協(xié)議為例進行說明，其傳輸層還可以使用OBEX或WSP等協(xié)議。上述述發(fā)送端為SyncML客戶端，接收端為SyncML服務器，或者，上述發(fā)送端為SyncML服務器，接收端為SyncML客戶端。
如果SyncML客戶端為移動終端，如手機，則所使用安全傳輸協(xié)議為無限傳輸層安全性(WTLS)協(xié)議，如果SyncML客戶端為固定終端，如PC客戶端，則所使用安全傳輸協(xié)議為安全套接層(SSL)協(xié)議或傳輸層安全性(TLS)協(xié)議。
上述對傳輸層的數(shù)據(jù)進行加密的傳輸方式即可以單獨使用，也可以與對待傳輸?shù)挠脩魯?shù)據(jù)加密后再構造SyncML消息，然后按現(xiàn)有方式實現(xiàn)傳輸?shù)姆椒ㄒ黄鹗褂?。如果一起使用，則為SyncML同步數(shù)據(jù)的傳輸提供了雙層的安全保障。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。
權利要求
1.一種實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法，其特征在于，該方法包括以下步驟a、SyncML服務器獲取SyncML客戶端生成的會話密鑰，并且，SyncML服務器和SyncML客戶端之間進行初始化操作；b、SyncML客戶端向SyncML服務器發(fā)送使用會話密鑰加密后的待同步數(shù)據(jù)，SyncML服務器接收到該同步數(shù)據(jù)后首先使用會話密鑰進行解密，然后再進行同步處理操作，之后，使用會話密鑰加密服務器端的待同步數(shù)據(jù)，再將加密后待同步數(shù)據(jù)發(fā)送給客戶端；c、SyncML客戶端接收到來自服務器的待同步數(shù)據(jù)后，先使用會話密鑰進行解密，然后再進行同步處理操作，之后，判斷是否還有待同步數(shù)據(jù)，如果有，則重復執(zhí)行步驟b，否則執(zhí)行步驟d；d、SyncML客戶端向SyncML服務器發(fā)送同步完成請求，并接收到來自SyncML服務器的同步完成確認請求后，結(jié)束本流程。
2.根據(jù)權利要求1所述的方法，其特征在于，步驟a所述SyncML服務器獲取SyncML客戶端生成的會話密鑰的過程為a1、SyncML服務器接收到來自SyncML客戶端的同步初始化請求后，判斷該請求中是否有請求加密標識，如果有，則執(zhí)行步驟a2，否則，給SyncML客戶端返回失敗原因為服務器要求加密而終端沒有發(fā)送加密請求的同步初始化請求失敗響應；a2、SyncML服務器判斷自身是否支持同步初始化請求中的會話密鑰所要求的算法類型和密鑰長度，如果支持，則獲取并保存同步初始化請求中的會話密鑰，并繼續(xù)后面的初始化操作，否則，給SyncML客戶端返回失敗原因為服務器不支持該密鑰的同步初始化請求失敗響應。
3.根據(jù)權利要求2所述的方法，其特征在于，該方法進一步包括所述SyncML服務器使用自身保存的私鑰對同步初始化請求中已經(jīng)公鑰加密后的會話密鑰進行解密，獲取客戶端生成的會話密鑰，然后再執(zhí)行步驟a2。
4.根據(jù)權利要求3所述的方法，其特征在于，所述SyncML客戶端使用的SyncML服務器端證書是預裝或預先從網(wǎng)絡側(cè)下載后安裝的，或者是與SyncML服務器交互后得到的。
5.根據(jù)權利要求2所述的方法，其特征在于，步驟a所述SyncML服務器和SyncML客戶端之間進行初始化操作的過程包括以下步驟a001、所述SyncML服務器接收到來自SyncML客戶端的包含已加密的用于初始化的用戶數(shù)據(jù)后，使用已獲取的會話密鑰對該用戶數(shù)據(jù)進行解密，并執(zhí)行初始化操作，之后，向SyncML客戶端發(fā)送同步初始化響應，該響應中包含SyncML服務器成功接受會話密鑰的信息和使用會話密鑰加密后的自身設備能力信息；a002、SyncML客戶端接收到步驟a001所述響應，判斷出SyncML服務器已成功接受會話密鑰后，使用自身生成的會話密鑰對服務器的設備能力信息進行解密，并執(zhí)行初始化操作。
6.根據(jù)權利要求2所述的方法，其特征在于，步驟a所述SyncML服務器和SyncML客戶端之間進行初始化操作的過程包括以下步驟a01、所述SyncML服務器接收到來自SyncML客戶端的包含未加密的用于初始化的用戶數(shù)據(jù)后，執(zhí)行初始化操作，之后，向SyncML客戶端發(fā)送同步初始化響應，該響應中包含服務器成功接受會話密鑰的信息和未加密的自身設備能力信息；a02、SyncML客戶端接收到步驟a01所述響應，判斷出SyncML服務器已成功接受會話密鑰后，根據(jù)SyncML服務器的設備能力信息執(zhí)行初始化操作。
7.根據(jù)權利要求5或6所述的方法，其特征在于，所述用于初始化的數(shù)據(jù)包括認證信息和SyncML客戶端設備的能力信息；所述認證信息至少包括用戶名和密碼。
8.根據(jù)權利要求2所述的方法，其特征在于，該方法進一步包括SyncML服務器確定自身是否支持加密信息，如果是，則繼續(xù)執(zhí)行步驟a1，否則，SyncML服務器接收到來自SyncML客戶端的同步初始化請求后，判斷該請求中是否有請求加密標識，如果沒有，則按現(xiàn)有技術進行處理；如果有，則給SyncML客戶端返回失敗原因為服務器不支持加密請求的同步初始化請求失敗響應。
9.根據(jù)權利要求2或8所述的方法，其特征在于，SyncML客戶端接收到來自SyncML服務器的同步初始化請求失敗響應后，判斷自身是否能夠滿足失敗原因所需的條件，如果能，則重新向SyncML服務器發(fā)送同步初始化請求，該請求中包含失敗原因所對應的條件，否則，終止向SyncML服務器發(fā)送同步初始化請求，結(jié)束本流程。
10.根據(jù)權利要求2所述的方法，其特征在于，所述SyncML客戶端發(fā)送的同步初始化請求中的請求加密標識以標簽的形式承載，且該標識中表明會話公鑰所需的算法類型及密鑰長度。
11.根據(jù)權利要求2、5、6或8所述的方法，其特征在于，所述SyncML服務器給SyncML客戶端返回的響應中的狀態(tài)信息以狀態(tài)碼的方式進行標識。
12.根據(jù)權利要求1所述的方法，其特征在于，所述會話密鑰為對稱密鑰或非對稱密鑰。
13.根據(jù)權利要求1所述的方法，其特征在于，該方法進一步包括A、發(fā)送端構造好待發(fā)送的SyncML信息后，將該待送的SyncML消息轉(zhuǎn)換為傳輸層協(xié)議的請求，并使用安全傳輸協(xié)議對該請求加密后，傳送至接收端；B、接收端接收到步驟A所述請求后，使用安全傳輸協(xié)議對接收到的請求進行解密，再將該解密后的傳輸層協(xié)議請求轉(zhuǎn)換為SyncML消息，并進行后續(xù)處理。
14.根據(jù)權利要求13所述的方法，其特征在于，所述發(fā)送端為SyncML客戶端，所述接收端為SyncML服務器，或者，所述發(fā)送端為SyncML服務器，所述接收端為SyncML客戶端。
15.根據(jù)權利要求13所述的方法，其特征在于，所述傳輸層協(xié)議為超文本傳輸協(xié)議、無線會話協(xié)議或?qū)ο蠼粨Q協(xié)議。
16.根據(jù)權利要求13所述的方法，其特征在于，如果所述SyncML客戶端為移動終端，則所使用安全傳輸協(xié)議為無線傳輸層安全性協(xié)議，如果所述SyncML客戶端為固定終端，則所使用安全傳輸協(xié)議為安全套接層協(xié)議或傳輸層安全性協(xié)議。
17.一種實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法，其特征在于，該方法包括以下步驟A、發(fā)送端構造好待發(fā)送的SyncML信息后，將該待送的SyncML消息轉(zhuǎn)換為傳輸層協(xié)議的請求，并使用安全傳輸協(xié)議對該請求加密后，傳送至接收端；B、接收端接收到步驟A所述請求后，使用安全傳輸協(xié)議對接收到的請求進行解密，再將該解密后的傳輸層協(xié)議請求轉(zhuǎn)換為SyncML消息，并進行后續(xù)處理。
18.根據(jù)權利要求17所述的方法，其特征在于，所述發(fā)送端為SyncML客戶端，所述接收端為SyncML服務器，或者，所述發(fā)送端為SyncML服務器，所述接收端為SyncML客戶端。
19.根據(jù)權利要求17所述的方法，其特征在于，所述傳輸層協(xié)議為超文本傳輸協(xié)議、無線會話協(xié)議或?qū)ο蠼粨Q協(xié)議。
20.根據(jù)權利要求17所述的方法，其特征在于，如果所述SyncML客戶端為移動終端，則所使用安全傳輸協(xié)議為無線傳輸層安全性協(xié)議，如果所述SyncML客戶端為固定終端，則所使用安全傳輸協(xié)議為安全套接層協(xié)議或傳輸層安全性協(xié)議。
全文摘要
本發(fā)明提供了實現(xiàn)傳輸SyncML同步數(shù)據(jù)的方法，一種是發(fā)送端對待傳輸?shù)挠脩魯?shù)據(jù)加密后構造SyncML消息，然后按現(xiàn)有方式實現(xiàn)傳輸；所述的用戶數(shù)據(jù)包括但不限于認證信息，終端能力信息以及待同步數(shù)據(jù)；另一種是發(fā)送端在傳輸層對該待傳輸?shù)腟yncML消息進行加密后再傳輸，接收端對接收到的傳輸層的SyncML消息解密后再進行后續(xù)處理，兩種方法可單獨使用也可以一起使用。如果一起使用，則為SyncML同步數(shù)據(jù)的傳輸提供了雙層的安全保障。使用本發(fā)明，保證了用戶數(shù)據(jù)的安全傳輸，避免被第三方竊取。
文檔編號H04L7/00GK1753359SQ200410080190
公開日2006年3月29日 申請日期2004年9月24日 優(yōu)先權日2004年9月24日
發(fā)明者田林一 申請人:華為技術有限公司