[發明專利]密鑰交換方法和裝置

有效

• 申請號: 200910119701.6
• 申請日: 2009-03-25
• 公開（公告）號: CN101848401A
• 公開（公告）日: 2010-09-29
• 發明（設計）人: 張偉良
• 申請（專利權）人: 中興通訊股份有限公司
• 主分類號: H04Q11/00
• 分類號: H04Q11/00;H04L29/06
• 代理公司: 北京康信知識產權代理有限責任公司 11240
• 代理人: 余剛;吳孟秋

技術領域

本發明涉及通信領域，尤其涉及一種密鑰交換方法和裝置。

背景技術

吉比特無源光網絡(Gigabit?Passive?Optical?Network，簡稱為GPON)是一種基于ITU-T?G.984系列的寬帶無源光接入技術，GPON系統一般包括光線路終端(Optical?Line?Terminal，簡稱為OLT)OLT、光網絡單元(Optical?Network?Unit，簡稱為ONU)和光分布網絡(Optical?Distribution?Network，簡稱為ODN)。其中，ODN為點到多點結構，一個OLT通過ODN連接多個ONU，在數據傳輸過程匯總，OLT向ONU發送的數據稱為下行數據，ONU向OLT發送的數據稱為上行數據。

在GPON系統中，下行數據具有天然廣播特性，OLT發送的數據能夠被所有與其相連接的ONU接收到。出于安全性的考慮，ITU-TGPON標準采用(Advanced?Encryption?Standard，簡稱為AES)加密技術對下行數據進行加密，OLT和ONU各自保存密鑰共同完成密鑰管理，OLT利用本地保存的密鑰對其發送的下行數據進行加密，ONU利用本地保存的密鑰對來自OLT的下行數據進行解密。

圖1是GPON系統中，OLT和ONU進行密鑰切換的消息交互示意圖，如圖1所示，在GPON系統中，OLT和ONU之間的密鑰管理流程可分為三個階段：密鑰交換、密鑰切換幀交換、密鑰切換。其中，OLT和ONU之間通過物理層操作管理維護(Physical?LayerOperation?Administration?&?Maintenance，簡稱為PLOAM)消息完成密鑰交換和密鑰切換幀交換。

在密鑰交換階段，OLT向ONU發送Request_Key(請求密鑰)消息，ONU接收到Request_Key消息之后，產生新的密鑰及索引，并將該新的密鑰及索引保存到shadow_key_register(備用密鑰寄存器)。然后，將上述新的密鑰及索引通過Encryption_Key(加密密鑰)消息發送給OLT，其中，新的密鑰及索引需要分為兩段通過兩個Encryption_Key消息進行發送，且每個Encryption_Key消息中攜帶相同的密鑰索引。

OLT接收到上述Encryption_Key消息之后，如果能解析出正確的密鑰及索引，則將解析出的密鑰及索引保存到本地的shadow_key_register寄存器，此時，OLT和ONU完成密鑰交換過程。如果OLT沒有接收到或者正確解析出ONU發送的密鑰及索引，則表示密鑰交換失敗，OLT會重新啟動密鑰交換，如果密鑰交換的失敗次數為三次，則OLT會聲明一個LOKi并去激活ONU，其中，LOK表示密鑰丟失(Loss?of?Key)，i表示ONU的編號。

如果密鑰交換成功，則進入密鑰切換幀交換階段。在密鑰切換幀交換階段，OLT選擇一個未來的復幀(可以稱為密鑰切換幀)作為OLT和ONU開始使用新密鑰的第一幀，并將密鑰切換幀的復幀號通過Key_Switching_Time(密鑰切換時間)消息發送給ONU。ONU正確收到OLT發送的Key_Switching_Time消息則向OLT發送Acknowledge(確認)消息表示已經獲取密鑰切換幀的復幀號。如果OLT正確收到ONU發送的Acknowledge消息則表示密鑰切換幀交換成功，否則聲明一個LOAi(LOA，Loss?of?Acknowledge，確認丟失，i表示ONU編號)并去激活該ONU。

如果密鑰切換幀交換成功，則進入密鑰切換階段。在密鑰切換階段，OLT在開始發送密鑰切換幀時執行密鑰切換，具體為：復制本地shadow_key_register寄存器中的密鑰及索引到本地的active_key_register寄存器)，并用新密鑰對下行幀(包括密鑰切換幀)進行加密；ONU在接收到密鑰切換幀時執行密鑰切換(復制本地的shadow_key_register寄存器中的密鑰及索引到active_key_register(在用密鑰寄存器))并用新密鑰對下行幀(包括密鑰切換幀)進行解密。

GPON標準規定，如果ONU檢測到短暫的信號丟失(Loss?ofSignal，簡稱為LOS)/幀丟失(Loss?ofFrame，簡稱為LOF)，OLT可能會重新啟動密鑰管理過程(這種發送策略會導致密鑰請求消息的頻繁發送，加大了網絡負擔，并且在發送之前缺少對發送條件的判斷，因此發送處理是盲目執行的)，而密鑰管理的重新啟動可能會導致多個Request_Key消息先后到達ONU。