参考版本2001.doc

参考版本2001 翻译者：Myth 联系地址：yyyyinsheng@163.net 一 应用的领域和范围 本章详细说明了应用程序可能应该遵守的安全规则。 尽管应该定义所有级别的安全规则，但是DICOM标准并没有在任何其他的地方列出或者讨论有关安全政策方面的问题。而仅仅提供了用在两个通信的应用程序之间交换信息时应遵守的安全规则。例如，一条安全规则应该规定某个级别的访问控制规则。DICOM标准不研究访问控制时的安全规则，只提供适当的技术手段，让两个应用程序通过交换足够多的信息来实现安全。 DICOM标准假定通信中的应用程序应该实现（但不仅仅局限于）下面的安全规则，如财务追踪、物理的保护、数据的保密和完整性和用户管理。最重要的是，在与其他应用程序通信前，必须要保证自身所处的环境是安全的。 若两个应用程序通过DICOM协议连接上，它们实际上同意了并接收了对方实体的安全级别。这时，主应用程序信任对方在他们的控制下能够保持它们数据的保密和完整性。当然这种级别上的信任也可由本地的设置得到。 应用程序可能并不相信其所处的通信线路是完全安全的。在通信的过程中，信息有可能被篡改，也有可能被截获用于不法用途，基于这种情况，DICOM标准规定通信双方需要安全认证。应用程序可以根据现实情况（网络范围），有选择的使用何种级别的认证。 DICOM标准假定，应用程序应该确保本地用户是合法的。用户可以是人或者抽象实体（组织或仪器）。通信时，应用程序可以传递用户的信息以便对方可以验证自己的身份。对方可以依据传送过来的用户信息决定此用户的使用权限，并且记录相关的财务信息。 DICOM标准假定信息的持有者（病人或组织机构）已经授权给应用程序的用户进行通信，但不关心他们之间是如何进行授权的。 DICOM 标准假定应用程序使用TLS（Transport Layer Security）进行安全访问或者是能够安全的获得X.509用户认证证书。另外，他也假定应用程序能够解读X.509证书。解读可以通过本地设置、公开的有用的认证或者是可信任的第三方。 DICOM 标准假定使用ISCL（Integrated Secure Communication Layer）的应用程序有权使用适当的密匙管理和分配系统（如IC卡）。标准中不介绍有关这方面的情况。 二 参考资料 三 定义 3.1 参考模型 a. 应用程序 b. 协议数据单元（PDU）或 链路协议数据单元（Layer Protocol Data Unit） c. 传输连接 3.2 安全体系结构模型 数据保密性 注：非法用户或程序不能访问信息。 数据来源认证 注：对数据源进行确认。 数据完整性 注：在没有授权的情况下不允许更改或删除数据。 密匙管理 注：创建、存储、分配、删除、保存和应用密匙的一套安全规则。 数字签名 注：通过传递加密的数据来保证数据源的完整性和安全性，防止伪造。 3.3 ACSE服务 a. 连接或应用连接 3.4 安全性 内容 注：它表现为一种安全信息，这信息是用来与一个已经存在或即将存在的启动程序或接受程序进行安全连接的。 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 安全框架 本章使用的术语， 安全的传输连接：要求在某个级别上保护信息不被篡改、窃听和伪造。 消息识别码：从信息中产生的摘要码或无序码。 证书：电子文档，用以识别某个部分和其公共的加密算法，参数和密匙。证书中存放了创建者的数字签名。证书的内容和格式由 ITU-T Recommendation X.509 定义。 五 约定 六 安全规则概要 应用程序可能支持一个或多个安全规则。它必须要在说明书中写明支持何种安全规则。 6.1 安全使用规则 应用程序可以任意使用安全规则。规则描述了其使用方法和与之相关的规则，详细说明见附件A。 6.2 安全传输和连接规则 应用程序可以任意使用安全传输和连接的规则。它包含了下面这些方面： 协议的框架和协商的机制。 b. 如何认证 1. 确认的ID 2. 如何确认 3. 财务记录 c. 如何加密 1. 如何分发密匙 2. 加密协议和相关参数 d. 数据完整性检查 详见附件B 6.3 数字签名 支持多种数字签名的方式 数字签名包含以下信息： a. 签名者的角色 1. 谁或者是什么实体 2. 描述签名的用途 3. 数据集拥有数字签名的条件 b. 签名属性列表 c. 产生