DICOM协议第十五章.docx
《DICOM协议第十五章.docx》由会员分享，可在线阅读，更多相关《DICOM协议第十五章.docx（11页珍藏版）》请在冰豆网上搜索。
DICOM协议第十五章
参考版本2001
翻译者：
Myth
联系地址：
yyyyinsheng@
一应用的领域和范围
本章详细说明了应用程序可能应该遵守的安全规则。
尽管应该定义所有级别的安全规则，但是DICOM标准并没有在任何其他的地方列出或者讨论有关安全政策方面的问题。
而仅仅提供了用在两个通信的应用程序之间交换信息时应遵守的安全规则。
例如，一条安全规则应该规定某个级别的访问控制规则。
DICOM标准不研究访问控制时的安全规则，只提供适当的技术手段，让两个应用程序通过交换足够多的信息来实现安全。
DICOM标准假定通信中的应用程序应该实现（但不仅仅局限于）下面的安全规则，如财务追踪、物理的保护、数据的保密和完整性和用户管理。
最重要的是，在与其他应用程序通信前，必须要保证自身所处的环境是安全的。
若两个应用程序通过DICOM协议连接上，它们实际上同意了并接收了对方实体的安全级别。
这时，主应用程序信任对方在他们的控制下能够保持它们数据的保密和完整性。
当然这种级别上的信任也可由本地的设置得到。
应用程序可能并不相信其所处的通信线路是完全安全的。
在通信的过程中，信息有可能被篡改，也有可能被截获用于不法用途，基于这种情况，DICOM标准规定通信双方需要安全认证。
应用程序可以根据现实情况（网络范围），有选择的使用何种级别的认证。
DICOM标准假定，应用程序应该确保本地用户是合法的。
用户可以是人或者抽象实体（组织或仪器）。
通信时，应用程序可以传递用户的信息以便对方可以验证自己的身份。
对方可以依据传送过来的用户信息决定此用户的使用权限，并且记录相关的财务信息。
DICOM标准假定信息的持有者（病人或组织机构）已经授权给应用程序的用户进行通信，但不关心他们之间是如何进行授权的。
DICOM标准假定应用程序使用TLS（TransportLayerSecurity）进行安全访问或者是能够安全的获得X.509用户认证证书。
另外，他也假定应用程序能够解读X.509证书。
解读可以通过本地设置、公开的有用的认证或者是可信任的第三方。
DICOM标准假定使用ISCL（IntegratedSecureCommunicationLayer）的应用程序有权使用适当的密匙管理和分配系统（如IC卡）。
标准中不介绍有关这方面的情况。
二参考资料
三定义
3.1参考模型
a.应用程序
b.协议数据单元（PDU）或链路协议数据单元（LayerProtocolDataUnit）
c.传输连接
3.2安全体系结构模型
a.数据保密性
注：
非法用户或程序不能访问信息。
b.数据来源认证
注：
对数据源进行确认。
c.数据完整性
注：
在没有授权的情况下不允许更改或删除数据。
d.密匙管理
注：
创建、存储、分配、删除、保存和应用密匙的一套安全规则。
e.数字签名
注：
通过传递加密的数据来保证数据源的完整性和安全性，防止伪造。
3.3ACSE服务
a.连接或应用连接
3.4安全性
a.内容
注：
它表现为一种安全信息，这信息是用来与一个已经存在或即将存在的启动程序或接受程序进行安全连接的。
3.5DICOM介绍和概况（PS3.1）
a.属性
3.6DICOM的一致性（PS3.2）
a.安全框架
3.7DICOMIOD（PS3.3）
a.模块
3.8DICOM服务类（PS3.4）
a.服务类
b.（SOP）实例
3.9DICOM通信（PS3.8）
a.DICOM上层
3.10DICOM安全框架
本章使用的术语，
安全的传输连接：
要求在某个级别上保护信息不被篡改、窃听和伪造。
消息识别码：
从信息中产生的摘要码或无序码。
证书：
电子文档，用以识别某个部分和其公共的加密算法，参数和密匙。
证书中存放了创建者的数字签名。
证书的内容和格式由ITU-TRecommendationX.509定义。
五约定
六安全规则概要
应用程序可能支持一个或多个安全规则。
它必须要在说明书中写明支持何种安全规则。
6.1安全使用规则
应用程序可以任意使用安全规则。
规则描述了其使用方法和与之相关的规则，详细说明见附件A。
6.2安全传输和连接规则
应用程序可以任意使用安全传输和连接的规则。
它包含了下面这些方面：
a.协议的框架和协商的机制。
b.如何认证
1.确认的ID
2.如何确认
3.财务记录
c.如何加密
1.如何分发密匙
2.加密协议和相关参数
d.数据完整性检查
详见附件B
6.3数字签名
支持多种数字签名的方式
数字签名包含以下信息：
a.签名者的角色
1.谁或者是什么实体
2.描述签名的用途
3.数据集拥有数字签名的条件
b.签名属性列表
c.产生和验证签名的机制，它包括：
1.创建MAC或无序码的算法和相关参数，（0400，0015）
2.加密的算法和参数
3.证书类型或发布机制，（0400，0110）
4.（0400，305）签署时间类型和（0400，310）签署时间
d.如何识别签名者
e.与其他数字签名的关系
f.其他用于创建、校验和解释签名的因数
见附件C
6.4媒质存储安全
应用程序可以支持一个或多个存储规则，这些规则可以是相互嵌套的。
注：
不能支持不存在的存储规则。
存储安全包含以下几个方面：
a.所涉及的方面
b.是否对可以被确保安全的DICOM文件的类型有所限制；如有限制，具体的限制范围如何。
c.如何压缩DICOM文件并保证文件安全。
见附件D
附件A安全规则
A.1在线电子存储的安全
如果本地设置需要对数据来源和它的拷贝进行跟踪的话，那么应用程序就要跟踪和校验SOP实例的状态。
说明书会写明系统对远端访问的限制。
A.1.1SOP实例的状态
应用程序如果遵守“在线电子存储安全规则”，那么就要满足以下关于在使用存储服务时如何使用SOP实例状态的若干规定：
a.应用程序（用于诊断目的并且遵守“在线电子存储安全规则”和SOP实例创建者）应该：
1SOP实例状态设置为原始状态（OR）。
2包含如下属性：
a）SOPClassUID（0008,0016）和SOPInstanceUID（0008,0018）
b）实例创建日期（0008,0012）和实例创建时间（0008,0013）
c）SOP实例状态
d）SOP认证日期和时间（0100,0420）
e）SOP认证注释（0100,0424）
f）SOP设备标识码（0100,0426）
g）StudyInstanceUID（0020,000D）和SeriesInstanceUID（0020,000E）
h）设备模块的其他属性
i）现有覆盖图
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.相互已经认证，并且使用一致的在线存储规则。
3.传送后，如果完整性检查不通过，接受方应能够拒绝对方的存储请求。
4.传输时的认证使用存储确认服务类的推进模式，在认证结束前，接受方不能再把此SOP实例发往其他任何地方。
5.一旦发送方把SOP实例传送到目的地，那么就要选择下面其中一种方法来处理本地的SOP实例：
a）删除SOP实例
b）改变SOP实例状态为“不指定”（NS）
c）如果SOP实例的状态为AO，那么要变为“原始拷贝”（AC）。
e.通信时，如果满足下面的条件，主叫方（SOP实例状态为AO或AC）发送AC状态的SOP实例到接受方：
1.保证传输的安全
2.相互已经认证，并且使用一致的在线存储规则。
3.发送方把SOP实例的状态改为NS或AC作为拷贝发送。
SOP实例UID不变。
4.传送后，如果完整性检查不通过，接受方应能够拒绝对方的存储请求。
f.如果有一方不支持在线电子存储规则或者当通信不是在安全传输连接下进行的，那么：
1.发送方（支持在线电子存储规则）有可能把SOP实例的状态设为NS或者不改变原来的状态和相关的参数。
2.接受方（支持在线电子存储规则）把任何接到的SOP实例状态设为NS。
g.接受方在保存SOP实例时，要按照存储服务类第二级的规定，保持实例的属性的原样，包括私有属性。
除了SOP实例状态、SOP授权日期和时间、授权设备证书号码以及SOP授权评注以外，不能再强制要求提供其他的属性。
h.接受方可以改变SOP实例状态、SOP授权日期和时间、授权设备证书号码以及SOP授权评注这些属性，还包括由于属性变化而变化的段的长度。
但不能改变其他的任何属性值。
A.2数字签名的基本安全规则
任何应用程序应当符合数字签名的基本安全规则，并且在处理数字签名时须遵循以下规则：
a.以适当的方式保存SOP实例，拒绝未授权的非法SOP实例。
b.必须验证所有SOP实例的数字签名。
c.发送SOP实例到别的应用程序时，要：
1.移除所有无效的数字签名，无效的原因是属性值的格式发生了变化（如去掉左右空格、号码格式的改变）。
2.生成多个新的数字签名用于SOP实例被接收时的验证。
A.3BIT-PRESERVING数字签名的基本安全规则
声明支持此种数字签名的应用程序要满足下面的若干规定：
a.接受时，不改变SOP实例中的任何属性值，原封不动的发给其他的应用程序。
b.不改变队列中每个属性的排列顺序。
c.不能删除和修改任何属性值，包括所有的数字签名。
d.使用显式的传输语法。
注：
不支持显式的传输语法的应用程序不能使用这种安全规则，因为隐式的传输语法下不能验证数字签名。
e.不改变属性值的类型。
附件B安全传输连接安全规则
B.1基本TLS安全传输连接
一个支持基本TLS安全传输连接规则的应用程序须利用由传输层安全（TLS）1.0版协议规定的框架和协议机制。
表B.1-1具体描述了TLS以内的相应的特征受到应用实体的支持的情况下必须受支持的各种机制。
本规则并不要求应用程序支持TLS的所有的特征（实体鉴定、编密码、检查完整性）。
如果在TLS信道建立的时候协议同意的话，其他的机制也可以受支持。
表B.1-1最低限度的TLS特征的机制
一个应用程序是在IP端口上接受TLS连接的，或者说，这个端口号码就是由这个机制所选择或设定的；无论是IP端口，或这种机制都须在一致声明中明确说明。
这个端口必须不同于用于其他类型的传输连接（安全或非安全的）的端口。
注：
建议支持基本TLS安全传输连接规则的系统给位于TLS:
（十进制）上的DICOM上层服务协议使用注册的端口号“2762dicom－tls”作为它们的端口。
一致声明还须指出应用程序使用何种机制来管理密匙。
规则自己不需说明TLS安全传输连接是如何建立的，也不需说明在对等的实体鉴别期间所交换的任何证书的具体意义。
这类问题留给应用实体来解决；一般说来应用实体是要遵循某些现场确定的安全政策的。
应用实体可以利用证书拥有者的身份支持跟踪记录，或者用某些外部访问规则来限制。
一旦应用实体建立了一个安全传输连接，上层联络就可以使用该安全信道了。
注：
在PDU大小和影响传输效率的TLS记录大小之间，可能会出现一种交互作用。
TLS记录的最大许可容量小于PDU最大许可容量。
当完整性检查失败的时候，许根据TLS协议断开连接，这样就会导致发送方和接受方两个方面都向上层发送指令，按照应用程序的特定要求说明提供方原因。
有关所用到的提供方原因这一内容，须在一致声明中明文阐述。
注：
如果完整性检查失败，则说明信道的安全性已经有可能受损。
B.2ISCL安全传输连接规则
一个支持ISCL传输连接规则的功能模组须利用《综合安全通讯层V1.0》所规定的框架结构和协议机制。
一个应用实体须使用ISCL来选择表B.2-1中具体说明的机制。
一个应用实体在最低限度上须使用一个实体鉴别机制以及数据完整性检验。
一个应用实体可以选择性地使用一个机密/不收干扰的机制。
表B.2-1ISCL特征的机制之最低限度
注：
在线电子存储可以选择DES用作保护隐私。
对于数据完整性的检查而言，应用程序既可以加密在应用MD-5之前的随机号码，也可以加密MD-5的结果；关于其顺序请见协议中的详细说明。
接受方须能够在不受序的影响的情况下执行对消息的完整性的检查。
一个应用程序是在IP端口上接受ISCL连接的，或者说，这个端口号码就是由这个机制所选择或配置/设定的；无论是IP端口，或这种机制都须在一致声明中明确说明。
这个端口必须不同于用于其他类型的传输连接（安全或非安全的）的端口。
注：
建议支持基本ISCL安全传输连接规则的系统给位于ISCL上的DICOM上层服务协议使用注册的端口号“2761dicom－iscl”作为它们的端口。
一致声明还须指出管理密匙的机制。
规则自己不需说明TLS安全传输连接是如何建立的。
这个问题留给应用实体来解决；一般说来应用实体是要遵循某些现场确定的安全政策的。
一旦应用实体建立了一个安全传输连接，上层联络就可以使用该安全信道了。
注：
在PDU大小和影响传输效率的ISCL记录大小之间，可能会出现一种交互作用。
当完整性检查失败的时候，许根据TLS协议断开连接，这样就会导致发送方和接受方两个方面都向上层发送指令，按照功能模组的特定要求说明提供方原因。
有关所用到的提供方原因（出自提供方的原因）这一内容，须在一致声明中明文阐述。
注：
如果完整性检查失败，则说明信道的安全性已经有可能受损。
附件C数字签名
C.1基本RSA数字签名规则
基本RSA数字签名规则概述了利用一个MAC的RSA编码法来生成一个数字签名的方法。
本配置文件不对需要签署的数据元素的特定集合做确切规定。
其他的数字签名规则可能会参考到本规则，可能会添加上一些有关该签署哪些数据元素的详细说明或者其他的定制。
数字签名的创建者须使用RIPEMD-160，MD5，或SHA-1之散列法功能之一来生成一个MAC；随后，用一个秘密的RSA密匙就可以把这个MAC加密。
所有的数字签名须验证生效，这一过程必须通过利用由三个散列法功能（RIPEMD-160，MD5或SHA-1对这三个功能做了具体规定）之任意一个所生成的MAC来完成。
注：
关于是否使用MD5，其发明者，RSA，并没有推荐。
见：
ftp:
//
将被标记的MAC须被填补到与RSA密匙区匹配的一个字区上（须被填补到映射RSA密匙区的一个字区上），具体方法见RFC2437（PKCS#1）。
MAC运算法则的值须被设定为“RIPEMD160”，“MD5”或“SHA1”。
与应用实体的身份或拥有/承认RAS密匙配对的设备生产商、以及个人/私人/自定的密匙相关的公共密匙须在一个X.509（1993）签名证书中传输/发射。
证书类型（0400,0110）属性的值须被设定为“X509_1993_SIG”。
为特定区域所创建的政策（现场制定的政策）可以确定X.509证书是如何生成、鉴别以及分布的。
一个场所/地址可以直接发送并分配X.509证书，可以使用证书授权服务，或使用证书生成和确认的相应方法。
如果利用时间标记，则必须使用“CMS_TSP”被鉴定的时间标记类型（0400,0305）。
根据“InternetX.509PublicKeyInfrastructure;TimeStampProtocols;March2000（《因特网X.509公共密匙下部结构；时间标记协议；2002三月》）的说明，必须生成被鉴定的时间标记（0400,0310）。
C.2创建者RSA数字签名规则
DICOMSOP实例的创建者可以利用创建者RSA数字签名规则来生成签名。
由本规则所产生的数字签名可用作永久性的数据完整性检查标记；该标记可用以查证SOP实例中的像素数据自从最初创建以来是否被更改过。
支持创建者RSA数字签名规则的一个应用程序可以随同它所创建每一个SOP实例一起包含一个创建者RSA数字签名；然而，并不是非被要求这样作不可。
一个功能模组在生成创建者RSA数字签名时须在最低限度上包含以下属性：
a.SOP类和实例UIDs
b.SOP创建日期和时间（如果存在的话）
c.检查和系列实例UIDs
d.所出现的综合设备模块的任何属性
e.所出现的覆盖平面、曲线或图解说明/注释模块的任何属性
f.所出现的综合影像和影像像素模块的任何属性
g.所出现的SR文件概要和SR文件内容模块的任何属性
h.所出现的波形和波形说明/注解模块的任何属性
创建数字签名时须用到基本RSA数字签名规则中说明的方法。
很具有明显特征的一点就是，用来生成创建者RSA数字签名的证书以及相关联的密匙都是有服务或安装工程师设定的应用实体的配置参数。
创建者RSA数字签名与其他的数字签名没有直接关系。
然而，其他的数字签名，如授权数字签名，可被用来与一个创建者RSA数字签名的时间标记相互协作。
C.3授权RSA数字签名规则
如果技术人人员或医师认为可以使用某个DICOMSOP实例，他可能会利用授权RSA数字签名规则来请求应用实体生成一个签名。
所生成的数字签名可被用作永久性的数据完整性检查标记；该标记可用以查证SOP实例中的像素数据与技术人员或医师核准时所看到的一样。
一个功能模组在生成授权RSA数字签名时须在最低限度上包含以下属性：
a.SOP类和实例UIDs
b.检查和系列实例UIDs
c.技术人员或医师可以证实其值的所有属性（即，它们的值显示给技术人员或医师）
d.所出现的覆盖平面、曲线或图解说明/注释模块的任何属性
e.所出现的综合影像和影像像素模块的任何属性
f.所出现的SR文件概要和SR文件内容模块的任何属性
g.所出现的波形图的属性
创建数字签名时须用到基本RSA数字签名规则中说明的方法。
应用实体须确定技术人员或医师的身份并通过注册/登录机制或智能卡之类的与场合有关的程序获得它们的证书。
授权RSA数字签名与其他的数字签名没有直接关系。
然而，其他的数字签名，如创建者RSA数字签名，可被用来与一个授权RSA数字签名的时间标记相互协作。
附件D媒体存储安全规则
D.1基本DICOM媒体安全规则
基本DICOM媒体安全规则允许将一个DICOM文档压缩成一个安全DICOM文件，因此，需要强调以下几个方面：
—机密性
—完整性
—数据源鉴定（选择性的）
本规则确定的内容为：
适应于内容译码的“三元组－DES”的使用，以及“三元组－DES”内容译码密匙的密匙传输的RSA。
被译码/加密的内容就是一个DICOM文件，该文件要么可以：
－由一个或多个数字签名来标记；标记过程中用SHA-1为分节运算法则，RAS为署名/信号/标记运算法则；要么也可以：
－以SHA-1为分解运算法则被分解，而不需实事数字签名。
D.1.1DICOM文件封包成安全DICOM文件
一个与本安全规则一致的安全DICOM文件须包含一个套封数据内容类型的密码信息语法（关于该语法的规定，见RFC2630）。
套封数据须使用RSA[RFC2313]来实现三元组-DES内容译码密匙的传输。
根据ANSIX9.52的规定，该三元组-DES密匙长度为168比特。
其编码须按照RFC-2630中的RSA密匙传输的规格来完成。
套封数据内容类型的机密内容须为以下选择之一：
－有符号数据内容类型
－分解数据内容类型
在两种情况下，必须使用SHA-1[SHA-1]作为分解运算法则。
在有符号数据内容类型的情况下，须使用RSA[RFC2313]作为签名/标记运算法则。
注：
1.在《EuropeanPrestandardENV13608-2:
健康信息学－保健通讯的安全－第二章：
保护数据物件》中，三元组-DES内容加密密钥的RSA传输被确定为一种必要条件。
2.关于用作RSA密钥传输的不对成的密钥配对的大小，本配置文件没有作任何要求。
3.关于有符号数据内容类型的标记者信息结构的有符号属性元素的使用，本配置文件/协议子集没有提出任何要求或限制。
根据ENV13608-2的要求有符号属性可以被用来确定标记时间或SMIME容量/性能。
升级会员 