1、1 印月968月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.240.01 X6022-1514176-15 經濟部標準檢驗局印 公布日期 修訂公布日期 968月21日 月日 (共21頁)醫學數位影像及通信 第 15 部：安全規範 Digital imaging and communications in medicine (DICOM) Part 15: Security profile 目錄 節次 頁次 1. 適用範圍 . 2 2. 引用標準 . 2 3. 用語釋義 . 3 3.1 參考模型定義 3 3.2 參考模型安全架構定義 . 3 3.3 ACSE 服
2、務定義 4 3.4 安全定義 . 4 3.5 DICOM 簡介及概述定義 . 4 3.6 DICOM 符合性定義 4 3.7 DICOM 資訊物件定義 4 3.8 DICOM 服務類別定義 4 3.9 DICOM 通信支援定義 4 3.10 DICOM 安全剖繪定義 . 4 4. 符號與縮寫 5 5. 規約 6 6. 安全剖繪概要 6 6.1 安全使用剖繪 6 6.2 安全傳送連結剖繪 . 6 6.3 數位簽章剖繪 6 6.4 媒體儲存安全剖繪 . 7 附錄 A 安全使用剖繪 . 8 附錄 B 安全傳送連結剖繪 .11 附錄 C 數位簽章剖繪 13 附錄 D 媒體儲存安全剖繪 .15 附錄 E
3、 屬性機密性剖繪 .16 【英中名詞對照表】 .21 2 CNS 14176-15, X 6022-15 1. 適用範圍 本標準旨在規範安全剖繪，使其實作可宣稱符合性。 對於任何層級之安全而言，嚴守適當之安全政策是必要的，但本標準並未涉及安全政策之議題。本標準僅提供可用於 DICOM 物件在應用個體之間交換時，實作安全政策之機制。例如，安全政策可規範某層級之存取控制，本標準並不考慮存取控制政策，但提供可使應用個體交換充足資訊之技術方法，以建立存取控制政策。 本標準認為涉及 DICOM 交換中之應用個體需建立合適的安全政策，包括 (但不限於 )存取控制、稽核存底、實體保護、維持資料之機密性及完整
4、性、以及識別使用者及其對存取資料權限之機制。基本上，每一應用個體在欲與其他之應用個體進行安全通信前須確認本身所處環境是安全的。 當應用個體經過結合協商同意藉由 DICOM 來互換資訊時，基本上是同意對其他之應用個體間有某些層級上的信任。應用個體要信任其通信夥伴會維持資料之機密性和完整性。該信任層級是由當地之安全與存取控制政策來決定。 應用個體可能不信任與其他應用個體通信時之通信通道。因此，本標準對應用個體提供一些機制來安全地鑑別彼此身分，偵測所交換訊息是否被竄改或置換，及保護經過通信通道之訊息的機密性。應用個體可視其對通信通道之信任層級，任意選用這些機制。 本標準認為應用個體能安全地識別此應用
5、個體之本地使用者及其使用者的角色或授權。使用者可以是個人或是抽象個體；例如，組織單位或儀器設備。當應用個體同意透過 DICOM 作資訊交換時，他們也可能在所建立之安全通道中，透過憑證來交換應用個體使用者之資訊。之後，應用個體可以依據包含在憑證內之使用者資訊 (不論是本地或遠端 )來制定執行存取控制政策或產生稽核存底。 本標準也認為應用個體有方法決定這些資訊之所有者 (如：病人、機構 )是否已授權特定使用者或某類使用者來存取資訊。本標準進一步認為，應用個體所提供之存取控制已考慮到此類授權。目前本標準不考慮通信個體之間如何溝通此類授權，雖然未來也許會考慮此一課題。 本標準也認為使用 TLS 之應用
6、個體可以安全存取或獲得應用個體使用者之 X.509 金鑰憑證。此外，本標準也認為應用個體具備驗證所收到之 X 509 憑證能力。確認機制可使用當地之管理機構、認證機構或具公信力之第三方。 本標準認為使用 ISCL 之應用個體可使用適當之金鑰管理及配送系統 (如：智慧卡 )。此類金鑰管理及配送系統不屬於 DICOM 範圍，雖然在某些使用場合，它們也屬於安全政策的一部分。 2. 引用標準 CNS 13204 資訊處理系統開放系統互連基本參考模式 CNS 13397 資訊處理系統開放系統互連基本參考模型（免接模式傳輸） CNS 13858 資訊處理系統開放系統互連結合控制服務元件協定 CNS 141
7、05-3 資訊技術安全技術雜湊函數第 3 部：專屬雜湊函數 CNS 14176-1 醫學數位影像及通信第 1 部：簡介與概述 3 CNS 14176-15, X 6022-15 CNS 14176-2 醫學數位影像及通信第 2 部：符合性 CNS 14176-3 醫學數位影像及通信第 3 部：資訊物件定義 CNS 14176-4 醫學數位影像及通信第 4 部：服務類別規格 CNS 14176-8 醫學數位影像及通信第 8 部：訊息交換之網路通信支援 ANSI X9.52 American National Standards Institute. ANSI X9.52-1998, Triple
8、 data encryption algorithm modes of operation. 1998. ECMA 235 The ECMA GSS-API mechanism FIPS PUB 46 Data encryption standard FIPS PUB 81 DES modes of operation IETF internet X.509 public key infrastructure： Time stamp protocols; march 2000 ISO/IEC directives(1989) Part 3 Drafting and presentation o
9、f international standardscontrol service element integrated secure communication layer V1.00 MEDIS-DC ISO/IEC 9798-2 Information technology security techniques entity authentication Part 2: Mechanisms using symmetric encipherment algorithms. ITU-T Rec.X.509(03/00) Information technology Open systems
10、 Interconnection The directory: Public key and attribute certificate frameworks. RFC 2246 Transport tayer security (TLS) 1.0 Internet Engineering Task Force Note： TLS is derived from SSL 3.0, and is largely compatible with it. RFC-2313 PKCS #1 RSA Encryption, Version 1.5, March 1998. RFC 2437 PKCS #
11、1 RSA Cryptography Specifications Version 2.0 3. 用語釋義 下列定義適用於本標準： 3.1 參考模型定義 本標準引用下列定義於 CNS 13397 系列標準之用語： (a) 應用個體 (application entity) (b) 協定資料單元 (protocol data unit)或層協定資料單元 (layer protocol data unit) (c) 傳送連結 (transport connection) 3.2 參考模型安全架構定義 本標準引用下列定義於 CNS 13397 系列標準之用語： (a) 資料機密性 (data con
12、fidentiality) 備考：此定義為資訊不被未經授權之個人、個體或處理利用或揭露之性質。 (b) 資料起源鑑別 (data origin authentication) 備考：此定義為確認所接收到之資料來源是與所宣稱一致。 (c) 資料完整性 (data integrity) 備考：此定義為資料未經非授權方式改變或破壞之性質。 (d) 金鑰管理 (key management) 備考： 此定義為金鑰之產生、儲存、配送、刪除、歸檔及應用與安全政 策符合。 (e) 數位簽章 (digital signature) 4 CNS 14176-15, X 6022-15 備考： 此定義為一附加於資
13、料單元之資料或加密轉換，以使接收者能驗證資料單元之來源及完整性，並防止 (接收者 )偽造。 3.3 ACSE 服務定義 本標準引用下列定義於 CNS 13858 之用語： (a) 結合或應用結合 (association or application association) 3.4 安全定義 本標準引用下列定義於 ECMA 235 之用語： (a) 安全上下文 (security context) 備考： 此定義用來表示在啟始者或 接受者已形成安全結合或正試圖形成此安全結合時，所表現或將表現之安全資訊。 3.5 DICOM 簡介及概述定義 本標準引用下列定義於 CNS 14176-1 之用語
14、： (a) 屬性 (attribute) 3.6 DICOM 符合性定義 本標準引用下列定義於 CNS 14176-2 之用語： (a) 安全剖繪 (security profile) 3.7 DICOM 資訊物件定義 本標準引用下列定義於 CNS14176-3 之用語： (a) 模組 (module) 3.8 DICOM 服務類別定義 本標準引用下列定義於 CNS 14176-4 之用語： (a) 服務類別 (service Class) (b) 服務物件對 (SOP)實例 (service-object pair (SOP) instance) 3.9 DICOM 通信支援定義 本標準引用
15、定義於 CNS 14176-8 之用語： (a) DICOM 上層 (DICOM upper layer) 3.10 DICOM 安全剖繪定義 下列定義通用於本標準： (a) 安全傳送連結 (secure transport connection)：提供某種層級之保護以防止竄改、竊聽及偽造之傳送連結。 (b) 訊息鑑別碼 (message authentication code)：衍生自資料元件子集之摘要或雜湊碼。 (c) 憑證 (certificate)：用以識別某方及該方使用公開加密演算法、參 數及金鑰之電子文件。此外，此憑證尚包括發出憑證個體 之身份識別及數位簽章。憑證之內容及格式由國際
16、電信聯盟電信標準化小組 (ITU-T) X.509 所定義。 5 CNS 14176-15, X 6022-15 4. 符號與縮寫 下列符號與縮寫適用於本標準： ACR 美國放射醫學會 (American College of Radiology ) AE 應用個體 (application entity) ANSI 美國國家標準局 (American National Standards Institute) CEN TC251 歐洲標準委員會 -251技術委員會 -醫療資訊學 (Comite European de Normalisation-Technical Committee 251
17、 Medical Informatics) CBC 密文區段鏈接 (cipher block chaining) CCIR 國際無線電諮詢委員會 (Consultative Committee,International Radio) DES 資料加密標準 (data encryption standard) DICOM 醫學數位影像及通信 (Digital Imaging and Communications in Medicine ) ECMA 歐洲電腦製造業協會 (European Computer Manufacturers Association) EDE 加密 -解密 -加密 (e
18、ncrypt-decrypt-encrypt) HL7 健康資訊交換第七層協定 (Health Level 7) IEEE 美國電機電子工程師協會 (Institute of Electrical and Electronics Engineers) IEC 國際電工委員會 (International Electrical Commission) IOD 資訊物件定義 (information object definition) ISCL 整合安全通信層 (integrated secure communication layer) ISO 國際標準組織 (International Or
19、ganization for Standardization) JIRA 日本放射儀器 工業協會 (Japan Industries association of RAdiation system) MAC 訊息鑑別碼 (message authentication code) MD-5 訊息摘要演算法 5(message digest 5) MEDIS-DC 醫學資訊系統發展中心 (medical information system development Center) NEMA 美國電機製造業協會 (National Electrical Manufacturers Associati
20、on) PDU 協定資料單元 (protocol data unit) RSA RSA加密演算法 (rivest, shamir, adleman) SCP 服務類別提供者 (service class provider) SCU 服務類別使用者 (service class user) SHA 安全雜湊演算法 (secure hash algorithm) SOP 服務物件對 (service-object pair) SSL 安全通道層 (secure sockets layer) TLS 傳送層安全 (transport layer security) UID 唯一識別符 (unique
21、 identifier) 6 CNS 14176-15, X 6022-15 5. 規約 在本標準中，如有使用到第 3 節所定義之用語縮寫，皆以英文大寫表示。 6. 安全剖繪概要 一實作可對個別之安全剖繪宣稱符合性，亦可宣稱對多個安全剖繪之符合性。在其符合性聲明中，應指出對任一交易所選擇使用之剖繪。 6.1 安全使用剖繪 可宣稱一或多個安全使用剖繪 符合性之實作。這些剖繪以特定形式概述屬性及其他安全剖繪的使用。 安全使用剖繪，規範於附錄 A 中。 6.2 安全傳送連結剖繪 可宣稱對一或多個安全傳送連結剖繪符合性之實作。 安全傳送連結剖繪包含下列資訊： 6.2.1 協定框架及協商機制之描述 6.
22、2.2 實作應支援個體鑑別之描述 (1) 用來鑑別之個體的識別 (2) 用來鑑別個體之機制 (3) 支援稽核紀錄之特別注意事項 6.2.3 實作應支援加密機制之描述 (1) 配送交談金鑰之方法 (2) 加密協定及相關參數 6.2.4 實作應支援完整性核對機制之描述 安全傳送連結剖繪，規範於附錄 B 中。 6.3 數位簽章剖繪 可宣稱對一或多個數位簽章剖繪符合性之實作。 數位簽章剖繪包含下列資訊： 6.3.1 數位簽章所扮演之角色，包括： (1) 數位簽章表示之個人或個體。 (2) 數位簽章目的之描述。 (3) 數位簽章被包含在資料集內之條件。 6.3.2 應被包含於數位簽章內之屬性的表列。 6
23、.3.3 產生或驗證數位簽章應使用之機制，包括： (1) 應被用來產生訊息鑑別碼 (MAC)或雜湊碼使用之演算法及相關參數，包括用於 MAC 演算法 (0400,0015)屬性之值。 (2) 應被用來對 MAC 或雜湊碼加密，以產生於數位簽章使用之加密演算法及相關參數。 (3) 使用之憑證型式或金鑰配送機制，包括用於憑證型式 (0400,0110)屬性之值。 (4) 任何已驗證時戳型式 (0400,0305)及已驗證時戳 (0400,0310)屬性之要求。 7 CNS 14176-15, X 6022-15 6.3.4 為能識別簽署人之任何特別要求。 6.3.5 與其他數位簽章之關係 (若有此
24、關係 )。 6.3.6 需用來產生、驗證或詮釋數位簽章之任何其他因素。 數位簽章剖繪，規範於附錄 C 中。 6.4 媒體儲存安全剖繪 可宣稱對一或多個媒體儲存應用剖 繪符合性之實作，而此媒體儲存應用剖繪須對一或多個媒體儲存安全剖繪之符合性。 備考： 實作若未對媒體儲存應用剖繪宣稱符合性，則不能宣稱對媒體儲存安全剖繪之符合性。 媒體儲存安全剖繪，包含下列規定： 6.4.1 剖繪所定位之安全觀點。 6.4.2 對被安全保存之 DICOM 檔案型式的限制 (若有此情形 )。 6.4.3 如何囊封及安全保存 DICOM 檔案。 媒體儲存安全剖繪，規範於附錄 D 中。 相對應國際標準： NEMA PS3
25、.15-2004 Digital imaging and communications in medicine (DICOM) Part 15: Security profile 8 CNS 14176-15, X 6022-15 附錄 A 安全使用剖繪 (規定 ) A.1. 線上電子儲存安全使用剖繪 此線上電子儲存安全使用剖繪允許應用個體追蹤及驗證 SOP 實例之狀態，以合乎安全政策需要追蹤原始資料集及後續副本。 符合性聲明應指出系統限制遠端存取之方法。 A.1.1 SOP 實例狀態 符合線上電子儲存安全使用剖繪之實作，應符合關於使用 SOP 實例狀態(0100,0410)屬性之規則，該 S
26、OP 實例係使用儲存服務類別來傳送： A.1.1.1 支援線上電子儲存安全使用剖繪之應用個體要在線上儲存其產生的診斷用 SOP 實例時，此應用個體應： A.1.1.1.1 設定 SOP 實例狀態為原版 (OR)。 A.1.1.1.2 包含下列屬性： (1) SOP 類別 UID(0008,0016)及 SOP 實例 UID(0008,0018) (2) 實例產生日期 (0008,0012)及實例產生時間 (0008,0013)(若已知 ) (3) SOP 實例狀態 (4) SOP 授權日期及時間 (0100,0420) (5) SOP 授權備註 (0100,0424)(若有 ) (6) SOP
27、 設備憑證號碼 (0100,0426) (7) 檢查實例 UID(0020,000D)及系列實例 UID(0020,000E) (8) 任何已知之通用設備模組的屬性 (9) 任何呈現之覆蓋資料 (10) 任何呈現之影像資料 A.1.1.2 擁有 SOP 實例之應用個體，其 SOP 實例狀態為原版 (OR)的，一旦遵循下列規則可將 SOP 實例狀態改變成授權原版 (AO)： A.1.1.2.1 應用個體應決定 SOP 實例已由一被授權的個體驗證可使用於診斷之目的上。 A.1.1.2.2 應用個體應改變 SOP 實例狀態為授權原版 (AO)。但 SOP 實例UID，則不應被改變。 A.1.1.2.
28、3 應用個體應置 SOP 授權日期和時間 (0100,0420)及授權設備憑證號碼 (0100,0426)屬性適當之值，亦可增加一適當之 SOP 授權備註 (0100,0424)屬性。 A.1.1.3 應僅有一應用個體持有一 SOP 實例狀態為原版 (OR)或授權原版 (AO)之 SOP 實例。擁有此一 SOP 實例之應用個體不應將其刪除。 A.1.1.4 當與支援線上電子儲存之個體通信時，擁有 SOP 實例狀態為原版 (OR)或是授權原版 (AO)之 SOP 實例的應用個體，可遵循下列規則將其 SOP實例傳送至另一符合線上電子儲存安全使用剖繪之應用個體上： 9 CNS 14176-15, X
29、 6022-15 A.1.1.4.1 傳送應在安全傳送連結上發生。 A.1.1.4.2 涉及傳送之兩個應用個體應相互驗 證且應經由鑑別來確認對方支援之線上電子儲存安全使用剖繪。 A.1.1.4.3 若傳送後之資料完整性驗證指出 SOP 實例在傳送的過程中被改變，則接收端之應用個體應拒絕該儲存請求並丟棄所收到的 SOP實例。 A.1.1.4.4 傳送應使用推壓模式之儲存確認服務類別以確認傳輸成功。直到完成此確認，接收端之應用個體不應把 SOP 實例或 SOP 實例的授權複本 (AC）遞送給任何其他應用個體。 A.1.1.4.5 一旦確認接收端之應用個體已確認 SOP 實例儲存成功，發送端之應用個
30、體應對本身 SOP 實例複本作下列事項之一： (1) 刪除 SOP 實例， (2) 改變 SOP 實例狀態為未指定 (NS: Not specified)， (3) 若 SOP 實例狀態為授權原版 (AO)，則改變其 SOP 實例狀態為授權複本 (AC)。 A.1.1.5 當與支援線上電子儲存之應用個體通信時，其擁有之 SOP 實例狀態為授權原版 (AO)或授權複本 (AC)之 SOP 實例的應用個體可遵循下列法則發送一 SOP 實例之授權複本至另一應用個體： A.1.1.5.1 傳送應發生在安全傳送連結上。 A.1.1.5.2 涉及傳送之兩應用個體間應互相鑑別，且應經由鑑別確認對方支援線上電
31、子儲存安全使用剖繪。 A.1.1.5.3 發送端之應用個體應設定複本發送之 SOP 實例狀態為未指定 (NS)或授權複本 (AC)，且 SOP 實例 UID 不應被改變。 A.1.1.5.4 若轉送後之資料完整性核對指出：其 SOP 實例在傳送過程中被改變，則接收端之應用個體應拒絕該儲存請求並丟棄複本。 A.1.1.6 若與一不支援線上電子儲存安全使用剖繪之系統通信時，或若未經由安全傳送連結進行通信時，則 A.1.1.6.1 符合此安全剖繪之發送端應用個體 經由不安全連結傳送資料或傳送資料至不支援線上電子儲存安 全使用剖繪系統，所傳送之SOP 實例應設定 SOP 實例狀態為未指定 (NS)或忽
32、略任何 SOP 實例狀態相關參數。 A.1.1.6.2 符合此安全剖繪之接收端的應用個 體應對經由不安全傳送連結或是從不支援線上電子儲存安全使用剖繪系統所接收之 SOP 實例的 SOP 實例狀態設定為未指定 (NS)。 A.1.1.7 接收端應用個體應根據儲存服務類別的層級 2 之要求 (亦即，所有屬性包括專用屬性 )來儲存 SOP 實例，如同儲存確認服務類別所要求。且也不應更改除了 SOP 實例狀態、 SOP 授權日期和時間、授權設備憑證號碼和 SOP 授權備註外之其他屬性。 10 CNS 14176-15, X 6022-15 A.1.1.8 除依據上述要求改變 SOP 實例狀態、 SOP
33、 授權日期和時間、授權設備憑證號碼及 SOP 授權備註等屬性，或改變群組長度屬性外，應用個體不應改變任何屬性值。 A.2 基本數位簽章安全使用剖繪 可驗證及產生數位簽章 之實作可宣稱對基本數位簽章安全使用剖繪之符合性。任何對此安全剖繪宣稱符合性之實作在處理數位簽章時，應遵守下列規則： A.2.1 實作應儲存任何接收到之 SOP 實例，並防範任何未經授權之 SOP 實例的竄改。 A.2.2 只要可能，實作應驗證其所接收到之 SOP 實例內的數位簽章。 A.2.3 若實作發送 SOP 實例至另一應用個體時，它應做下列事項： A.2.3.1 移除任何因對屬性值之格式所作的改變而可能已成無效之數位簽章
34、(例如，填充數之整理，數之替代表示法 ) A.2.3.2 產生一或多個新數位簽章，簽章內涵蓋之資料元件在 SOP 實例被接收時，可被接收端之實作來驗證。 A.3 位元保存之數位簽章使用剖繪 可儲存及遞送 SOP 實例之實作可以宣稱對位元保存數位簽章使用剖繪之符合性。任何對此安全剖繪宣稱符合性之實作在處理數位簽章時應遵守下列規則： A.3.1 實作應儲存任何接收到之 SOP 實例，當 SOP 實例被遞送到另一 個應用個體時，所有屬性之值欄位會以位元對位元方式複製原始所接收之資料。 A.3.2 實作不應改變在一序列中之項目次序。 A.3.3 當經由 DICOM 發送 SOP 實例至另一應用個體時，
35、實作不應移除或是改變任何接收到之 SOP 實例的任何資料元件。這也包含任何所接收到之數位簽章。 備考：實作可增加新資料元件而不改變已存在的數位簽章。 A.3.4 實作應利用外顯 VR 傳送語法。 備考： 不能使用外顯 VR 傳送語法之實作，就不能符合此安全使用剖繪，因其可能無法驗證以內隱 VR 傳送語法所傳來的資料之數位簽章。 A.3.5 當傳輸物件至另一應用個體時，實作不應改變任何所接收到之資料元件的 VR。 11 CNS 14176-15, X 6022-15 附錄 B 安全傳送連結剖繪 (規定 ) B.1 基本 TLS 安全傳送連結剖繪 支援基本 TLS 安全傳送連結剖繪之實作應使用第
36、1.0 版本之傳送層安全協定所規範的框架及協商機制。若應用個體支援 TLS 時，表 B.1-1 規範其所應支援特徵之機制。此剖繪不需要求實作去支援所有 TLS 之特徵 (個體鑑別、加密及完整性核對 )。但若在建立 TLS 通道期間經由協商同意，則這些機制也可被支援使用。 表 B.1-1 TLS 特徵之最低限度的機制 被支援之 TLS特徵 最低限度之機制 個體鑑別 以 RSA為基礎之憑證 交換主要之秘密 RSA 資料完整性 SHA私密性 三重 -DES、 EDE、 CBC 在實作中接受 TLS 連結之 IP 埠號及此埠號被選擇或設定之機制，應規範在符合性聲明中。此埠號應與使用在其他型式之傳送連結
37、 (安全或不安全 )之埠號，有所不同。 備考：強烈建議支援基本 TLS 安全傳送連結剖繪之系統使用已註冊之埠號 “2762 dicomtls“ (十進位 )，作為 DICOM TLS 傳輸之埠號。 符合性聲明也應指出實作所支援之金鑰管理機制。 此剖繪並未規範 TLS 安全傳送連結是如何被建立，亦未指明在個體間利用憑證做身份確認時，如何驗證 憑證之有效性。這些議題留給應用個體，應用個體被認為是遵照某些特定安全政 策。憑證使用者之識別可由應用個體用來支援稽核紀錄，或做為基於某些外部存 取權限控制框架之存取管控。一旦應用個體建立了安全傳送連結，則上層聯結就可以使用該安全通道。 備考： PDU 大小及
38、 TLS 紀錄大小間可能會交互作用，進而影響傳送之效率。最大可允許之 TLS 紀錄大小比最大可允許之 PDU 大小還小。 當完整性核對失敗，每一 TLS 協定之連結應被中斷，促使發送者及接收者對上層發出 A-P-ABORT 指示及提出特定之中斷理由。所使用的中斷理由會因實作而異，故其應被記載於符合性聲明中。 備考：完整性核對失敗代表通道之安全可能已被破解。 B.2 ISCL 安全傳送連結剖繪 支援 ISCL 傳送連結剖繪之實作應利用整合性安全通信層之第 1.00 版協定所規範之框架及協商機制。應用個體應使用 ISCL 並選擇規範於表 B.2-1 之機制。應用個體最低限度應使用個體鑑別機制及資料
39、完整性核對。應用個體可選用之私密性機制。 12 CNS 14176-15, X 6022-15 表 B.2-1 ISCL 特徵之最低限度的機制 支援之 ISCL特徵 最低限度之機制 個體鑑別 三回合 (四 -向 )鑑別 (ISO/IEC 9798-2) 資料完整性 MD-5以 DES或 DES-MAC加密 私密性 DES(參閱備考 ) 備考：對線上電子儲存，私密性可選用之 DES。 為了核對資料完整性，實作可在使用 MD-5 前對亂數加密，或對 MD-5 之輸出加密。此順序規範於協定中。不論順序為何，接收者應能對訊息作完整性之核對。 在實作中接受 ISCL 連結之 IP 埠號及此埠號被選擇或設
40、定之機制應被規範在符合性聲明中。此埠號應和使用在其他型式之傳送連結 (安全或不安全 )的埠號，有所不同。 備考： 強烈建議支援 ISCL 安全傳送連結剖繪之系 統使用已註冊之埠號 “2761 dicomiscl“ (十進位 )，作為 DICOM ISCL 傳輸之埠號。 符合性聲明也應指出實作所支援之金鑰管理的機制為何。 此剖繪並未規範 ISCL 安全傳送連結是如何被建立，這些議題留給應用個體，應用個體被認為是遵照某 些特定安全政策。一旦應用個體建立了安全傳送連結，則上層結合就可使用該安全通道。 備考： PDU 大小及 ISCL 紀錄大小間可能會交互作用，進而影響傳送之效率。 當完整性之核對失敗
41、，每一 ISCL 協定之連結應被中斷，使發送者及接收者對上層發出 A-P-ABORT 指示及提出特定之中斷理由。所使用之中斷理由會因實作而異，故其應被記載於符合性聲明中。 備考：完整性核對失敗代表通道之安全可能已被破解。 13 CNS 14176-15, X 6022-15 附錄 C 數位簽章剖繪 (規定 ) C.1 基本 RSA 數位簽章剖繪 基本 RSA數位簽章剖繪概要說明訊息鑑別碼 (MAC)之 RSA加密的使用以產生數位簽章。本剖繪並未規範 對任何特別之資料元件集做簽章。其他數位簽章剖繪可參考此剖繪，加入對何種資料元件做簽署或其他客製化之規格。 數位簽章之建立者應使用 RIPEMD-1
42、60、 MD-5 或 SHA-1 之其中一雜湊函數來產生一訊息鑑別碼 (MAC)，該訊息鑑別碼接著以 RSA 私鑰來加密。所有使數位簽章驗證者應有能力使 用這些雜湊函數 (RIPEMD-160， MD5 或 SHA-1)產生訊息鑑別碼，以驗證電子簽章。 備考： RSA 之發明者並不推薦使用 MD-5，詳參： ftp:/ 欲被簽章之訊息鑑別碼 (MAC)應被填充為符合 RSA 鑰匙長度之區塊大小，如同RFC2437(PKCS#1)所示。 MAC 演算法 (0400， 0015) 之值應被設為 “RIPEMD- 160“、 “MD5“或 “SHA1“。驗章公鑰，以及擁有此 RSA 鑰匙對的應用個體
43、或設備製造商之身分識別資料應包含在 X.509(1993)簽章憑證下 傳輸交換。憑證型式 (0400， 0110) 之屬性值應設為 “X509_1993_SIG“。一特定之政策決定 X.509 憑證如何被產生、被鑑別及被配送。單位可直接發出及配送 X.509 憑證、可利用憑證驗證單位之服務、或使用任何合理之方法作憑證之產生及驗證。 若實作利用時戳，則應使用 “CMS_TSP”之已驗證時戳型式 (0400,0305)。已驗證時戳 (0400,0310) 應依據 “Internet X.509 public key Infrastructure; time stamp protocols; Mar
44、ch 2000“之規範來產生。 C.2 建立者 RSA 數位簽章剖繪 DICOM SOP 實例之建立者可使用建立者 RSA 數位簽章剖繪來產生數位簽章。由此剖繪所產生之數位簽 章，可作為資料存活時間之完整性核對，此簽章可用來驗證在該 SOP 實例中之像素資料，自其被產生以來，就不曾被改變過。支援建立者RSA 數位簽章剖繪之實作對其產生之每一 SOP 實例都可包含一建立者 RSA 數位簽章；然而，實作並未被要求如此做。 實作在產生其建立者 RSA 數位簽章時，其最少應包含下列屬性： (1) SOP 類別及實例 UID (2) SOP 產生日期及時間 (若表示 ) (3) 檢查及系列實例 UID
45、(4) 存在之一般設備模組的任何屬性 (5) 存在之覆蓋平面、曲線或圖形註解模組的任何屬性 (6) 存在之一般影像及影像像素模組的任何屬性 (7) 存在之 SR 文件概要及 SR 文件內容模組的任何屬性 (8) 存在之波形及波形註解模組的任何屬性 14 CNS 14176-15, X 6022-15 數位簽章應使用基本 RSA 數位簽章剖繪所描述之方法來產生。被用來產生建立者RSA 數位簽章之憑證及結合私鑰是應用個體的結構參數，這些參數是由服務或裝設工程師所設定的。 建立者 RSA 數位簽章與其他數位簽章沒有直接關係。然而，其他數位簽章如授權數位簽章就可被用來協作建立者 RSA 數位簽章之時戳
46、。 C.3 授權 RSA 數位簽章剖繪 認可 DICOM SOP 實例之技術人員或醫生，也許會要求應用個體使用授權 RSA 數位簽章剖繪來產生簽章。所產生之數位簽章作為生命期的資料完整性核對可用來驗證在該 SOP 實例中之像素資料及當技術人員或醫生作出認可時，所見是相同的。 實作在產生授權 RSA 數位簽章時，至少應包含下列屬性： (1) SOP 類別及實例 UID (2) 檢查及系列實例 UID (3) 可由技術人員或醫生驗證之任何屬性的值 (例如：這些值可顯示給技師或醫生 ) (4) 存在之覆蓋平面、曲線或圖形註解模組的任何屬性 (5) 存在之一般影像及影像像素模組的任何屬性 (6) 存在
47、之 SR 文件通則及 SR 文件內容模組的任何屬性 (7) 存在之波形及波形註解模組的任何屬性 數位簽章應使用基本 RSA 數位簽章剖繪中所描述之方法來產生。應用個體應決定技術人員或醫生之身分及透過一特定程序，如登入機制或智慧卡來獲得其憑證。 授權 RSA 數位簽章與其他數位簽章並無直接關係。然而，其他數位簽章如建立者RSA 數位簽章就可能被用來協作授權 RSA 數位簽章之時戳。 15 CNS 14176-15, X 6022-15 附錄 D 媒體儲存安全剖繪 (規定 ) D.1 基本 DICOM 媒體安全剖繪 基本 DICOM 媒體安全剖繪允許一 DICOM 檔案囊封至一安全的 DICOM
48、檔案當中，因此下列之安全觀點被提出： 機密性 完整性 資料起源鑑別 (選擇性 ) 此剖繪規範了使用三重 -DES 對內容加密，及 RSA 對三重 -DES 內容加密金鑰之金鑰傳送。此被加密之內容是一 DICOM 檔案，這個檔案可以是 能被一或多個數位簽章作簽署，使用 SHA-1 作為摘要演算法及以 RSA 作為作簽章演算法，或 能以 SHA-1 作為摘要演算法來作摘錄，而沒有數位簽章之應用。 D.1.1 DICOM 檔案在安全 DICOM 檔案內之囊封 符合本安全剖繪之安全 DICOM 檔案應包含定義在 RFC2630 之密碼訊息語法的封裝資料 型式中。被封裝之資料應使用 RSARFC2313
49、作為三重 -DES內容加密金鑰之金鑰傳送。三重 -DES 金鑰之長度為由 ANSI X.952 所定義之 168 位元。編碼應根據 RFC 2630 所規範之 RSA 金鑰傳送來執行。 封裝資料內容型式中被加密之內容，應根據下列來選擇： 已簽屬之資料內容型式 已摘錄之資料內容型式 在上述兩種情形中， SHA-1SHA-1應被當作摘要演算法來使用。在已簽署資料之內容型式中， RSARFC 2313應被當作簽章演算法來使用。 備考 1. 三重 -DES 內容加密金鑰之 RSA 金鑰傳送在 European prestandard ENV 13608-2: Health informatics security for healthcare communication Part 2: Secure data objects 中被規範為是必須的。 2. 本剖繪並未定義 RSA 金鑰傳送所使用之非對稱金鑰對大小之需求。 3. 本剖繪未定義對使用已 簽署之資料內容型式的簽署者資訊結構中的簽署屬性元件需求或限制。簽署屬
