Clients access unencrypted UTM services. There is, therefore, the possibility that unauthorized persons on the line can monitor and, for example, discover passwords for UTM user IDs or sensitive user data (man-in-the-middle attack). In order to avoid this, openUTM supports the encryption of passwords and user data for client connections.
Encryption in openUTM can be used to control access from clients and also access to certain services.
openUTM uses a hybrid encryption scheme. this is a combination of an asymmetric encryption for the exchange of the AES key and symmetric encryption with an AES key for the data.
How to enable encryption see section Runtime environment, linking, starting
Encryption methods
The encryption of user data for connections to UTM applications always follows the same pattern: First, a session key is exchanged or agreed between the two partners, and the user data is then encrypted with this session key between the two partners.
The session key used in all encryption levels is an AES key with a length of 128 bits.
For Encryption Levels 3 and 4, the session key is exchanged with the RSA algorithm. The client encrypts the created AES key with the public RSA key of the UTM application. Depending on the encryption level, an RSA key with a length of 1024 or 2048 bits is used.
At Encryption Level 5, the agreement of the AES key is done using the Elliptic Curve Diffie Hellman method. The RSA key of the UTM application is used in this method only to sign the public Diffie-Hellman key of the UTM application to prove the origin of the Diffie-Hellman key. The Diffie-Hellman method has the advantage that the AES key does not need to be transferred from the client to the server. Thus, this method offers Perfect Forward Secrecy.
Encryption levels 3 and 4 use the AES-CBC procedure to encrypt the user data. Encryption Level 5 uses the newer AES/GCM process. AES/GCM offers the advantage that in addition to the encryption of the user data, further protocol parts of the message are protected against changes by a message authentication code (MAC).
Configured encryption level | Public key | Symmetric key | authenticated encryption | perfect forward secrecy |
| TRUSTED | No key | No key | no | no |
| NONE | Depending on situation | Depending on situation | Depending on situation | Depending on situation |
| 3 | RSA - 1024 bit | AES (128 bit) | nein | nein |
| 4 | RSA - 2048 bit | AES (128 bit) | nein | nein |
| 5 | ECDH secp256k1 | AES (128 bit) | ja | ja |
Table 6: Configured encryption levels and associated keys
In openUTM each RSA key pair can be modified and activated using administration facilities. Only activated RSA keys are used. For encryption levels 3 and 4 the UPIC client can store the public key locally in advance. When a connection is set up, the public key received is checked against the stored public key.
The active RSA key can be read out and can be deleted by using calls of the UTM administration interface or by using the openUTM WinAdmin administration tool.
Requirements
If an encryption level of 3 to 5 is generated for the partner in openUTM but the encryption requirements have not been satisfied, no connection is set up. This may be for one of the following reasons.
The client does not support encryption because of the encryption functionality is not available.
Procedure
When the client attempts to connect to the UTM application, it informs openUTM whether it supports encryption.
Once the connection between the client and the server has been established and if encryption is supported by both partners, the client sends information to the server indicating the level up to which it supports encryption. The server compares this with the configured information for the partner.
Depending on the encryption level the client generates in the UTM apllication, various situations can occur.
ENCRYPTION-LEVEL=TRUSTED
The client is configured as trusted. In this case openUTM does not request encryption. Neither can the client force encryption.
ENCRYPTION-LEVEL=NONE
In this case the UTM application sends the RSA key with maximum modulo length to the client. The RSA key determines the encryption level.
The client generates an AES key. The client encrypts the AES key with the RSA key and returns it to the server. openUTM stores the key for later use on this connection.
By default only passwords are encrypted.
However, the client can enforce encryption of user data by using the ENCRYPTION_LEVEL keyword in the upicfile or by means of the Set_Conversation_Encryption_Level call.
Notes
If the software requirements for encryption are not met, passwords and user data are exchanged without encryption.
ENCRYPTION-LEVEL= 3 or 4
The UTM server sends the public RSA key associated with the appropriate encryption level. The length of this key is 1024 or 2048, see table6 Encryption.
The client generates an AES key, encrypts it with the RSA key and sends it back to the server. openUTM stores the AES key for later use on this connection.
Passwords and user data are encrypted.
The Set_Conversation_Encryption_Level call or an ENCRYPTION_LEVEL entry in the upicfile has no effect.
ENCRYPTION-LEVEL= 5
The UPIC client and the UTM application agree on a common secret with the ECDH procedure.
The client generates an AES key, encrypts it with the shared secret, and sends it back to the UTM application. openUTM saves the AES key for later use on this connection.
Passwords and user data are encrypted.
The Set_Conversation_Encryption_Level call or an ENCRYPTION_LEVEL entry in the upicfile has no effect.
The client-level encryption level of the conversation can be read out using the Extract_Conversation_Encryption_Level call, preferrably after the Allocate call.
Encryption with protected TAC
A service of a UTM application can be protected by assigning an encryption level to the associated TAC in the ENCRYPTION-LEVEL=tac-level operand at generation. This ensures that a client cannot call the protected service unless data is transferred with the specified encryption. The following situations can occur depending on the generation of the client and on the encryption level of the TAC.
TRUSTED is generated for the client
openUTM does not request encryption and the client can also start protected services. The client cannot force encryption because no keys were exchanged.
NONE is generated for the client
openUTM does not request encryption. If a client-level encryption level > 0 was established at connection setup and if a conversation whose TAC requires level 2 or level 5 encryption is initialized, there are the following possibilities.
client-level >= tac-level
where the client has activated encryption for this conversation.
The service can be started. The client sends user data in an encrypted form right from the beginning.client-level >= tac-level
where the client has not activated encryption for this conversation and has not yet sent any user data.
The service can be started. The UTM application transmits all output on the client-level encryption level to the client in an encrypted form. The client also encrypts all subsequent messages to openUTM on the client-level encryption level.client-level < tac-level
The UPIC client has already sent user data that was either not encrypted or was encrypted with a lower encryption level.openUTM ends the conversation.
3 ,4 or 5 is generated for the client
If a conversation whose TAC requires level 2 or level 5 encryption (tac-level) is initialized, there are the following possibilities.
client-level >= tac-level
The service can be started.client-level < tac-level
The service cannot be started and openUTM terminates the conversation.