DICOM30标准中文版15

1、参考版本2001翻译者：Myth联系地址：yyyyinsheng一应用的领域和范围本章详细说明了应用程序可能应该遵守的安全规则。尽管应该定义所有级别的安全规则，但是DICOM标准并没有在任何其他的地方列出或者讨论有关安全政策方面的问题。而仅仅提供了用在两个通信的应用程序之间交换信息时应遵守的安全规则。例如，一条安全规则应该规定某个级别的访问控制规则。DICOM标准不研究访问控制时的安全规则，只提供适当的技术手段，让两个应用程序通过交换足够多的信息来实现安全。DICOM标准假定通信中的应用程序应该实现（但不仅仅局限于）下面的安全规则，如财务追踪、物理的保护、数据的保密和完整性和用户管理。最重要的

2、是，在与其他应用程序通信前，必须要保证自身所处的环境是安全的。若两个应用程序通过DICOM协议连接上，它们实际上同意了并接收了对方实体的安全级别。这时，主应用程序信任对方在他们的控制下能够保持它们数据的保密和完整性。当然这种级别上的信任也可由本地的设置得到。应用程序可能并不相信其所处的通信线路是完全安全的。在通信的过程中，信息有可能被篡改，也有可能被截获用于不法用途，基于这种情况，DICOM标准规定通信双方需要安全认证。应用程序可以根据现实情况（网络范围），有选择的使用何种级别的认证。DICOM标准假定，应用程序应该确保本地用户是合法的。用户可以是人或者抽象实体（组织或仪器）。通信时，应用程序

3、可以传递用户的信息以便对方可以验证自己的身份。对方可以依据传送过来的用户信息决定此用户的使用权限，并且记录相关的财务信息。DICOM标准假定信息的持有者（病人或组织机构）已经授权给应用程序的用户进行通信，但不关心他们之间是如何进行授权的。DICOM 标准假定应用程序使用TLS（Transport Layer Security）进行安全访问或者是能够安全的获得X.509用户认证证书。另外，他也假定应用程序能够解读X.509证书。解读可以通过本地设置、公开的有用的认证或者是可信任的第三方。DICOM 标准假定使用ISCL（Integrated Secure Communication Layer）

4、的应用程序有权使用适当的密匙管理和分配系统（如IC卡）。标准中不介绍有关这方面的情况。二参考资料三定义3.1参考模型a. 应用程序b. 协议数据单元（PDU）或 链路协议数据单元（Layer Protocol Data Unit）c. 传输连接3.2 安全体系结构模型a. 数据保密性注：非法用户或程序不能访问信息。b. 数据来源认证注：对数据源进行确认。c. 数据完整性注：在没有授权的情况下不允许更改或删除数据。d. 密匙管理注：创建、存储、分配、删除、保存和应用密匙的一套安全规则。e. 数字签名注：通过传递加密的数据来保证数据源的完整性和安全性，防止伪造。3.3 ACSE服务a. 连接或应用

5、连接3.4 安全性a. 内容注：它表现为一种安全信息，这信息是用来与一个已经存在或即将存在的启动程序或接受程序进行安全连接的。3.5 DICOM介绍和概况（PS 3.1）a. 属性3.6 DICOM 的一致性（PS 3.2）a. 安全框架3.7 DICOM IOD（PS 3.3）a. 模块3.8 DICOM 服务类（PS 3.4）a. 服务类b. (SOP) 实例3.9 DICOM通信（PS 3.8）a. DICOM 上层3.10 DICOM 安全框架本章使用的术语，安全的传输连接：要求在某个级别上保护信息不被篡改、窃听和伪造。消息识别码：从信息中产生的摘要码或无序码。证书：电子文档，用以识别

6、某个部分和其公共的加密算法，参数和密匙。证书中存放了创建者的数字签名。证书的内容和格式由 ITU-T Recommendation X.509 定义。五约定六安全规则概要应用程序可能支持一个或多个安全规则。它必须要在说明书中写明支持何种安全规则。6.1 安全使用规则应用程序可以任意使用安全规则。规则描述了其使用方法和与之相关的规则，详细说明见附件A。6.2 安全传输和连接规则应用程序可以任意使用安全传输和连接的规则。它包含了下面这些方面：a. 协议的框架和协商的机制。b.如何认证1. 确认的ID 2. 如何确认3. 财务记录c. 如何加密1. 如何分发密匙2. 加密协议和相关参数d. 数据完整

7、性检查详见附件B6.3 数字签名支持多种数字签名的方式数字签名包含以下信息：a. 签名者的角色1. 谁或者是什么实体2. 描述签名的用途3. 数据集拥有数字签名的条件 b. 签名属性列表c. 产生和验证签名的机制，它包括：1. 创建MAC或无序码的算法和相关参数，（0400，0015）2. 加密的算法和参数3. 证书类型或发布机制，（0400，0110）4. （0400，305）签署时间类型和（0400，310）签署时间d. 如何识别签名者e. 与其他数字签名的关系f. 其他用于创建、校验和解释签名的因数见附件C6.4 媒质存储安全应用程序可以支持一个或多个存储规则，这些规则可以是相互嵌套的。

8、注：不能支持不存在的存储规则。存储安全包含以下几个方面：a. 所涉及的方面b. 是否对可以被确保安全的DICOM文件的类型有所限制；如有限制，具体的限制范围如何。c. 如何压缩DICOM文件并保证文件安全。见附件D附件A安全规则A.1 在线电子存储的安全如果本地设置需要对数据来源和它的拷贝进行跟踪的话，那么应用程序就要跟踪和校验SOP实例的状态。说明书会写明系统对远端访问的限制。A.1.1 SOP实例的状态应用程序如果遵守“在线电子存储安全规则”，那么就要满足以下关于在使用存储服务时如何使用SOP实例状态的若干规定：a. 应用程序（用于诊断目的并且遵守“在线电子存储安全规则”和SOP实例创建者

9、）应该：1 SOP实例状态设置为原始状态（OR）。2 包含如下属性：a) SOP Class UID (0008,0016) 和 SOP Instance UID (0008,0018)b) 实例创建日期 (0008,0012) 和 实例创建时间 (0008,0013) c) SOP实例状态d) SOP 认证日期和时间 (0100,0420)e) SOP 认证注释 (0100,0424)f) SOP 设备标识码 (0100,0426)g) Study Instance UID (0020,000D) 和 Series Instance UID (0020,000E)h) 设备模块的其他属性i)

10、 现有覆盖图j) 现有影像b. 从“原始态”（OR）到“授权的原始态”（AO）需要满足：1.应用程序应该确定某个已授权实体是否已经鉴定了SOP实例的医用性。2.实例状态变为AO，同时SOP实例UID保持不变。3.应用程序要设置SOP认证时间和日期（0100，0420）和授权设备标识号（0100，0426）。如果需要也可以加上注释（0100，0424）。c.只允许一个应用程序保留SOP实例（当它的状态为OR或AO时），而且不能删除。d.当与其它应用程序（也支持在线存储）通信时，如果满足以下条件，就可以将自身拥有的SOP实例（OR或OA状态）传送给另一端的通信程序：1.保证传输的安全2.相互已经认

11、证，并且使用一致的在线存储规则。3.传送后，如果完整性检查不通过，接受方应能够拒绝对方的存储请求。4.传输时的认证使用存储确认服务类的推进模式，在认证结束前，接受方不能再把此SOP实例发往其他任何地方。5. 一旦发送方把SOP实例传送到目的地，那么就要选择下面其中一种方法来处理本地的SOP实例：a) 删除SOP实例b) 改变SOP实例状态为“不指定”（NS）c) 如果SOP实例的状态为AO，那么要变为“原始拷贝”（AC）。e.通信时，如果满足下面的条件，主叫方（SOP实例状态为AO或AC）发送AC状态的SOP实例到接受方：1. 保证传输的安全2. 相互已经认证，并且使用一致的在线存储规则。3.

12、 发送方把SOP实例的状态改为NS或AC作为拷贝发送。SOP实例UID不变。4. 传送后，如果完整性检查不通过，接受方应能够拒绝对方的存储请求。f. 如果有一方不支持在线电子存储规则或者当通信不是在安全传输连接下进行的，那么：1.发送方（支持在线电子存储规则）有可能把SOP实例的状态设为NS或者不改变原来的状态和相关的参数。2.接受方（支持在线电子存储规则）把任何接到的SOP实例状态设为NS。g.接受方在保存SOP实例时，要按照存储服务类第二级的规定，保持实例的属性的原样，包括私有属性。除了SOP实例状态、SOP授权日期和时间、授权设备证书号码以及SOP授权评注以外，不能再强制要求提供其他的属

13、性。h.接受方可以改变SOP实例状态、SOP授权日期和时间、授权设备证书号码以及SOP授权评注这些属性，还包括由于属性变化而变化的段的长度。但不能改变其他的任何属性值。A.2数字签名的基本安全规则任何应用程序应当符合数字签名的基本安全规则，并且在处理数字签名时须遵循以下规则：a.以适当的方式保存SOP实例，拒绝未授权的非法SOP实例。b.必须验证所有SOP实例的数字签名。c.发送SOP实例到别的应用程序时，要：1.移除所有无效的数字签名，无效的原因是属性值的格式发生了变化（如去掉左右空格、号码格式的改变）。2.生成多个新的数字签名用于SOP实例被接收时的验证。A.3 BIT-PRESERVIN

14、G数字签名的基本安全规则声明支持此种数字签名的应用程序要满足下面的若干规定：a.接受时，不改变SOP实例中的任何属性值，原封不动的发给其他的应用程序。b.不改变队列中每个属性的排列顺序。c.不能删除和修改任何属性值，包括所有的数字签名。d.使用显式的传输语法。注：不支持显式的传输语法的应用程序不能使用这种安全规则，因为隐式的传输语法下不能验证数字签名。e.不改变属性值的类型。附件B 安全传输连接安全规则B.1基本TLS安全传输连接一个支持基本TLS安全传输连接规则的应用程序须利用由传输层安全（TLS）1.0版协议规定的框架和协议机制。表B.1-1具体描述了TLS以内的相应的特征受到应用实体的支

15、持的情况下必须受支持的各种机制。本规则并不要求应用程序支持TLS的所有的特征（实体鉴定、编密码、检查完整性）。如果在TLS信道建立的时候协议同意的话，其他的机制也可以受支持。表 B.1-1 最低限度的TLS特征的机制一个应用程序是在IP端口上接受TLS连接的，或者说，这个端口号码就是由这个机制所选择或设定的；无论是IP端口，或这种机制都须在一致声明中明确说明。这个端口必须不同于用于其他类型的传输连接（安全或非安全的）的端口。注：建议支持基本TLS安全传输连接规则的系统给位于TLS:(十进制)上的DICOM上层服务协议使用注册的端口号“2762 dicomtls”作为它们的端口。一致声明还须指出

16、应用程序使用何种机制来管理密匙。规则自己不需说明TLS安全传输连接是如何建立的，也不需说明在对等的实体鉴别期间所交换的任何证书的具体意义。这类问题留给应用实体来解决；一般说来应用实体是要遵循某些现场确定的安全政策的。应用实体可以利用证书拥有者的身份支持跟踪记录，或者用某些外部访问规则来限制。一旦应用实体建立了一个安全传输连接，上层联络就可以使用该安全信道了。注：在PDU大小和影响传输效率的TLS记录大小之间，可能会出现一种交互作用。TLS记录的最大许可容量小于PDU最大许可容量。当完整性检查失败的时候，许根据TLS协议断开连接，这样就会导致发送方和接受方两个方面都向上层发送指令，按照应用程序的

17、特定要求说明提供方原因。有关所用到的提供方原因这一内容，须在一致声明中明文阐述。注：如果完整性检查失败，则说明信道的安全性已经有可能受损。B.2ISCL安全传输连接规则一个支持ISCL传输连接规则的功能模组须利用综合安全通讯层V1.0所规定的框架结构和协议机制。一个应用实体须使用ISCL来选择表B.2-1中具体说明的机制。一个应用实体在最低限度上须使用一个实体鉴别机制以及数据完整性检验。一个应用实体可以选择性地使用一个机密/不收干扰的机制。表 B.2-1 ISCL特征的机制之最低限度注：在线电子存储可以选择DES用作保护隐私。对于数据完整性的检查而言，应用程序既可以加密在应用MD-5之前的随机

18、号码，也可以加密MD-5的结果；关于其顺序请见协议中的详细说明。接受方须能够在不受序的影响的情况下执行对消息的完整性的检查。一个应用程序是在IP端口上接受ISCL连接的，或者说，这个端口号码就是由这个机制所选择或配置/设定的；无论是IP端口，或这种机制都须在一致声明中明确说明。这个端口必须不同于用于其他类型的传输连接（安全或非安全的）的端口。注：建议支持基本ISCL安全传输连接规则的系统给位于ISCL上的DICOM上层服务协议使用注册的端口号“2761 dicomiscl”作为它们的端口。一致声明还须指出管理密匙的机制。规则自己不需说明TLS安全传输连接是如何建立的。这个问题留给应用实体来解决

19、；一般说来应用实体是要遵循某些现场确定的安全政策的。一旦应用实体建立了一个安全传输连接，上层联络就可以使用该安全信道了。注：在PDU大小和影响传输效率的ISCL记录大小之间，可能会出现一种交互作用。当完整性检查失败的时候，许根据TLS协议断开连接，这样就会导致发送方和接受方两个方面都向上层发送指令，按照功能模组的特定要求说明提供方原因。有关所用到的提供方原因（出自提供方的原因）这一内容，须在一致声明中明文阐述。注：如果完整性检查失败，则说明信道的安全性已经有可能受损。附件C 数字签名C.1基本RSA数字签名规则基本RSA数字签名规则概述了利用一个MAC的RSA编码法来生成一个数字签名的方法。本

20、配置文件不对需要签署的数据元素的特定集合做确切规定。其他的数字签名规则可能会参考到本规则，可能会添加上一些有关该签署哪些数据元素的详细说明或者其他的定制。数字签名的创建者须使用RIPEMD-160，MD5，或SHA-1之散列法功能之一来生成一个MAC；随后，用一个秘密的RSA密匙就可以把这个MAC加密。所有的数字签名须验证生效，这一过程必须通过利用由三个散列法功能（RIPEMD-160，MD5或SHA-1对这三个功能做了具体规定）之任意一个所生成的MAC来完成。注：关于是否使用MD5，其发明者，RSA，并没有推荐。见：ftp:/将被标记的MAC须被填补到与RSA密匙区匹配的一个字区上（须被填补

21、到映射RSA密匙区的一个字区上），具体方法见RFC 2437 (PKCS #1)。MAC运算法则的值须被设定为“RIPEMD160”，“MD5”或“SHA1”。与应用实体的身份或拥有/承认RAS密匙配对的设备生产商、以及个人/私人/自定的密匙相关的公共密匙须在一个X.509 (1993)签名证书中传输/发射。证书类型(0400,0110)属性的值须被设定为“X509_1993_SIG”。为特定区域所创建的政策（现场制定的政策）可以确定X.509证书是如何生成、鉴别以及分布的。一个场所/地址可以直接发送并分配X.509证书，可以使用证书授权服务，或使用证书生成和确认的相应方法。如果利用时间标记，

22、则必须使用“CMS_TSP”被鉴定的时间标记类型(0400,0305)。根据“Internet X.509 Public Key Infrastructure; Time Stamp Protocols; March 2000（因特网X.509公共密匙下部结构；时间标记协议；2002三月）的说明，必须生成被鉴定的时间标记(0400,0310)。C.2 创建者RSA数字签名规则DICOM SOP实例的创建者可以利用创建者RSA数字签名规则来生成签名。由本规则所产生的数字签名可用作永久性的数据完整性检查标记；该标记可用以查证SOP实例中的像素数据自从最初创建以来是否被更改过。支持创建者RSA数字签

23、名规则的一个应用程序可以随同它所创建每一个SOP实例一起包含一个创建者RSA数字签名；然而，并不是非被要求这样作不可。一个功能模组在生成创建者RSA数字签名时须在最低限度上包含以下属性：a. SOP类和实例UIDsb. SOP创建日期和时间（如果存在的话）c. 检查和系列实例UIDsd. 所出现的综合设备模块的任何属性e. 所出现的覆盖平面、曲线或图解说明/注释模块的任何属性f. 所出现的综合影像和影像像素模块的任何属性g. 所出现的SR文件概要和SR文件内容模块的任何属性h. 所出现的波形和波形说明/注解模块的任何属性创建数字签名时须用到基本RSA数字签名规则中说明的方法。很具有明显特征的一

24、点就是，用来生成创建者RSA数字签名的证书以及相关联的密匙都是有服务或安装工程师设定的应用实体的配置参数。创建者RSA数字签名与其他的数字签名没有直接关系。然而，其他的数字签名，如授权数字签名，可被用来与一个创建者RSA数字签名的时间标记相互协作。C.3授权RSA数字签名规则如果技术人人员或医师认为可以使用某个DICOM SOP实例，他可能会利用授权RSA数字签名规则来请求应用实体生成一个签名。所生成的数字签名可被用作永久性的数据完整性检查标记；该标记可用以查证SOP实例中的像素数据与技术人员或医师核准时所看到的一样。一个功能模组在生成授权RSA数字签名时须在最低限度上包含以下属性：a.SOP类和实例UIDsb. 检查和系列实例UIDsc.技术人员或医师可以证实其值的所有属性（即，它们的值显示给技术人员或医师）d.所出现的覆盖平面、曲线或图解说明/注释模块的任何属性e. 所出现的综合影像和影像像素模块的任何属性f. 所出现的SR文件概要和SR文件内容模块的任何属性g.所出现的波形图的属性创建数字签名时须用到基本RSA数字签名规则中说明的方法。应用实体须确定技术人员或医师的身份并通过注册/登录机制或智能卡之类的与场合有关的程序获得它们的证书。授权RSA数字签名与其他的数字签名没有直接关系。然而，其他的数字签名，如创建者RSA数字签名，可被用来与