《電動汽車充換電服務信息交換》第四部分要點

《《電動汽車充換電服務信息交換》第四部分要點》由會員分享，可在線閱讀，更多相關《《電動汽車充換電服務信息交換》第四部分要點（16頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、ICS 35.240.60 L 73 T/CEC 中 國 電 力 企 業(yè) 聯(lián) 合 會 標 準 T/CEC XXXXX—XXXX 電動汽車充換電服務信息交換第 4 部分：數(shù)據(jù)傳輸與安全 Charging and battery swap service data interactive for electric vehicle Part4：Data exchange and Security （征求意見稿）

2、 XXXX- XX- XX發(fā)布 實施 XXXX- XX- XX 中 國 電 力 企 業(yè) 聯(lián) 合 會 標 準 T/CEC XXXXX — 201X 目 次 目 次 ............................................................................... I 前 言 ...........................

3、................................................... II 引 言 ............................................................................... I 1 范圍 ............................................................................... 1 2 規(guī)范性引用文件 ...................................................

4、.................. 1 3 術語和定義 ......................................................................... 1 4 數(shù)據(jù)傳輸體系 ....................................................................... 1 4.1 概述 ............................................................................. 1 4.2 數(shù)據(jù)傳輸

5、一般流程 ................................................................. 2 4.3 數(shù)據(jù)傳輸接口的基本要求 ........................................................... 2 5 平臺認證方式及規(guī)則 ................................................................. 2 5.1 概述 ................................................

6、............................. 2 5.2 平臺認證模式 ..................................................................... 2 5.3 平臺認證方法 ..................................................................... 3 6 數(shù)據(jù)傳輸方式及規(guī)則 ................................................................. 3 6.1 數(shù)據(jù)傳

7、輸接口規(guī)則 ................................................................. 3 6.2 接口調(diào)用方式 ..................................................................... 4 6.3 消息頭規(guī)范 ....................................................................... 4 6.4 消息主體規(guī)范 ..................................

8、................................... 4 6.5 批量數(shù)據(jù)傳輸 ..................................................................... 5 6.6 返回參數(shù)規(guī)則 ..................................................................... 5 7 密鑰的使用及管理 ................................................................... 6 7

9、.1 基本安全要求 ..................................................................... 6 7.2 密鑰的安全要求 ................................................................... 6 7.2.1 密鑰的產(chǎn)生 ................................................................... 6 7.2.2 密鑰的分發(fā) ...........................

10、........................................ 6 7.2.3 密鑰的存儲 ................................................................... 6 7.2.4 密鑰的銷毀 ................................................................... 6 7.3 數(shù)據(jù)的加密處理 ...................................................................

11、 6 7.3.1 數(shù)據(jù)加密規(guī)則 ................................................................. 6 7.3.2 數(shù)據(jù)加 / 解密方法 .............................................................. 7 7.3.3 數(shù)據(jù)加 / 解密示例 .............................................................. 8 附 錄 A （資料性附錄） 數(shù)字信封密鑰分發(fā)方式 ........

12、............................... 10 I T/CEC XXXXX — 201X 前 言 《電動汽車充換電服務信息交換》分為四個部分： ——第 1 部分：總則； ——第 2 部分：公共信息交換規(guī)范； ——第 3 部分：業(yè)務信息交換規(guī)范； ——第 4 部分：數(shù)據(jù)傳輸及安全； 本規(guī)范為第 4部分。 本規(guī)范按照 GB/T 1.1-2009 給出的規(guī)則編寫。 請注意本規(guī)范中的某些內(nèi)容可能涉及專利。本規(guī)范的發(fā)

13、布機構(gòu)不承擔識別這些專利的責任。 本規(guī)范由中國電力企業(yè)聯(lián)合會提出。 本規(guī)范由能源行業(yè)電動汽車充電設施標準化技術委員會歸口。 本規(guī)范主要起草單位： 本規(guī)范參加起草單位： 本規(guī)范主要起草人： 本標準為首次制定。 本標準在執(zhí)行過程中的意見或建議反饋至中國電力企業(yè)聯(lián)合會標準化中心（北京市白廣路二條一號， 100761）。 II

14、 /T XXXXX— XXXX 引 言 為加快電動汽車充電基礎設施建設， 促進不同充電服務平臺互聯(lián)互通， 構(gòu)建充電基礎設施信息服務信息交換體系架構(gòu)， 統(tǒng)一信息接口通信協(xié)議， 實現(xiàn)不同充電運營企業(yè)、 不同區(qū)域的充電服務設施、 第三 方平臺信息資源等互聯(lián)和充分利用， 實現(xiàn)充電設施網(wǎng)絡服務平臺間數(shù)據(jù)交換， 充電系統(tǒng)服務功能跨平臺信息交換服務，特制定本標準。

15、 I /T XXXXX— XXXX 電動汽車充換電服務信息交換 第 4 部分：數(shù)據(jù)傳輸與安全 1 范圍 本部分規(guī)定了電動汽車充換電服務信息交換的數(shù)據(jù)傳輸規(guī)范和安全要求， 包含充換電服務信息交換 的平臺認證規(guī)范、數(shù)據(jù)傳輸規(guī)范和數(shù)據(jù)傳輸安全要求。 本部分適用于歸屬不同運營商的電動汽車充換電運營服務平臺之間的充換電服務信息交換， 以及

16、電 動汽車充換電運營服務平臺與其他第三方服務及管理平臺之間的信息交換。 2 規(guī)范性引用文件 下列文件對于本文件的應用是必不可少的。 凡是注日期的引用文件， 僅所注日期的版本適用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。 GB/T 19596-2004 ：電動汽車術語 GB/T 29317-2012 ：電動汽車充換電設施術語 GB/T 2260-2007 中華人民共和國行政區(qū)域代碼 GB 11714-1997 全國組織機構(gòu)代碼編制規(guī)則 GB/T 31286-2014 全國組織

17、機構(gòu)代碼與名稱 GB/T 18391.1-2002 信息技術 數(shù)據(jù)元的規(guī)范與標準化 第 1部分：數(shù)據(jù)元的規(guī)范與標準化框架 GB/T 9387.1-1998 信息技術 開放系統(tǒng)互聯(lián) 基本參考模型 第 1部分：基本模型 GB/T 7408-2005 數(shù)據(jù)元和交換格式信息交換日期和時間表示法 GB/T 22239-2008 信息安全技術信息系統(tǒng)安全等級保護基本要求 GB/T 25070-2010 信息安全技術信息系統(tǒng)等級保護安全設計技術要求 GB/T 20271-2006 信息安全技術信息系統(tǒng)安全通用技術要求 GB/T 20988-20

18、07 信息安全技術信息系統(tǒng)災難恢復規(guī)范 GB/T 19596-2004 電動汽車術語 3 術語和定義 GB/T 19596、 GB/T 29317、 GB/Z 19027-2005 以及《電動汽車充換電服務信息交換 第1部分：總則》 中定義的以及下列術語和定義適用于本文件。 4 數(shù)據(jù)傳輸體系 4.1 概述 數(shù)據(jù)傳輸體系要求了參與電動汽車充換電服務的各角色和實體之間應在正常、 安全、有效的原則下 通過規(guī)范的接口進行信息交換， 相互協(xié)同地向電動汽車用戶提供充換電服務。 相關實體及其之間的信息 交換

19、接口參見《電動汽車充換電服務信息交換 第 1部分：總則》 。 電動汽車充換電服務信息通過數(shù)據(jù)傳輸接口進行交換， 數(shù)據(jù)傳輸接口眾多， 既存在于各個服務邏輯 層之間， 也存在于同一邏輯層的不同管理域之間， 數(shù)據(jù)傳輸接口可通過身份認證、 訪問控制、 數(shù)據(jù)加密、 數(shù)字簽名等安全措施，保障數(shù)據(jù)傳輸過程中要保障所傳輸數(shù)據(jù)的機密性和安全性。 1 /T XXXXX— XXXX 4.2 數(shù)據(jù)傳輸一般流程 電動汽車充換電服務信息交換一般需要經(jīng)過平臺認證、數(shù)據(jù)請求和數(shù)據(jù)返回 3個步驟。 平臺認證 數(shù)據(jù)請求 運營服務平臺 A

20、 運營服務平臺 B 數(shù)據(jù)返回 圖 1 電動汽車充換電服務信息交換流程 4.3 數(shù)據(jù)傳輸接口的基本要求 電動汽車充換電服務信息交換應根據(jù)國家信息安全等級保護相關要求。 運營商須提供嚴格的系統(tǒng)安全保密機制， 保障信息交換接口安全、 穩(wěn)定、可靠地運行， 包括信息的存取控制、應用系統(tǒng)操作的安全等?；疽螅? 1) 采用身份認證、訪問控制、數(shù)據(jù)加密、數(shù)字簽名等安全措施； 2) 采用安全可靠并且普遍使用的加密算法； 3) 密鑰的存貯和交易信息的加密／解密需要在安全的環(huán)境中； 4) 遵循數(shù)據(jù)安全保密的國家和行業(yè)標準； 5) 定期更

21、換密鑰； 6) 具備對報文做來源正確性鑒別的機制（ HMAC）。 5 平臺認證方式及規(guī)則 5.1 概述 電動汽車充換電服務信息交換應具備平臺認證服務提供平臺之間的鑒權認證功能。 平臺之間在信息 交換前，需完成平臺認證，獲得平臺交換能力。 5.2 平臺認證模式 平臺認證支持分布式認證模式和中心交換認證模式。 分布式認證模式由運營商之間進行鑒權認證，運營商之間確定運營商標識（ OperatorID ）、運營商 密鑰（ Operator_Secret ）和消息密鑰（ Data_Secret ），具體認證方式可由運營商協(xié)商確

22、定。 中心交換認證模式由統(tǒng)一的認證服務方提供鑒權認證服務， 運營商與中心認證服務方確定運營商標 識（ OperatorID ）、運營商密鑰（ Operator_Secret ）和消息密鑰（ Data_Secret ），具體認證方式由各運營商和認證服務方共同確定。 運營服務平臺 B 運營服務平臺 A 運營服務平臺 C 圖 2 分布式認證模式 2 /T XXXXX— XXXX 運營服務平臺 B

23、 中心認證服務 運營服務平臺 A 運營服務平臺 C 圖 3 中心交換認證模式 5.3 平臺認證方法 平臺認證宜采取身份認證和訪問控制相結(jié)合的方式進行。 身份認證可采取用戶名 / 口令認證、密鑰認證或數(shù)字證書認證等方式進行；訪問控制可采取 IP 訪問 控制、時間訪問控制等多種手段結(jié)合。 用戶身份認證成功后授予 Token，每次向服務端請求資源的時候需要帶著服務端簽發(fā)的 Token，服務 端驗證 Token成功后， 才返回請求的數(shù)據(jù)。 Token的有效期不宜大于

24、7天，Token丟失或失效后需要再次發(fā) 起認證服務。 訪問控制 發(fā)送身份信息 認 請求發(fā)起方 認證服務 證 返回 Token 成 功 圖4 平臺認證方式 6 數(shù)據(jù)傳輸方式及規(guī)則 6.1 數(shù)據(jù)傳輸接口規(guī)則 所有數(shù)據(jù)傳輸接口均采用 HTTP(S)接口，每個接口的 URL均采用如下格式定義： http(s)://[域名 ]/evcs/v[ 版本號 ]/[ 接口名稱 ] 1) 域名：各接入運營商所

25、屬域名。 2) 版本號：代表接口版本號，不同的版本地址對應相應版本代碼。系統(tǒng)升級期間，新舊版本可同時 存在，待所有接入方都切換到新接口，舊接口即可下線。從而達到平滑升級的目的。 3) 接口名稱： 所請求 / 調(diào)用接口的名稱， 具體接口名稱見 《電動汽車充換電服務信息交換 第 2部分： 公共信息交換規(guī)范》和《電動汽車充換電服務信息交換 第 3部分：業(yè)務信息交換規(guī)范》。 為保證各接口的功能明確清晰，每個 URL只允許對應一種功能。其中測試例分類 : 3 /T XXXXX— XXXX 6.2 接口 用方式 所有接口

26、均使用 HTTP(S)/POST方式 參數(shù)， 程中 包含消息 和消息主體兩部分。 6.3 消息 范 消息 一般需包含內(nèi)容 型， 內(nèi)容 型 （Content-Type ）字段用于 求中的消息主體的 方 式，本 準中所 范的信息交 內(nèi)容均采用 JSON的方式，參數(shù)信息采用 utf-8 ，因此需要配置消息 中的 Content-Type 為 application/json;charset=utf-8 。 6.4 消息主體 范 6.4.1 消息主體的 成 消息主體是信息交 程中的具體內(nèi)容，一般由運 商 （ OperatorI

27、D ）、憑 （ Token）、參 數(shù)內(nèi)容（ Data ）、 戳（ TimeStamp）和數(shù)字 名（ Sig ） 成。 表 1 消息主體內(nèi)容表 參數(shù)名 明 例 Token 行的憑 Data 各接口具體參數(shù)信息 Data: { [ ‘ stationID ’ : 充 站 ID, ‘ platformID ’: 屬運 平臺所 有方 ID, xxxxxxxxx, ], ?? [ ‘ stationID ’ : 充 站 ID, ‘ platformID ’: 屬運 平臺所

28、 有方 ID, xxxxxxxxx, ] } 接 口 請 求 時 時 間 戳 信 息 , 格 式 為 TimeStamp 戳 yyyyMMddHHmmss Sig 參數(shù) 名 6.4.2 參數(shù) 名 參數(shù) 名采用 HMAC-MD5算法，采用 MD5作 散列函數(shù)， 通 密 （ Operator_Secret ） 整個消息主體 行加密，然后 采 用 Md5信息摘要的方式形成新的密文。 （ 1） HMAC-MD5算法 HMAC（ K， M） =H（ K⊕ opad ∣H（ K⊕ ipad ∣ M）） 4

29、 /T XXXXX— XXXX 其中 :K 是密鑰（ Operator_Secret ），長度可為 64字節(jié)，若小于該長度，在密鑰后面用“ 0”補齊。 M 是消息內(nèi)容； H 是散列函數(shù)； opad 和 Ipad 分別是由若干個 0x5c和 0x36組成的字符串； ⊕表示異或運算； ∣表示連接操作。 （ 2） HMAC-MD5流程 1) 在密鑰（ Operator_Secret ）后面添加 0來創(chuàng)建一個長為 64字節(jié)的字符串 (str) ； 2) 將上一步生成的字符串 (str) 與 ipad(0x36)

30、 做異或運算，形成結(jié)果字符串 (istr) ； 3) 將消息內(nèi)容 data 附加到第二步的結(jié)果字符串 (istr) 的末尾； 4) 做 md5運算于第三步生成的數(shù)據(jù)流 (istr) ； 5) 將第一步生成的字符串 (str) 與 opad(0x5c) 做異或運算，形成結(jié)果字符串 (ostr) ； 6) 再將第四步的結(jié)果 (istr) 附加到第五步的結(jié)果字符串 (ostr) 的末尾； 7) 做 md5運算于第六步生成的數(shù)據(jù)流 (ostr) ，輸出最終結(jié)果 (out) 。 6.4.3 參數(shù)傳遞要求 參數(shù)

31、傳遞過程中的所有參數(shù)都要先進行 urlencode 轉(zhuǎn)義，然后再按照 key=value 格式使用 &連接在一 起。 6.5 批量數(shù)據(jù)傳輸 數(shù)據(jù)傳輸接口中的 Data 字段可為數(shù)組型的 JSON格式，數(shù)據(jù)發(fā)送方可通過該字段實現(xiàn)批量數(shù)據(jù)的傳 輸。 6.6 返回參數(shù)規(guī)則 數(shù)據(jù)傳輸接口的返回參數(shù)包括兩個部分： ret, msg 。 1)ret: 必填字段，返回編碼參考下表。 2)msg: 可選字段，當 ret!=0 是存在，表示具體錯誤信息。 3) 采用 utf-8 編碼， JSON格式。 4) 舉例： ｛ ‘r

32、et ’: 401, ‘msg’: ‘Invalid signature ’,｝ 表 2 返回參數(shù)編碼表 Ret 值 說明 -1 系統(tǒng)繁忙，此時請求方稍后重試 0 請求成功 401 簽名錯誤 402 Token 錯誤 403 POST參數(shù)不合法 , 缺少必須的示例： OperatorID,sig,TimeStamp,Data 四個參數(shù) 404 請求的業(yè)務參數(shù)不合法，各接口定義自己的必須參數(shù) 5 /T XXXXX— XXXX 500 系統(tǒng)錯誤 7 密鑰的使用及

33、管理 各運營商系統(tǒng)間在消息傳遞時，需要保障傳輸和接收數(shù)據(jù)的安全和完整。 7.1 基本安全要求 運營商必須滿足數(shù)據(jù)安全傳輸控制方面的要求。 運營商必須提供嚴格的系統(tǒng)安全保密機制，保障信息交換接口安全、穩(wěn)定、 可靠地運行，包括信息的存取控制、應用系統(tǒng)操作的安全等。 7.2 密鑰的安全要求 密碼算法用于密鑰的產(chǎn)生、 分發(fā)、 HMAC以及加密等安全功能， 相關的算法模塊在其生命周期內(nèi)不能被修改、導出至安全環(huán)境外部。 指定功能的密鑰僅能做指定功能使用，不能被其他任何功能使用。 7.2.1 密鑰的產(chǎn)生 數(shù)據(jù)密鑰應具備隨機產(chǎn)生特性，密

34、鑰產(chǎn)生后要檢查密鑰的有效性，弱密鑰和半弱密鑰需被剔除。 運營商加入信息交換時，必須申請獨立的密鑰文件，密鑰可由運營商協(xié)商產(chǎn)生。 7.2.2 密鑰的分發(fā) 密鑰的分發(fā)應該由安全方式進行，可通過聯(lián)機報文或數(shù)字信封的方式加密傳輸。 7.2.3 密鑰的存儲 密鑰宜保存在硬件加密機內(nèi)。如果出現(xiàn)在硬件加密機外，則必須密文方式出現(xiàn)。 密鑰注入、 密鑰管理和密鑰檔案的保管應由專人負責。 使用密鑰和銷毀密鑰要在監(jiān)督下進行并應有使用、銷毀記錄。 7.2.4 密鑰的銷毀 當新密鑰產(chǎn)生后， 生命期結(jié)束的舊密鑰必須從數(shù)據(jù)庫和內(nèi)存中清除， 防止被替換使用； 同時所

35、有可能重新構(gòu)造此密鑰的信息也必須清除。新密鑰成功啟用和舊密鑰自動銷毀的記錄將被更新。 7.3 數(shù)據(jù)的加密處理 每個運營商交互前需要分配 運營商標識（ OperatorID ）、運營商密鑰（ Operator_Secret ）和消息密鑰（ Data_Secret ）。 1) 運營商標識（ OperatorID ） : 固定 9位，運營商的組織機構(gòu)代碼，作為運營商的唯一標示。 2) 運營商密鑰（ Operator_Secret ）: 可采用 32H、48H和64H，由 0-F 字符組成，為簽名的加密密鑰。 3) 消息密鑰（ Data_Secret ）:

36、用于對所有接口中 Data 信息進行加密。 7.3.1 數(shù)據(jù)加密規(guī)則 消息發(fā)送方需要對 Data字段中涉及交易及隱私等數(shù)據(jù)利用消息密鑰（ Data_Secret ）進行加密，加 密算法宜使用 AES加密。 6 /T XXXXX— XXXX 消息接收方收到消息之后，根據(jù)消息密鑰（ Data_Secret ）對消息體中的 Data 數(shù)據(jù)進行解密，校驗參數(shù)合法性等后續(xù)業(yè)務處理。 7.3.2 數(shù)據(jù)加 / 解密方法 數(shù)據(jù)傳輸?shù)募用苁褂脤ΨQ加密算法 AES加密， AES算法的密鑰長度、分組長度和輪數(shù)的關系如表 3所

37、 示。 表 3 Key-Block-Round 關系 密鑰長度 分組長度 輪數(shù) (Nk words) (Nb words) (Nr) 4 4 10 6 4 12 8 4 14 對于 AES加密和解密變換， AES算法使用的輪函數(shù)由 4個不同的以字節(jié)為基本單位的變換復合而成，該過程由四個不同的階段組成： 1)S 盒變換，用一個 S盒完成分組中的按字節(jié)代替； 2) 行移位變換，一個簡單的置換； 3) 列混淆變換，一個利用在域 GF(28) 上的算術性的代替； 4) 輪密鑰加變換，一個利用當前分組和擴展密鑰的一個部分進行按

38、位異或。 AES對數(shù)據(jù)的加密過程是通過把輸入的明文和密鑰由輪函數(shù)經(jīng) Nr輪迭代來實現(xiàn)的，結(jié)尾輪與前 Nr-1 輪不同。前 Nr-1 輪依次進行 S盒變換、行移位變換、列混淆變換和輪密鑰加變換；結(jié)尾輪與前 Nr-1 輪相 比去掉了列混淆變換。 而解密過程與加密過程相反， 通過把輸入的密文和密鑰由輪函數(shù)經(jīng) Nr輪迭代來實現(xiàn)的， 結(jié)尾輪與前 Nr-1 輪不同。前 Nr-1 輪依次進行逆行移位變換、逆 S盒變換、輪密鑰加變換和逆列混淆變換；結(jié)尾輪與 前 Nr-1 輪相比去掉了逆列混淆變換。 AES算法的加密解密過程如圖 5所示。

39、 7 密鑰 密鑰擴展 明文 明文 W[0] ~ W[3] 輪密鑰加變換 逆列混淆變換 S盒變換 逆 S盒變換 第 行移位變換 逆行移位變換 一 輪 列混淆變換 逆列混淆變換 W[4] ~ W[7] 輪密鑰加變換 輪密鑰加變換 逆 S盒變換 逆行

40、移位變換 S盒變換 第 （ 行移位變換 Nr-1 ） 列混淆變換 逆列混淆變換 輪 W[4(Nr-1)] ~ W[4Nr-1] 輪密鑰加變換 輪密鑰加變換 逆 S盒變換 S盒變換 最 逆行移位變換 后 行移位變換 一 W[4Nr] ~ W[4(Nr+1)-1] 輪 輪密鑰加變換 輪密鑰加變換 密文 密文 加密 解密 圖 5 AES加 / 解密過程圖 7.

41、3.3 數(shù)據(jù)加 / 解密示例 密鑰： 1234567890abcdef  /T XXXXX— XXXX 最 后 一 輪 第 （ Nr-1 ） 輪 第 一 輪 8 /T XXXXX— XXXX 明文信息： 示例： {"total":1,"stationStatu

42、sInfo":{"operationID":"123456789","stationID":"111111111111111","con nectorStatusInfos":{"connectorID":1,"equipmentID":"10000000000000000000001","status":4, "currentA":0,"currentB":0,"currentC":0,"voltageA":0,"voltageB":0,"voltageC":0,"soc":10,} 秘文： 示例： DHVWF+8xRIfU7nUCNQdLaGF15V

43、aMZWtNcwaqeumUPe/ok9zgSkR0pbOJUmYYQs7ZFMN7GhLB 1ywEN3kb1gH4z+Mc2Z4rQe8Xa42LrmkDRvwwosmVMuR+mbLFCG+Xf5unkRO6JJx1PiTAxAB6o yWqUmbOKskK81LqpWBU5fKnBZwXo3jv2hnKItwCODYw+B+Pg+0IzZ5ye5cKcwz99NO5//H2gU 0scZhn+rl8Jcktbm42TVklnxdzG/aw200H2z9ugpB1q2X0sGAi55SQH3DbLpWb5oQE5vy0As7lje4e +4dE8vbL

44、IR0dMw8/lA9cBPYRO2WOkH6SFwFUyi+IishP8j+mzEcfoyAOIUSh5G/5VYqlYu1zlVUsY CHWu7MTE1Gr55SicHZQxl5KHgmgFBw8OQl8DerA++D8vswR8eiRNcXR2MQmNXYarCmZ7Kuc6 mRSbrSk2cImOZAywVIo6MpBSu/u0BINysS3S7Ni1LB6zqAu3Ly0yNbbxzz+ZpHjmAM+MMsx4/K 6LtG1rhiW8iE3bbGOLJqu9njLFVLQtKXrVsUnF4b1FWuIADG3FBCXqcdyTTTj5vNwI2xx

45、Fm/zq5lvJ UKUlcFPvYSwBQFsjKHZnl8= 9 /T XXXXX— XXXX 附 錄 A （資料性附錄） 數(shù)字信封密鑰分發(fā)方式 A.1 數(shù)字信封的定義 數(shù)字信封是公鑰密碼體制在實際中的一個應用， 是用加密技術來保證只有規(guī)定的特定收信人才能閱讀通信的

46、內(nèi)容。 A.2 數(shù)字信封的原理 在數(shù)字信封中， 信息發(fā)送方采用對稱密鑰來加密信息內(nèi)容， 然后將此對稱密鑰用接收方的公開密鑰來加密（這部分稱數(shù)字信封）之后， 將它和加密后的信息一起發(fā)送給接收方，接收方先用相應的私有密鑰打開數(shù)字信封，得到對稱密鑰，然后使用對稱密鑰解開加密信息，這種技術的安全性相當高。 數(shù)字信封主要包括數(shù)字信封打包和數(shù)字信封拆解， 數(shù)字信封打包是使用對方的公鑰將加密密鑰進行 加密的過程， 只有對方的私鑰才能將加密后的數(shù)據(jù) ( 通信密鑰 ) 還原；數(shù)字信封拆解是使用私鑰將加密過的數(shù)據(jù)解密的過程。 A.3 密鑰的更換 數(shù)字

47、信封的功能類似于普通信封， 普通信封在法律的約束下保證只有收信人才能閱讀信的內(nèi)容； 數(shù) 字信封則采用密碼技術保證了只有規(guī)定的接收人才能閱讀信息的內(nèi)容。 數(shù)字信封中采用了對稱密碼體制 和公鑰密碼體制。 信息發(fā)送者首先利用隨機產(chǎn)生的對稱密碼加密信息， 再利用接收方的公鑰加密對稱密 碼，被公鑰加密后的對稱密碼被稱之為數(shù)字信封。 在傳遞信息時， 信息接收方若要解密信息， 必須先用 自己的私鑰解密數(shù)字信封， 得到對稱密碼， 才能利用對稱密碼解密所得到的信息。 這樣就保證了數(shù)據(jù)傳輸?shù)恼鎸嵭院屯暾浴? _________________________________ 10