The DICOM standard does not address issues of security policies, though clearly adherence to appropriate security policies is necessary for any level of security. The standard only provides mechanisms that could be used to implement security policies with regard to the interchange of DICOM objects between Application Entities. For example, a security policy may dictate some level of access control. This Standard does not consider access control policies, but does provide the technological means for the Application Entities involved to exchange sufficient information to implement access control policies.

This Standard assumes that the Application Entities involved in a DICOM interchange are implementing appropriate security policies, including, but not limited to access control, audit trails, physical protection, maintaining the confidentiality and integrity of data, and mechanisms to identify users and their rights to access data. Essentially, each Application Entity must insure that their own local environment is secure before even attempting secure communications with other Application Entities.

When Application Entities agree to interchange information via DICOM through association negotiation, they are essentially agreeing to some level of trust in the other Application Entities. Primarily Application Entities trust that their communication partners will maintain the confidentiality and integrity of data under their control. Of course that level of trust may be dictated by local security and access control policies.

Application Entities may not trust the communications channel by which they communicate with other Application Entities. Thus, this Standard provides mechanisms for Application Entities to securely authenticate each other, to detect any tampering with or alteration of messages exchanged, and to protect the confidentiality of those messages while traversing the communications channel. Application Entities can optionally utilize any of these mechanisms, depending on the level of trust they place in the communications channel.

This Standard assumes that Application Entities can securely identify local users of the Application Entity, and that user's roles or licenses. Note that users may be persons, or may be abstract entities, such as organizations or pieces of equipment. When Application Entities agree to an exchange of information via DICOM, they may also exchange information about the users of the Application Entity via the Certificates exchanged in setting up the secure channel. The Application Entity may then consider the information contained in the Certificates about the users, whether local or remote, in implementing an access control policy or in generating audit trails.

This Standard also assumes that Application Entities have means to determine whether or not the "owners" (e.g., patient, institution) of information have authorized particular users, or classes of users to access information. This Standard further assumes that such authorization might be considered in the access control provided by the Application Entity. At this time, this Standard does not consider how such authorization might be communicated between Application Entities, though that may be a topic for consideration at some future date.

This Standard also assumes that an Application Entity using TLS has secure access to or can securely obtain X.509 key Certificates for the users of the application entity. In addition, this standard assumes that an Application Entity has the means to validate an X.509 certificate that it receives. The validation mechanism may use locally administered authorities, publicly available authorities, or some trusted third party.

This Standard assumes that an Application Entity using ISCL has access to an appropriate key management and distribution system (e.g., smartcards). The nature and use of such a key management and distribution system is beyond the scope of DICOM, though it may be part of the security policies used at particular sites.

The System Management Profiles specified in this Part are designed to support automation of the configuration management processes necessary to operate a system that uses DICOM Standard protocols for information interchange.

This Part assumes that the Application Entities may operate in a variety of network environments of differing complexity. These environments may range from a few units operating on an isolated network, to a department-level network with some limited centralized network support services, to an enterprise-level network with significant network management services. Note that the System Management Profiles are generally addressed to the implementation, not to Application Entities. The same Profiles need to be supported by the different applications on the network.

This part of the Standard makes use of the following terms defined in ISO 7498‑1:

This Part of the Standard makes use of the following terms defined in ISO 7498-2:

This part of the Standard makes use of the following terms defined in ISO 8649:

This Part of the Standard makes use of the following terms defined in ECMA 235:

This Part of the Standard makes use of the following terms defined in PS3.1:

This Part of the Standard makes use of the following terms defined in PS3.2:

This Part of the Standard makes use of the following terms defined in PS3.3:

This Part of the Standard makes use of the following terms defined in PS3.4:

This Part of the Standard makes use of the following terms defined in PS3.8:

The following definitions are commonly used in this Part of the DICOM Standard:

An implementation may claim conformance to one or more Secure Use Profiles. Such profiles outline the use of attributes and other Security Profiles in a specific fashion.

Secure Use Profiles are specified in Annex A.

An implementation may claim conformance to one or more Secure Transport Connection Profiles.

A Secure Transport Connection Profile includes the following information:

Secure Transport Connection Profiles are specified in Annex B.

An implementation may claim conformance to one or more Digital Signature Profiles.

A Digital Signature profile consists of the following information:

Digital Signature Profiles are specified in Annex C.

An implementation may claim conformance to one or more Media Storage Application Profiles, which in turn require conformance to one or more Media Storage Security Profiles.

A Media Storage Security Profile includes the following specifications:

Media Storage Security Profiles are specified in Annex D.

An implementation may claim conformance to one or more Network Address Management Profiles. Such profiles outline the use of non-DICOM network protocols to obtain the network addresses for the implementation.

Network Address Management Profiles are specified in Annex F.

An implementation may claim conformance to one or more Time Synchronization Profiles. Such profiles outline the use of non-DICOM protocols to set the current time for the implementation.

Time Synchronization Profiles are specified in Annex G.

An implementation may claim conformance to one or more Application Configuration Management Profiles. Such profiles outline the use of non-DICOM network protocols to obtain the descriptions, addresses and capabilities of other devices with which the implementation may communicate using the DICOM Protocol. They also specify the use of those non-DICOM protocols for the implementation to publish or announce its description, addresses and capabilities. They also specify how implementation specific configuration information can be obtained by devices.

Application Configuration Management Profiles are specified in Annex H.

An implementation may claim conformance to one or more Audit Trail Profiles. Such profiles outline the generation and transport of audit messages for security and privacy policy enforcement.

Audit Trail Profiles are specified in Annex A.

DHCP Server

The DHCP Server is a computer/software feature that is provided with a network configuration description, and that provides startup configuration services in accordance with the DHCP protocol.

DHCP Client

The DHCP Client is a software feature that is used to obtain TCP/IP parameters during the startup of a computer. It continues operation to maintain validity of these parameters.

DNS Server

The DNS server is a computer/software feature that provides IP related information in response to queries from clients utilizing the DNS protocol. It is a part of a federated database facility that maintains the current database relating machine names to IP address information. The DNS server may also be isolated from the worldwide federated database and provide only local DNS services.

DNS Client

The DNS client as a computer/software feature that utilizes the DNS protocols to obtain IP information when given hostnames. The hostnames may be in configuration files or other files instead of explicit IP addresses. The hostnames are converted into IP addresses dynamically when necessary. The DNS client uses a DNS server to provide the necessary information.

NTP Server

The NTP server is a computer/software feature that provides time services in accordance with the NTP or SNTP protocol.

NTP Client

The NTP client is software that obtains time information from an NTP server and maintains the client time in synchronization with the time signals from the NTP server.

SNTP Client

The SNTP client is software that obtains time information from an NTP server and maintains the client time in approximate synchronization with time signals from the NTP server. The SNTP client synchronization is not maintained with the accuracy or precision that NTP provides.

LDAP Server

The LDAP server is a computer/ software feature that maintains an internal database of various directory information. Some of this directory information corresponds to DICOM Configuration schema. The LDAP server provides network access to read and update the directory information. The LDAP server provides a mechanism for external loading, unloading, and backup of directory information. The LDAP server may be part of a federated network of servers that provides a coordinated view of a federated directory database in accordance with the rules of the LDAP protocols.

LDAP Client

The LDAP client utilizes the LDAP protocol to make queries to an LDAP server. The LDAP server maintains a database and responds to these queries based on the contents of this database.

The following transactions are used to provide communications between actors in accordance with one or more of the DICOM Configuration protocols.

Configure DHCP Server

This transaction changes the configuration on a DHCP server to reflect additions, deletions, and changes to the IP parameters that have been established for this network.

Find and Use DHCP Server

This transaction is a sequence of network messages that comply with the rules of the DHCP protocol. It allows a DHCP client to find available DHCP servers and select the server appropriate for that client. This transaction obtains the mandatory IP parameter information from the DHCP server and obtains additional optional parameters from the DHCP server.

Configure Client

The service staff uses this transaction to set the initial configuration for a client.

Maintain Lease

This transaction deals with how the DHCP client should behave when its IP lease is not renewed.

DDNS Coordination

This transaction documents whether the DHCP server is coordinating with a DNS server so that access to the DHCP client can be maintained using the hostname assigned to the DHCP client.

Resolve Hostname

This transaction obtains the IP address for a computer when given a hostname.

Maintain Time

These transactions are the activities needed for an NTP or SNTP client to maintain time synchronization with a master time service.

Find NTP Server

This transaction is the autodiscovery procedure defined for NTP. This may use either a broadcast method or a DHCP supported method.

Find LDAP Server

In this transaction the DNS server is queried to obtain the IP address, port, and name of the LDAP server.

Query LDAP Server

In this transaction the LDAP server is queried regarding contents of the LDAP database.

Client Update LDAP Server

This transaction updates the configuration database using LDAP update instructions from the client being configured.

Maintain LDAP Server

This transaction updates the configuration database using local services of the LDAP server.

Figure 7-1 shows the actors and their transactions. The usual device will have an NTP Client, DHCP Client, and LDAP client in addition to the other applications actors. The transactions "Configure DHCP Server", "Configure Client", and "Maintain LDAP Server" are not shown because these transactions are between a software actor and a human actor. DICOM does not specify the means or user interface. It only requires that certain capabilities be supported.

Figure 7-1. Transactions and Actors

The Online Electronic Storage Secure Use Profile allows Application Entities to track and verify the status of SOP Instances in those cases where local security policies require tracking of the original data set and subsequent copies.

The Conformance Statement shall indicate in what manner the system restricts remote access.

An implementation that validates and generates Digital Signatures may claim conformance to the Basic Digital Signatures Secure Use Profile. Any implementation that claims conformance to this Security Profile shall obey the following rules in handling Digital Signatures:

An implementation that stores and forwards SOP Instances may claim conformance to the Bit-Preserving Digital Signatures Secure Use Profile. Any implementation that claims conformance to this Security Profile shall obey the following rules in handling Digital Signatures:

Any implementation that claims conformance to this Security Profile shall obey the following rules when creating a Structured Report or Key Object Selection Document that includes Digital Signatures:

The implementation claiming conformance shall outline in its conformance statement the conditions under which it will either sign or not sign a Structured Report or Key Object Selection Document.

To help assure healthcare privacy and security in automated systems, usage data need to be collected. These data will be reviewed by administrative staff to verify that healthcare data is being used in accordance with the healthcare provider's data security requirements and to establish accountability for data use. This data collection and review process is called security auditing and the data itself comprises the audit trail. Audit trails can be used for surveillance purposes to detect when interesting events might be happening that warrant further investigation.

This profile defines the format of the data to be collected and the minimum set of attributes to be captured by healthcare application systems for subsequent use by a review application. The data includes records of who accessed healthcare data, when, for what action, from where, and which patients' records were involved. No behavioral requirements are specified for when audit messages are generated, or for what action should be taken on their receipt. These are subject to local policy decisions and legal requirements.

Any implementation that claims conformance to this Security Profile shall:

datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"

# This defines the coded value type. The comment shows a pattern that can be used to further
# constrain the token to limit it to the format of an OID.  Not all schema software 
# implementations support the pattern option for tokens.
other-csd-attributes =
  (attribute codeSystemName { token } |     # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"
     attribute codeSystemName { token }),   # This makes clear that codeSystemName is
                                            # either an OID or String 
  attribute displayName { token }?,
  attribute originalText { token }          # Note: this also corresponds to DICOM "Code Meaning"
CodedValueType =
  attribute csd-code { token },
  other-csd-attributes

# Define the event identification, used later

EventIdentificationContents =
  element EventID { CodedValueType },
  element EventTypeCode { CodedValueType }*, # Note: DICOM/IHE defines and uses this
                                             # differently than RFC-3881
  attribute EventActionCode {                # Optional action code
    "C" |              ## Create
    "R" |              ## Read
    "U" |              ## Update
    "D" |              ## Delete
    "E"                ## Execute
  }?,
  
  attribute EventDateTime { xsd:dateTime },
  attribute EventOutcomeIndicator {
    "0" |            ## Nominal Success (use if status otherwise unknown or ambiguous)
    "4" |            ## Minor failure (per reporting application definition)
    "8" |            ## Serious failure (per reporting application definition)
    "12"             ## Major failure, (reporting application now unavailable)
  },
  
  element EventOutcomeDescription { text }?
  
# Define AuditSourceIdentification, used later
#  Note: This includes one constraint that cannot be represented yet in RNC.  The use
#        of a token other than the specified codes is permitted only if the codeSystemName
#        is present.
#  Note: This has no elements, only attributes.

AuditSourceIdentificationContents =
  attribute code {
    "1" |                 ## End-user display device, diagnostic device
    "2" |                 ## Data acquisition device or instrument
    "3" |                 ## Web Server process or thread
    "4" |                 ## Application Server process or thread
    "5" |                 ## Database Server process or thread
    "6" |                 ## Security server, e.g., a domain controller
    "7" |                 ## ISO level 1-3 network component
    "8" |                 ## ISO level 4-6 operating software
    "9" |                 ## other
    token },              ## other values are allowed if a codeSystemName is present
  other-csd-attributes?,  ## If these are present, they define the meaning of code
  
  attribute AuditEnterpriseSiteID { token }?,
  attribute AuditSourceID { token },
  element AuditSourceTypeCode { token }*

# Define ActiveParticipantType, used later

ActiveParticipantContents =
  element RoleIDCode { CodedValueType }*,
  element MediaIdentifier {
    element MediaType { CodedValueType }
  }?,
  attribute UserID { text },
  attribute AlternativeUserID { text }?,
  attribute UserName { text }?,
  attribute UserIsRequestor { xsd:boolean },
  attribute NetworkAccessPointID { token }?,
  attribute NetworkAccessPointTypeCode {
    "1" |              ## Machine Name, including DNS name
    "2" |              ## IP Address
    "3" |              ## Telephone Number
    "4" |              ## Email address
    "5" }?             ## URI (user directory, HTTP-PUT, ftp, etc.)

# The BinaryValuePair is used in ParticipantObject descriptions to capture parameters.  
# All values (even those that are normally plain text) are encoded as xsd:base64Binary.
# This is to preserve details of encoding (e.g., nulls) and to protect against text
# contents that contain XML fragments.  These are known attack points against applications,
# so security logs can be expected to need to capture them without modification by the
# audit encoding process.

ValuePair =
  # clarify the name
  attribute type { token },
  attribute value { xsd:base64Binary } # used to encode potentially binary, malformed XML text, etc.

# Define ParticipantObjectIdentification, used later

# Participant Object Description, used later

DICOMObjectDescriptionContents =
  element MPPS {
    attribute UID { token }       # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"
  }*,
  element Accession {
    attribute Number { token }
  }*,
  element SOPClass {              # SOP class for one study
    element Instance {
      attribute UID { token }     # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"
    }*,
    attribute UID { token }?,     # OID pattern="[0-2]((\.0)|(\.[1-9][0-9]*))*"
    attribute NumberOfInstances { xsd:integer }
  },
  element ParticipantObjectContainsStudy {
    element StudyIDs {
      attribute UID { token }
    }*
  },
  element Encrypted { xsd:boolean }?,
  element Anonymized { xsd:boolean }?

ParticipantObjectIdentificationContents =
  element ParticipantObjectIDTypeCode { CodedValueType },
  (element ParticipantObjectName { token } |             # either a name or
  element ParticipantObjectQuery { xsd:base64Binary }),  # a query ID field,
  element ParticipantObjectDetail { ValuePair }*,   # optional details, these can be extensive
                                                    # and large
  element ParticipantObjectDescription { token }*,  # optional descriptive text
  DICOMObjectDescriptionContents,                   # These are extensions made by DICOM to RFC-
                                                    # 3881 schema for use describing DICOM objects
  attribute ParticipantObjectID { token },          # mandatory ID
  attribute ParticipantObjectTypeCode {             # optional type
    "1" | #3 Person
    "2" | #3 System object
    "3" | #3 Organization
    "4"   ## Other
  }?,
  
  attribute ParticipantObjectTypeCodeRole {          ## optional role
    "1" |         ## Patient
    "2" |         ## Location
    "3" |         ## Report
    "4" |         ## Resource
    "5" |         ## Master File
    "6" |         ## User
    "7" |         ## List
    "8" |         ## Doctor
    "9" |         ## Subscriber
    "10" |        ## guarantor
    "11" |        ## Security User Entity
    "12" |        ## Security User Group
    "13" |        ## Security Resource
    "14" |        ## Security Granulatiry Definition
    "15" |        ## Provider
    "16" |        ## Report Destination
    "17" |        ## Report Library
    "18" |        ## Schedule
    "19" |        ## Customer
    "20" |        ## Job
    "21" |        ## Job Stream
    "22" |        ## Table
    "23" |        ## Routing Criteria
    "24" }?,      ## Query?,
  
  attribute ParticipantObjectDataLifeCycle {          # optional life cycle stage
    "1" |         ## Origination, Creation
    "2" |         ## Import/ Copy
    "3" |         ## Amendment
    "4" |         ## Verification
    "5" |         ## Translation
    "6" |         ## Access/Use
    "7" |         ## De-identification
    "8" |         ## Aggregation, summarization, derivation
    "9" |         ## Report
    "10" |        ## Export
    "11" |        ## Disclosure
    "12" |        ## Receipt of Disclosure
    "13" |        ## Archiving
    "14" |        ## Logical deletion
    "15" }?,      ## Permanent erasure, physical destruction
  
  attribute ParticipantObjectSensistity { token }?
  
# The basic message
message =
  element AuditMessage {
    (element EventIdentification { EventIdentificationContents }, # The event must be identified
     element ActiveParticipant { ActiveParticipantContents }+, # It has one or more active
                                                               # participants
     element AuditSourceIdentification {                       # It is reported by one source
       AuditSourceIdentificationContents
     },
     element ParticipantObjectIdentification {                 # It may have other objects involved
       ParticipantObjectIdentificationContents
     }*)
  }

# And finally the magic statement that message is the root of everything.
start = message

    

This profile defines the transmission of audit trail messages. Transport Layer Security (TLS) Transport Mapping for Syslog (RFC 5425) provides the mechanisms for reliable transport, buffering, acknowledgement, authentication, identification, and encryption. The RFC5424 states that the TLS used MUST be TLS version 1.2. For this DICOM profile TLS MUST be used, and version 1.2 or later is RECOMMENDED.

Any implementation that claims conformance to this profile shall also conform to the Audit Trail Message Format Profile. XML audit trail messages created using the format defined in Audit Trail Message Format Profile shall be transmitted to a collection point using the syslog over TLS mechanism, defined in RFC 5425. Systems that comply with this profile shall support message sizes of at least 32768 octets.

The XML audit trail message shall be inserted into the MSG portion of the SYSLOG-MSG element of the syslog message as defined in RFC 5424 "The Syslog Protocol".The XML audit message may contain Unicode characters that are encoded using the UTF-8 encoding rules.

The PRI field shall be set using the facility value of 10 (security/authorization messages). Most messages should have the severity value of 5 (normal but significant), although applications may choose other values if that is appropriate to the more detailed information in the audit message. This means that for most audit messages the PRI field will contain the value "<85>".

The MSGID field in the HEADER of the SYSLOG-MSG shall be set. The value "DICOM+RFC3881" may be used for messages that comply with this profile.

The MSG field of the SYSLOG-MSG shall be present and shall be an XML structure following the RFC 3881 format, as extended in the audit trail message format profile.

The syslog message shall be created and transmitted as described in RFC 5424.

Any implementation that claims conformance to this Security Profile shall describe in its conformance statement:

This profile defines the transmission of audit trail messages. Transmission of Syslog Messages over UDP (RFC5426) provides the mechanisms for rapid transport of audit messages. It is the standardized successor to the informative standard "The BSD syslog protocol (RFC3164) ", which is widely used in a variety of settings.

The syslog port number shall be configurable, with the port number (514) as the default.

The underlying UDP transport might not accept messages longer than the MTU size minus the UDP header length. This may result in longer syslog messages being truncated. When these messages are truncated the resulting XML may be incorrect. Because of this potential for truncated messages and other security concerns, the transmission of syslog messages over TLS may be preferred (see Section A.6).

The PRI field shall be set using the facility value of 10 (security/authorization messages). Most messages should have the severity value of 5 (normal but significant), although applications may choose values of 4 (warning condition) if that is appropriate to the more detailed information in the audit message. This means that for most audit messages the PRI field will contain the value "<85>". Audit repositories shall be prepared to deal appropriately with any incoming PRI value.

The MSGID field in the HEADER of the SYSLOG-MSG shall be set. The value "DICOM+RFC3881" may be used for messages that comply with this profile.

The MSG field of the SYSLOG-MSG shall be present and shall be an XML structure following the RFC 3881 format, as extended in this profile.

The syslog message shall be created and transmitted as described in RFC 5424.

Any implementation that claims conformance to this Security Profile shall describe in its conformance statement:

An implementation that supports the Basic TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security Version 1.0 protocol. Table B.1-1 specifies mechanisms that shall be supported if the corresponding features within TLS are supported by the Application Entity. The profile does not require the implementation to support all of the features (entity authentication, encryption, integrity checks) of TLS. Other mechanisms may also be used if agreed to by negotiation during establishment of the TLS channel.

IP ports on which an implementation accepts TLS connections, or the mechanism by which this port number is selected or configured, shall be specified in the Conformance Statement. This port shall be different from ports used for other types of transport connections (secure or unsecure).

The Conformance Statement shall also indicate what mechanisms the implementation supports for Key Management.

The profile does not specify how a TLS Secure Transport Connection is established, or the significance of any certificates exchanged during peer entity authentication. These issues are left up to the Application Entity, which presumably is following some site specified security policy. The identities of the certificate owners can by used by the application entity for audit log support, or to restrict access based on some external access rights control framework. Once the Application Entity has established a Secure Transport Connection, then an Upper Layer Association can use that secure channel.

When an integrity check fails, the connection shall be dropped per the TLS protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The provider reason used shall be documented in the conformance statement.

An implementation that supports the ISCL Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Integrated Secure Communication Layer, V1.00. An Application Entity shall use ISCL to select the mechanisms specified in Table B.2-1. An Application Entity shall as a minimum use an Entity Authentication mechanism and Data Integrity checks. An Application Entity may optionally use a privacy mechanism.

For the Data Integrity check, an implementation may either encrypt the random number before applying MD-5, or encrypt the output of MD-5. The order is specified in the protocol. A receiver shall be able to perform the integrity check on messages regardless of the order.

IP ports on which an implementation accepts ISCL connections, or the mechanism by which this port number is selected or configured, shall be specified in the Conformance Statement. This port shall be different from ports used for other types of transport connections (secure or unsecure).

The Conformance Statement shall also indicate what mechanisms the implementation supports for Key Management.

The profile does not specify how an ISCL Secure Transport Connection is established. This issue is left up to the Application Entity, which presumably is following some site specified security policy. Once the Application Entity has established a Secure Transport Connection, then an Upper Layer Association can use that secure channel.

When an integrity check fails, the connection shall be dropped, per the ISCL protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The provider reason used shall be documented in the conformance statement.

An implementation that supports the AES TLS Secure Transport Connection Profile shall utilize the framework and negotiation mechanism specified by the Transport Layer Security Version 1.0 protocol. Table B.3-1 specifies mechanisms that shall be supported if the corresponding features within TLS are supported by the Application Entity. The profile does not require the implementation to support all of the features (entity authentication, encryption, integrity checks) of TLS. Other mechanisms may also be used if agreed to by negotiation during establishment of the TLS channel.

Two cyphersuite options shall be offered during TLS negotiation by applications that comply with this profile:

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

The application shall offer both options. The AES version shall be preferred. The fallback to 3DES is offered so that this profile can interoperate easily with applications that only support the 3DES cyphersuite.

IP ports on which an implementation accepts TLS connections, or the mechanism by which this port number is selected or configured, shall be specified in the Conformance Statement. This port shall be different from ports used for other types of transport connections (secure or unsecure).

The Conformance Statement shall also indicate what mechanisms the implementation supports for Key Management.

The profile does not specify how a TLS Secure Transport Connection is established, or the significance of any certificates exchanged during peer entity authentication. These issues are left up to the Application Entity, which presumably is following some site specified security policy. The identities of the certificate owners can by used by the application entity for audit log support, or to restrict access based on some external access rights control framework. Once the Application Entity has established a Secure Transport Connection, then an Upper Layer Association can use that secure channel.

When an integrity check fails, the connection shall be dropped per the TLS protocol, causing both the sender and the receiver to issue an A-P-ABORT indication to the upper layers with an implementation-specific provider reason. The provider reason used shall be documented in the conformance statement.

An implementation that supports the Basic User Identity Association profile shall accept the User Identity association negotiation sub-item, for User-Identity-Type of 1 or 2. It need not verify the passcode. If a positive response is requested, the implementation shall respond with the association response sub-item.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

An implementation that supports the User Identity plus Passcode Association Profile shall send/accept the User Identity association negotiation sub-item, for User-Identity-Type of 2. If a positive response is requested, the association acceptor implementation shall respond with the association response sub-item. The passcode information shall be made available to internal or external authentication systems. The user identity shall be authenticated by means of the passcode and the authentication system. If the authentication fails, the association shall be rejected.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

An implementation that supports the Kerberos Identity Negotiation Association Profile shall send/accept the User Identity association negotiation sub-item, for User-Identity-Type of 3. If a positive response is requested, the association acceptor implementation shall respond with the association response sub-item containing a Kerberos server ticket. The Kerberos server ticket information shall be made available to internal or external Kerberos authentication systems. The user identity shall be authenticated by means of the Kerberos authentication system. If the authentication fails, the association shall be rejected.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

An implementation that supports the Generic SAML Assertion Identity Negotiation Association Profile shall send/accept the User Identity association negotiation sub-item, for User-Identity-Type of 4. If a positive response is requested, the association acceptor implementation shall respond with the association response sub-item containing a SAML response. The SAML Assertion information shall be made available to internal or external authentication systems. The user identity shall be authenticated by means of an authentication system that employs SAML Assertions. If the authentication fails, the association shall be rejected.

The user identity from the Primary-field shall be used within the implementation as the user identification. Such uses include recording user identification in audit messages.

When a DICOM File Set is sent over Email transport in compliance with this profile the following rules shall be followed:

The email signature is present to provide minimum sender information and to confirm the integrity of the email transmission (body contents, attachment, etc.). The email signature is separate from other signatures that may be present in DICOM reports and objects contained in the File set attached to the email. Those signatures are defined in terms of clinical uses. Any clinical content attestations shall be encoded as digital signatures in the DICOM SOP instances, not as the email signature. The email may be composed by someone who cannot make clinical attestations. Through the use of the email signature, the composer attests that he or she is authorized to transmit the data to the recipient.

The Base RSA Digital Signature Profile outlines the use of RSA encryption of a MAC to generate a Digital Signature. This Profile does not specify any particular set of Data Elements to sign. Other Digital Signature profiles may refer to this profile, adding specifications of which Data Elements to sign or other customizations.

The creator of a digital signature shall use one of the RIPEMD-160, MD5, SHA-1 or SHA-2 family (SHA256, SHA384, SHA512) of hashing functions to generate a MAC, which is then encrypted using a private RSA key. All validators of digital signatures shall be capable of using a MAC generated by any of the hashing functions specified (RIPEMD-160, MD5, SHA-1 or SHA256, SHA384, SHA512).

The MAC to be signed shall be padded to a block size matching the RSA key size, as directed in RFC 2437 (PKCS #1). The Value of MAC Algorithm (0400,0015) shall be set to either "RIPEMD160", "MD5", "SHA1", "SHA256", "SHA384" or "SHA512". The public key associated with the private key as well as the identity of the Application Entity or equipment manufacturer that owns the RSA key pair shall be transmitted in an X.509 (1993) signature certificate. The Value of the Certificate Type (0400,0110) Attribute shall be set to "X509_1993_SIG". A site-specific policy determines how the X.509 certificates are generated, authenticated, and distributed. A site may issue and distribute X.509 certificates directly, may utilize the services of a Certificate Authority, or use any reasonable method for certificate generation and verification.

If an implementation utilizes timestamps, it shall use a Certified Timestamp Type (0400,0305) of "CMS_TSP". The Certified Timestamp (0400,0310) shall be generated as described in "Internet X.509 Public Key Infrastructure; Time Stamp Protocols; March 2000".

The creator of a DICOM SOP Instance may generate signatures using the Creator RSA Digital Signature Profile. The Digital Signature produced by this Profile serves as a lifetime data integrity check that can be used to verify that the pixel data in the SOP instance has not been altered since its initial creation. An implementation that supports the Creator RSA Digital Signature Profile may include a Creator RSA Digital Signature with every SOP Instance that it creates; however, the implementation is not required to do so.

As a minimum, an implementation shall include the following attributes in generating the Creator RSA Digital Signature:

The Digital Signature shall be created using the methodology described in the Base RSA Digital Signature Profile. Typically the certificate and associated private key used to produce Creator RSA Digital Signatures are configuration parameters of the Application Entity set by service or installation engineers.

Creator RSA Digital Signatures bear no direct relationship to other Digital Signatures. However, other Digital Signatures, such as the Authorization Digital Signature, may be used to collaborate the timestamp of a Creator RSA Digital Signature.

The technician or physician who approves a DICOM SOP Instance for use may request the Application Entity to generate a signature using the Authorization RSA Digital Signature Profile. The Digital Signature produced serves as a lifetime data integrity check that can be used to verify that the pixel data in the SOP instance is the same that the technician or physician saw when they made the approval.

As a minimum, an implementation shall include the following attributes in generating the Authorization RSA Digital Signature:

The Digital Signature shall be created using the methodology described in the Base RSA Digital Signature Profile. The Application Entity shall determine the identity of the technician or physician and obtain their certificate through a site-specific procedure such as a login mechanism or a smart card.

Authorization RSA Digital Signatures bear no direct relationship to other Digital Signatures. However, other Digital Signatures, such as the Creator RSA Digital Signature, may be used to collaborate the timestamp of an Authorization RSA Digital Signature.

This profile defines a mechanism for adding Digital Signatures to Structured Reports or Key Object Selection Documents where there is no more than one Verifying Observer. Instances that follow this Digital Signature Profile shall include at least one Digital Signature at the top level of the Data Set.

All Digital Signatures that follow this profile shall include a Digital Signature Purpose Code Sequence Attribute (0400,0401).

As a minimum, an implementation shall include the following attributes in generating the Digital Signature required by this profile:

If the Verification Flag is set to "VERIFIED" (and the SOP Instance UID can no longer change) at least one of the Digital Signatures profile shall have the purpose of (5,ASTM-sigpurpose,"Verification Signature") and shall also include the following Attributes in addition to the above attributes:

All occurrences of Referenced SOP Instance MAC Sequence (0400,0403) shall have the Value of MAC Algorithm (0400,0015) set to either "RIPEMD160", "MD5", "SHA1", "SHA256", "SHA384" or "SHA512"..

The Digital Signature shall be created using the methodology described in the Base RSA Digital Signature Profile. The Application Entity shall determine the identity of the signatories and obtain their certificate through an application-specific procedure such as a login mechanism or a smart card. The conformance statement shall specify how the application identifies signatories and obtains certificates.

The Basic DICOM Media Security Profile allows encapsulation of a DICOM File into a Secure DICOM File such that the following aspects of security are addressed:

This profile specifies the use of either AES or Triple-DES for content encryption and RSA, or password-based encryption and AES or Triple-DES, for the key transport of the content-encryption keys. The encrypted content is a DICOM File that can either

Application Level Confidentiality Profiles address the following aspects of security:

Other aspects of security not addressed by these profiles, that may be addressed elsewhere in the standard include:

These Profiles are targeted toward creating a special purpose, de-identified version of an already-existing Data Set. It is not intended to replace the original SOP Instance from which the de-identified SOP Instance is created, nor is it intended to act as the primary representation of clinical Data Sets in image archives. The de-identified SOP Instances are useful, for example, in creating teaching or research files, performing clinical trials, or submission to registries where the identity of the patient and other individuals is required to be protected. In some cases, it is also necessary to provide a means of recovering identity by authorized personnel.