Clients often access UTM services via open networks. This can allow unauthorized persons to read data transmitted on the line and pick out passwords for UTM users or read sensitive user data. openUTM supports the encryption of passwords and user data in connections to UPIC clients to prevent this from happening.
For encryption openUTM uses either a combination of RSA methods (named after the authors Rivest, Shamir and Adleman) and AES-CBC (Advanced Encryption Standard Cipher Block Chaining Mode) or DES methods, or a combination of Ephemeral Elliptic Curve Diffie-Hellman methods (ECDHE) and AES-GCM methods (Advanced EncryptionStandard Gallois Counter Mode). The second combination is more state-of-the-art and offers increased security compared to the first combination, but is currently only supported by openUTM for Linux - UNIX -Windows platforms.
The AES key is generated by the UPIC client each time a client-server connection is established.
The RSA key pair is generated by openUTM and consists of a public key and a private key. Several key pairs with different key lengths can be generated in an application. This enables several encryption levels to be implemented.
Use of the RSA-AES-CBC encryption method
Data is encrypted and decrypted in the following steps.
When the connection is established, the public RSA key associated with the generated encryption level is passed to the UPIC client. If no encryption level has been generated (NONE), then the longest currently available RSA key is passed.
The UPIC client generates a connection-specific AES key. This is encrypted using the public key and sent to the UTM application.
Once the UTM application has decrypted the AES key correctly using the RSA key, the client sends the encrypted data.
openUTM decrypts the data using the AES key.
All other data exchanged between client and openUTM on this connection is also encrypted with the AES key.
Use of the ECDHE-RSA-AES-GCM encryption method (only for Linux, Unix and Windows systems)
The combination ECDHE-RSA-AES-GCM uses the elliptic curve based Ephemeral Diffie-Hellman method to agree the AES session key. Each side generates a Diffie-Hellman key pair, transmits the public part of its key pair to the partner and generates the common AES session key from its private key and the public key of the partner. This means that in this procedure the AES session key is not transferred on the data connection.
The server also signs its private key with the private RSA key of the UTM application. In this way, the client can verify that the sent public Diffie-Hellman key of the server really comes from the UTM application. Again, as described above, to prevent man-in-the-middle attacks, it is necessary that the public RSA key is additionally made known to the client in a separate way.
The Ephemeral Diffie-Hellman method offers the user Perfect Forward Secrecy, this means that even recorded data cannot even be decrypted if the Long-Term key (RSA key) is compromised in the future.
The AES-GCM procedure is used to encrypt user data. Compared to AES-CBC, this method has the advantage that it supports Authenticated Encryption with Associated Data (AEAD), in which the encrypted message and the other protocol parts of the message are protected against changes by a Message Authentication Code (MAC).
It is also possible to read out the public RSA key of an UTM application via the administration interface and to have it securely stored locally on the UPIC clients. In this case the client can check when a connection is established whether the public key received matches the locally stored key (to prevent a „man-in-the-middle“ problem).
For security reasons, the RSA key pair of a UTM application should be replaced with a new pair at regular intervals (by means of programmed administration or using WinAdmin/WebAdmin). Administration facilities can be used to activate, deactivate and delete RSA keys. It is therefore possible to distribute a newly generated RSA key to all UPIC clients, to activate it and then to deactivate or delete the old key pair.
Encryption can be used in openUTM to control the access to the system by clients as well as the access to certain services.
System access control
You can specify in the UTM configuration for each client and each group of clients if and to what extent the messages and passwords are to be encrypted. There are three cases in this regard:
The client must always perform encryption, otherwise it will not gain access to the UTM application. Several encryption levels can be defined. The client must perform encryption to at least the requisite encryption level.
The client is allowed access without encryption, but it must encrypt when a service explicitly demands it to encrypt (see below under “Access protection”).
The client is a trusted client and does not need to encrypt.
Access protection
openUTM can protect individual services. A client may only access such services when it is a trusted client or when it can perform encryption to at least the requisite encryption level.
If a client that is not a trusted client wants to access a service with this kind of protection, then it may be required to send an encrypted input message. openUTM sends the output message back in encrypted form even if the client has started the service without an input message or the service was started through service chaining.
| Information on encryption for clients and service can be found in the openUTM manual “Generating Applications” under the keyword ENCRYPTION-LEVEL and in the openUTM manual “Administering Applications” under the keyword KC_ENCRYPT. |
