Secure ICA Technical Overview Back to Secure ICA Section

RC5 keys

The RC5 algorithm is a symmetric key algorithm. One key is used to both encrypt and decrypt data. The security of the data depends on keeping the key secret. In order to keep data secure, there must be a method of exchanging the RC5 keys without allowing the keys themselves to be copied. The Diffie-Hellman key agreement algorithm generates the same RC5 key on the MetaFrame client and server without exchanging information that compromises the security of the key. The SecureICA Option Pack uses a total of four keys during each session.

During user logon, SecureICA uses two 128-bit keys for enhanced security. One key is used to encrypt ICA packets the server sends to the client. The other key is used for client to server communication.

The SecureICA Option Pack uses two 40, 56, or 128 bit keys to encrypt ICA packets after logon. One key is used when the server is sending data to the client. The other key is used for client to server communication. Using two separate keys increases security. The key size to use for the session is specified by the MetaFrame client. An administrator can specify the minimum key size in the WinStation Configuration and User Manager for Domains utilities.

Generating RC5 keys

Each time a MetaFrame client connects to a MetaFrame server the four RC5 keys are generated.

The Diffie-Hellman algorithm is used when two people need to establish secret keys but they cannot securely transmit those keys to each other. The MetaFrame server and the MetaFrame client establish RC5 session keys using the Diffie-Hellman key agreement algorithm.

The MetaFrame server periodically generates two numbers (A and B) using the Encryption Service installed by the SecureICA Option Pack. These numbers are the Diffie-Hellman parameters.

The MetaFrame server and client follow the steps outlined below to establish a 1024 bit secret key. This secret key is split into two 128 bit keys used during logon and two 128, 56, or 40 bit keys used after logon.

1. The MetaFrame server generates a private key K 1 each time a MetaFrame client connects.
   
    
2. Using the private key K 1 and the Diffie-Hellman parameters (A and B) the server generates a public key P 1 .
   
    
3. The MetaFrame server sends the MetaFrame client A, B, and the servers public key P 1 .
   
    
4. The MetaFrame client generates a private key K 2 each time a connection is made to a MetaFrame server. The client receives A, B, and the servers public key P 1 .
   
    
5. Using the private key K 2 and the MetaFrame servers public key P 1 , a 1024 bit secret key S is generated.
   
    
6. The MetaFrame client generates a public key P 2 using its private key K 2 and the Diffie-Hellman parameters (A and B).
   
    
7. The MetaFrame client sends its public key P 2 to the MetaFrame server.
   
    
8. The MetaFrame server receives the clients public key P 2 . Using the clients public key P 2 , the Diffie-Hellman parameters (A and B), and the servers private key K 1 , the MetaFrame server generates the secret key S.

The MetaFrame client and MetaFrame server both have the same 1024 bit secret key S.

The mathematical steps to generate the secret key are described below.

Server

Generate private key K1

Use two well known values A and B

Generate a public key P1 = AK1 mod B

Send P1, A, and B to the client.

Client

Client receives P₁, A, and B

Client generates a private key K₂

Client uses the public key P₁ and its private key K₂ to generate a secret key S using the following algorithm:

S = P₁ ^K2 mod B

Generate a public key P₂ = A^K2 mod B

Send P₂ to the server

Server

Server receives P₂

Server uses the public key P₂ and its private key K₁ to generate a secret key S using the following algorithm:

S = P₂ ^K1 mod B

Even if P_2, P₁, A and B are known by an intruder, S cannot be derived from that information. The algorithm relies on the mathematical property that

(A^K1 mod B) ^K2 mod B = A^{K1 K2} mod B

(A^K2 mod B) ^K1 mod B = A^{K1 K2} mod B