【正文】 存儲。接收來自發(fā)卡行的個人化文件時，文件信息必須：? 始終得到安全的存儲，訪問這些信息的權(quán)利必須嚴格地局限于業(yè)務(wù)需求者。? 在成功完成個人化之后，將生產(chǎn)系統(tǒng)內(nèi)的數(shù)據(jù)清除干凈。26 / 33另外，機密信息必須：? 在硬件安全模塊（HSM）上從KEK解譯成TK，以便將機密信息向前傳輸給個人化設(shè)備。此外，數(shù)據(jù)準備系統(tǒng)至少必須：? 位于一個能夠控制數(shù)據(jù)存取的中間安全區(qū)，并將數(shù)據(jù)訪問權(quán)局限于業(yè)務(wù)需求者。加密過程的安全要求應(yīng)適合于給定的數(shù)據(jù)組及IC卡用途，而且無論是在數(shù)據(jù)準備過程中，還是在個人化設(shè)備相關(guān)的本機處理過程中，都必須與相應(yīng)的加密過程協(xié)調(diào)一致。 個人化過程中的安全要求在個人化階段，個人化設(shè)備必須：? 在硬件安全模塊HSM上執(zhí)行中國金融集成電路（IC）卡K DEK推算過程。? 將個人化文件中的機密信息從傳輸密鑰TK 解譯成K DEK，以便將其傳送給卡片。這一解譯過程必須在HSM上執(zhí)行。另外，個人化設(shè)備必須：? 安裝在工廠的高安全區(qū)并符合中國金融集成電路（IC）卡生產(chǎn)安全標準規(guī)定的一切安全要求和程序要求。 操作不同類型的加密算法支持 EMV 規(guī)范中的不同功能。然而，當加密算法沒有得到正確實施時，加密算法的預定作用將受到負面的影響。一種安全的實施將取決于規(guī)范所需的不同密鑰被簽發(fā)者管理的好壞程度。以下材料的目的是提供不同算法類型所扮演的加密角色的一個概述，以及提出安全地管理密鑰所必需的基本要求。1. 非對稱（RSA）密鑰管理IC卡的安全性取決于私有（簽名）密鑰的保護。不能保證用來對靜態(tài)或動態(tài)數(shù)據(jù)元素簽名的私有密鑰的安全性將使IC卡面臨被偽造的風險。私有密鑰面臨的主要風險包括（1）成功地分解RSA 模數(shù)（ 2）私有密鑰自身的泄漏。為了限制這些風險所代表的潛在的泄露問題，我們推薦使用以下簽發(fā)商要求。私有（簽名）密鑰的安全性取決于許多因素，包括：? RSA密鑰模數(shù)位的長度；例如：76891024和1152，? 組成公共/私有密鑰模數(shù)的主要數(shù)字的質(zhì)量，以及? 用來從物理上保障（保護）私有（簽名）密鑰不受未經(jīng)授權(quán)的訪問和暴露/危害的影響的方法。特別是當IC卡或其它安全加密設(shè)備（SCD）使用它們時為密鑰提供的保護。27 / 33RSA密鑰生成當生成RSA 公/私鑰對時，推薦在一臺物理安全的設(shè)備的受保護內(nèi)存中完成這個過程。這種設(shè)備必須包含一個隨機或偽隨機數(shù)字生成器，執(zhí)行原始校驗例程，并支持篡改響應(yīng)機制。? RSA私有（簽名）密鑰可能對物理安全設(shè)備而言是暫時性的。? 密鑰生成將利用一個隨機或偽隨機過程，以使得不可能預測出任何密鑰或者確定密鑰空間中的某些密鑰比其它任意密鑰可能性更大。? 個人計算機或其它類似的不安全設(shè)備，即不被信任的設(shè)備，將永遠不能用來生成RAS公/私鑰對。密鑰傳輸和存儲為了保護公/私鑰對的完整性，對簽發(fā)商而言，確保這種密鑰數(shù)據(jù)使用以下步驟非常重要。? 公鑰應(yīng)該用一種能夠保證它們完整性的方式來保障安全和傳輸。推薦公鑰始終在諸如一個證書之類的數(shù)據(jù)結(jié)構(gòu)中傳輸，或者利用一個由 ISO 9807 和僅用于這個用途的一個密鑰定義的算法將消息驗證代碼 （MAC） 用于公鑰和相關(guān)的數(shù)據(jù)。也推薦使用雙重控制技巧來確保公鑰的接收方有辦法驗證它的發(fā)送方和完整性，即通過公鑰上的一個校驗值的單獨和獨立的傳輸來實現(xiàn)這一點。? 私鑰必須用一種能夠保證它們的完整性和私密的方式來保障安全和傳輸。傳輸機制可能包括：? 一臺安全加密設(shè)備? 利用至少與加密相等力量的對稱算法來對被保護密鑰的私鑰進行解密，或者? 作為幾個部分（在IC卡上保障安全） ，并使用一個對稱算法來進行解密。2. 對稱（DES）密鑰管理EMV規(guī)范中的DES密鑰用于特殊的事務(wù)功能。DES密鑰是在個人化期間從一個主導出密鑰（Master Derivation Key）中導出的。最終的卡片級密鑰是唯一的。? 簽發(fā)商主導出密鑰（ID KAC）——用來導出用于生成稱為應(yīng)用密文 （AC）的MAC的卡片密鑰。? 簽發(fā)商安全消息主密鑰（IMK SMC IMKSMI）——用來導出卡片密鑰，這些卡片密鑰用在卡片和驗證系統(tǒng)之間的安全消息中，即卡片鎖定、應(yīng)用鎖定/解鎖、更新卡片特定數(shù)據(jù)和修改PIN。密鑰生成發(fā)卡行將使用以下原則來使密鑰數(shù)據(jù)在創(chuàng)建期間泄漏的機會最小化。? 在生成DES密鑰時，它們必須要么在一臺由篡改響應(yīng)機制保護的物理安全的設(shè)備中生成，要么必須由授權(quán)的工作人員以一部分一部分的形式生成（參見下文） 。設(shè)備必須包含一個隨機或偽隨機的數(shù)字生成器。? 任何時候一個未被保護的密鑰都不能存在于一臺物理安全的設(shè)備的被保護內(nèi)存之外。任何時候物理安全的設(shè)備都不能輸出純文本的密鑰，除非作為密碼或者以兩個或更多部分的形式輸出。28 / 33? 當密鑰由授權(quán)工作人員通過一個將各部分組合的過程來生成時，必須要求每一方生成一個和要生成的密鑰一樣長的部分。密鑰組合過程在一個物理安全的設(shè)備內(nèi)部進行。此外，組合各部分的方法應(yīng)當是，知道了各部分的任何一個子集也無法知道密鑰值。分開的密鑰由一個管理機構(gòu)掌握，至少應(yīng)有一個部分持有人是發(fā)卡行的一名員工。? 應(yīng)當為實際密鑰的全部計算校驗位。? 個人電腦或類似的不安全設(shè)備永遠不能用來生成密鑰資料。? 如果發(fā)現(xiàn)任何密鑰存在于一個物理安全的設(shè)備之外，或者密鑰的各個部分被人所知，或者有被單個人掌握的嫌疑，那么該密鑰將被認為已被泄漏，并且必須用一個新的密鑰來替換它。密鑰傳輸和存儲DES 密鑰可能需要被傳輸和存儲。例如包括將DES密鑰從發(fā)卡行的站點傳輸給一個第三方的處理商或卡片個性化供應(yīng)商。當DES密鑰正被傳輸或存儲時，以下措施將限制數(shù)據(jù)泄漏的潛在危險。? DES密鑰可以被安全地轉(zhuǎn)移到一塊安全令牌或智能卡的保護之下，以進行傳輸和存儲。? DES 密鑰只能以以下方式之一在安全令牌或智能卡的受保護內(nèi)存之內(nèi)進行傳輸或存儲：利用雙重控制和分持機密的原則，以兩個或更多部分的形式或者作為密碼，密碼是用一個由各方安全地建立的傳輸或存儲密鑰來創(chuàng)建的。1. 一旦接收到密鑰資料，負責的密鑰管理人員必須立即檢查郵包是否篡改，并且必須驗證內(nèi)容。2. 如果接收的管理人員對密鑰數(shù)據(jù)的完整性有任何不確定的地方，必須立即通知發(fā)送方。發(fā)送方與接收方商議決定密鑰數(shù)據(jù)將來的狀況。關(guān)于繼續(xù)使用密鑰資料的任何決定的基礎(chǔ)必須記錄在案并由雙方保留。3. 如果硬拷貝數(shù)據(jù)要保留任意一段時間，那么各個硬拷貝組成部分、安全令牌或智能卡必須保存在一個序列化的保密信封中。4. 這個序列化的保密信封必須持續(xù)保存在一個物理安全的容器中，這個容器僅能由指定的密鑰管理人員或預備人員訪問。每次對密鑰數(shù)據(jù)的訪問都必須記入日志，包括時間、日期、信封序列號、目的和簽名。這些日志將可以向任何相應(yīng)的請求機構(gòu)提供。5. 密鑰資料永遠不能在超過任務(wù)所需的訪問必需的時間之后保留在保密信封和它們的物理安全的環(huán)境之外。下面給出了關(guān)于密鑰存儲問題的一些一般的指導，它適用于非對稱和對稱密鑰存儲：1. PC板的使用29 / 33一塊向主機提供加密服務(wù)的 PC 板可以看作是 HSM 的一種形式和類似的期望保護級別。注意：使用加密安全設(shè)備的主要原因是保護密鑰。如果使用 HSM 主機的系統(tǒng)自身是不安全的，那么攻擊者將更容易危害系統(tǒng)的軟件功能，而忽略 HSM。2. 訪問控制所有在卡外和HSM外保存的密鑰都應(yīng)當保持在至少雙重的控制之下。3. HSM和IC安全內(nèi)存一般而言，HSM將包含單獨的存儲和處理設(shè)備，而密鑰資料將跨內(nèi)部硬件總線傳送。由于這個原因，當檢測到了危害時，HSM清除（或歸零）它的內(nèi)存是很重要的。此外，HSM的硬件設(shè)計解決電磁輻射的問題也很重要。HSM一般設(shè)計位于一個安全的環(huán)境之中。發(fā)卡行在發(fā)卡之前必須執(zhí)行以下幾個步驟，這些步驟有時還需要在使用支付系統(tǒng)的過程中得以執(zhí)行。? 生成發(fā)卡行密鑰對發(fā)卡行必須安全地生成并保存一對或幾對公鑰和私鑰。私鑰將被用來簽署IC卡靜態(tài)數(shù)據(jù)或IC卡公鑰證書（這取決于IC卡各自執(zhí)行的數(shù)據(jù)認證是靜態(tài)的還是動態(tài)的） 。在支付模式允許的情況下，建議發(fā)卡行為每個銀行標識碼（BIN）或首標分配不同的密鑰對，這樣，一旦發(fā)卡行的私鑰被泄密，就可以把相應(yīng)的BIN鎖閉起來。? 生成發(fā)卡行密鑰發(fā)卡行必須根據(jù)IC卡密鑰的推算需要而安全地生成并保存一個或幾個密鑰。? 接收“CA 公鑰（PBOC Public Key） ”發(fā)卡行必須接收并安全地保存一個或幾個CA公鑰。這些公鑰必須以一定的方式進行傳輸，使發(fā)卡行能夠?qū)λ鼈兊耐暾院蛿?shù)據(jù)源進行核實。CA公鑰將用來驗證發(fā)卡行公鑰驗證證書。? 請求并接收發(fā)卡行公鑰證書就發(fā)卡行公鑰而言，發(fā)卡行必須獲得相應(yīng)的發(fā)卡行公鑰證書。為此，須將每個發(fā)卡行公鑰傳輸給CA認證機構(gòu)（PBOC CA） ，繼而發(fā)卡行會收到發(fā)卡行的公鑰證書。發(fā)卡行公鑰必須以一定的方式傳輸給CA認證機構(gòu)，使之能夠?qū)€的完整性和數(shù)據(jù)源進行核實。接收CA認證機構(gòu)發(fā)來的公鑰驗證證書時，發(fā)卡行可以采用CA公鑰對證書進行驗證。? 傳輸“發(fā)卡行秘密關(guān)鍵碼”如果發(fā)卡行希望授權(quán)給第三方生成和驗證IC卡密碼，發(fā)卡行必須安全地將推算IC卡密鑰所使用的秘密關(guān)鍵碼安全地傳輸給第三方。30 / 33 管理規(guī)范負責管理秘密關(guān)鍵碼和密鑰元及其它密鑰數(shù)據(jù)設(shè)備的人員必須由不同的參與方（即發(fā)卡行、第三方處理商和/或IC卡個人化廠商）進行指派。指派專人負責監(jiān)控密鑰數(shù)據(jù)時，必須落實足夠的保密控制措施，以保證任何個人或未經(jīng)認可的個人沒有任何機會讀取密鑰的數(shù)據(jù)成分。密鑰保管人必須是正式受托的職員，決不可以是臨時傭工或顧問。另外，為了確保服務(wù)的連續(xù)性，可以把候補人員當作主要密鑰管理人的“備份” 。選擇“備用”管理人的標準應(yīng)該和選擇主要密鑰管理人的標準相同。密鑰管理人的責任重大，而且是發(fā)卡行安全協(xié)議的一個基本組成部分，他們所要管理的密鑰數(shù)據(jù)是發(fā)卡行發(fā)卡程序中最重要的加密操作碼。每個發(fā)卡行應(yīng)對內(nèi)部密鑰管理程序和下列業(yè)務(wù)的有關(guān)人員的作用進行核查：? 密鑰管理人員的職責包括密碼資料的控制、驗證和安全存儲。? 密鑰管理人或其“候補”的責任是：? 接收和安全存儲密鑰元；? 對讀取和使用密鑰數(shù)據(jù)的記錄或日志進行管理，包括讀取次數(shù)、日期、目的和重新安全存儲情況；? 對傳輸給發(fā)卡行控制權(quán)限以外的其它所有指定人員的密鑰數(shù)據(jù)進行驗證；? 對過期密鑰元的銷毀進行簽名作證；? 時常根據(jù)需要將密鑰數(shù)據(jù)輸入安全加密模塊；? 依據(jù)數(shù)據(jù)所有人的通知，指導和監(jiān)視過期密碼資料的銷毀。? 在密鑰數(shù)據(jù)的第一個數(shù)據(jù)源，密鑰管理人應(yīng)負責保護該數(shù)據(jù)，并將其轉(zhuǎn)發(fā)給接收單位的指定密鑰管理人，這個責任還包括對數(shù)據(jù)收訖進行驗證。請參見“銀聯(lián)”標識卡個人化企業(yè)安全和質(zhì)量管理指南 1. 數(shù)據(jù)傳輸安全管理請參見“銀聯(lián)”標識卡個人化企業(yè)安全和質(zhì)量管理指南 31 / 332. 數(shù)據(jù)存儲介質(zhì)的管理請參見“銀聯(lián)”標識卡個人化企業(yè)安全和質(zhì)量管理指南 3. 數(shù)據(jù)信息使用的控制請參見“銀聯(lián)”標識卡個人化企業(yè)安全和質(zhì)量管理指南 安全模塊防止篡改的要求篡改的防止可以分為兩個安全領(lǐng)域，（1）物理，和（2）邏輯。 物理安全屬性物理安全包括以下屬性：? 對侵入的保護，包括擦除敏感數(shù)據(jù)。? 對將導致敏感信息暴露的未授權(quán)修改的保護。? 防止對設(shè)備運轉(zhuǎn)帶來的電磁輻射的監(jiān)控的保護。 邏輯安全屬性邏輯安全特性包括以下屬性：? 真實性的驗證。? 設(shè)備功能集的設(shè)計確保沒有單個或設(shè)備功能的組合將導致敏感信息的泄露。? 存在的、用來確保密鑰分割的機制。? 敏感狀態(tài)操作需要雙重控制。? 包含的用來驗證軟件下載的技巧。 功能需求一個HSM 的最小的需求應(yīng)圍繞著對以下內(nèi)容的支持：? 密鑰值生成? 密鑰值交換? 密鑰配置文件分離（邏輯分割密鑰屬性）32 / 33? 密鑰值輸出和輸入? 密鑰值的安全存儲 安全模塊等級HSM須符合國家所訂之法規(guī)。 風險審計在每個IC卡應(yīng)用的個人化過程的最后，必須創(chuàng)建這個應(yīng)用的個人化過程的記錄。在整個個人化過程的最后，必須創(chuàng)建包含所有的IC卡應(yīng)用的個人化過程紀錄的審計文檔。對每一張IC卡的審計文檔的格式，請參考EMV Card Personalization Specification 之表21。這些記錄可保證對個人化過程的可審計性和可跟蹤性。