ISCL and DICOM Security Included with LEADTOOLS Medical Imaging Suite

LEADTOOLS' General Integrated Secure Communication Layer (ISCL) Information

The Integrated Secure Communication Layer (ISCL) provides a means of adding security to DICOM communication. The security added targets three main areas:

• Computer or Entity Authentication
• Confidentiality
• Data Integrity

Key Features The key features are explained below

Computer/Entity Authentication:

Computer or entity authentication will allow both the client and the server make sure the computer to which they are communicating (the peer computer) is "legitimate" for communication. This is accomplished by exchanging challenge codes and response codes. This occurs during "mutual authentication". Currently, the only mutual authentication protocol is the "Three-pass-four-way" protocol.

Before establishing a DICOM Associate connection between two computers, each computer should "authenticate" the other computer. This ensures that both computers are legitimate, and are qualified to have access to the information that may be transferred. This is accomplished through mutual authentication.

A specific mode can be used for the mutual authentication process. During the mutual authentication process, authentication data, an authentication key and an index for the authentication key is used to authenticate one entity to another.

In addition, during the mutual authentication process an index into an array of authentication keys is used to further authenticate an entity. The authentication keys for both the client and the server must be the same. An index is used to specify which key in the array should be used for authentication.

Confidentiality:

Communication confidentiality is achieved by encrypting the data sent over the communication channel. Currently, the encryption options are:

• No encryption
• DES-CBC encryption. This is a 56 bit effective key length in a 64 bit key encryption in cipher block chaining mode.

Once two computers have authenticated each other, they can begin transferring messages and data between them. The confidentiality of these transfers is maintained by encrypting the data sent over the communication channel. Both encryption modes specified by the ISCL standard (DES-CBC and no encryption) are supported by LEADTOOLS. In addition, during the encryption/decryption process an index into an array of encryption keys is used to further guard data confidentiality. The encryption keys for both the client and the server must be the same. An index is used to specify which key in the array should be used for encryption.

Data Integrity:

Data integrity is maintained by using message authentication codes for each message sent across a DICOM Network. These message authentication codes are encrypted using the same encryption mode used for encrypting data. Currently, ISCL uses DESMAC (64 bit) and MD5 (128 bit) message authentication codes.

Protocols:

There are four protocols covered by the ISCL standards. These are:

• Line connection
• Mutual authentication
• Sending and receiving messages
• Line disconnection

Line connection:

The Line Connection Protocol is used to establish the maximum packet size for transferring information between a client and a server, and for determining the version of the ISCL standard to use. Generally, a client will request a connection with a server. The server can then accept or reject the connection request. The server will also then request a line connection check to determine whether the client and the server can communicate. Along with this request, the server sends information on the maximum packet size it can handle and the version of the standard it uses.

The client receives this information and generates a line connection response. Please note that the maximum packet size will be the smaller value of the client's maximum packet size and the server's maximum packet size. The client then sends a line connection response back to the server.

Once the line connection has been successfully established, the server is then ready to request mutual authentication.

Mutual authentication:

The mutual authentication protocol lets both the client and the server verify that the computer to which each is connected is cleared to receive information. The server begins by issuing a GETCHALLENGE command. This generates a random number, which in turn is used to create a challenge code.

The challenge code is then sent to the client. The client issues an INTERNAL AUTHENTICATE command, which takes the challenge code and generates a response code. This response code is then returned to the server. The client has also generated its own GETCHALLENGE command and has generated a challenge code. This is sent to the server with the response code. This allows the client to verify that it should be communicating with the server.

The server receives the response code from the client and generates an EXTERNAL AUTHENTICATE command. The original challenge code and the response code returned from the client are compared. If the response code is found to be a legitimate response code for the challenge code, the server has authenticated the client. The server also takes the challenge code received from the client and generates an INTERNAL AUTHENTICATE command. This also generates a response code from the received challenge code. This response code is then sent back to the client.

The client receives the response code from the server and generates an EXTERNAL AUTHENTICATE command. The original challenge code is compared to this response code. If the response code is found to be a legitimate response code for the challenge code, the client has authenticated the server.

At this point, the client sends the server a message that the mutual authentication has been completed.

Sending and receiving messages:

Messages may be sent secured or unsecured. Regardless of the encryption mode or the message authentication mode, messages can still be sent unsecured.

Sending and receiving a secured message is achieved by encrypting the data and adding a message authentication code also encrypted, to the message. Upon receipt, the message is decrypted and the authentication code verified.

Line disconnection:

When the connection is no longer needed, one computer/entity of a connection sends a line disconnection request to the other (peer) computer. The computer receiving the request then sends a line disconnection response.

Back to the DICOM Security Page

Related products

Pricing Structure

Product	Price	Purchase	Try
LEADTOOLS Medical Imaging Suite	†$7995		Free Trial

†Marked toolkits require runtime licensing based on the deployment of the application you develop. Several purchase options are available. For more information, please contact oemsales@leadtools.com or call a LEAD sales representative.