Form encryption

End-to-end encryption or E2EE is a mode of communication where only the communicating parties can read the messages, while any possible intermediary, malevolent or benevolent, cannot. In Nevis, this is implemented using form encryption.

Security vulnerabilities like the OpenSSL heartbleed bug have shown that mistakes can happen in implementations of the theoretically secure transport layer security (TLS) protocol. Since security vulnerabilities through implementation bugs are likely to occur again, relying on a single implementation increases the probability of falling victim to a future vulnerability. To complicate wide-spread automated attacks, nevisAuth introduced form encryption.

A typical Nevis setup contains a client that connects to the nevisProxy using TLS. nevisProxy terminates the TLS session and opens another session to communicate securely with nevisAuth. Form parameters passing user credentials that are used to authenticate the user are extracted from the HTTP POST body received from the client and forwarded as inargs to nevisAuth. This means that nevisProxy has access to the plain text credentials by the user even though it is not required to process them.

Form encryption has been introduced to avoid that plain text passwords end up in memory or log files of intermediate nodes like nevisProxy. It will not prevent active attacks if TLS has been broken between a client and nevisProxy. Only passive attacks will be prevented because intermediate nodes such as nevisProxy will not be able to log or store plain text credentials.

Overview of involved components

The preceding figure gives an overview of the involved components to enable form encryption. When a request arrives at nevisProxy (1), it will be transformed into a SOAP request and sent to nevisAuth. If the AuthState, which is processing the user data, decides that input is missing, a SOAP response containing a GUI descriptor that instructs nevisLogRend how to render the login form will be created. It is possible to mark a GUI descriptor such that the generated form must be encrypted. This is done through the encryption attribute in the nevisAuth configuration (2). Through it, the encryption algorithm and key size are configured in nevisAuth. If a GUI descriptor is marked for encryption, a public key is appended to the GUI descriptor, and the encryption information is sent back to nevisProxy (3), where it is forwarded to nevisLogRend.

At nevisLogRend, a JavaScript encryption script is appended to the HTML response and the HTML form is constructed such that the script is executed on form submit (4). The previously configured encryption algorithm and keySizes as well as the public key are planted into the script.

When the user submits the form (5), the values of the input text and password fields will be encrypted, using the pre-configured script (note that hidden fields will not be encrypted). The request with the encrypted form parameters is sent to nevisProxy, where it is transformed to a SOAP request and forwarded to nevisAuth. Before nevisAuth executes the current AuthState, the form parameters are decrypted using the associated private key and the configured algorithms (6). The plain text form parameters are then stored with the same name, which means that the integration with any AuthStates is possible without code adaptions.

The form encryption feature works out-of-the-box with nevisLogRend 1.6.3.0 and above if you create a new instance. If you work with an older instance, the integration is possible by adapting the velocity templates and resources. Refer to the nevisLogRend reference guide for further details about form encryption integration.

Encryption mechanism

nevisAuth currently only supports encryption with the key encapsulation mechanism (KEM) using the AES algorithm to encrypt form parameters and RSA public/private keys to encrypt/decrypt the AES key for further decryption of the form parameters on the server side. Figure 12 shows the steps that need to be taken to encrypt and decrypt parameters. The top level shows the functionality on the client side. The JavaScript library delivered through nevisLogRend generates an initialization vector (IV) for the AES algorithm and creates a session key object. The session key object contains the actual key, used for encryption, as well as the encapsulation, which is the key encrypted with the public key that nevisLogRend sent.

The names of the encrypted fields, the IV and the session key encapsulation are then posted to the server. As detailed in the bottom layer of the figure, nevisProxy receives the parameters and forwards them to nevisAuth, where they are used to decrypt the session key and, with it, the encrypted fields.

If form encryption is activated nevisAuth will not accept non-encrypted information sent by the client and the authentication process will fail. Form encryption enforcement allows you to detect possible malfunctions of the encryption code in the rendered page or identify inconsistent configurations.

Limitations

Form encryption is only an additional security measure for hiding user credentials from intermediate nodes. Note, however, that those intermediate nodes must be trusted and that TLS has to be used to secure the transport layer. If the intermediate node is under the control of an attacker, or if the transport layer between client and nevisProxy, nevisProxy and nevisLogRend, or nevisProxy and nevisAuth has been compromised, the response received from the server at the client cannot be trusted. An attacker could remove the onsubmit trigger, by which he can trick the user into sending plain-text credentials. Although in this case, the encryption enforcement makes the authentication fail and detects that there is a problem. Therefore, form encryption is only considered an additional security measure against automated, passive attacks on intermediate nodes.

Even if nevisAuth only accepts encrypted information, a client sending non-encrypted information still poses a threat to the system, as it defies the main purpose of form encryption: Preventing intermediate parties from having access to sensitive data - with all the risks involved (like logging the sensitive information by a compromised intermediate node).

Configuration

An example of a GUI descriptor marked for encryption:

<!-- Userid/Password login -->
<AuthState name="IdmPasswordLogin">
 <ResultCond name="ok" next="IdmPostProcessing"/>
 <ResultCond name="pwChange" next="IdmPasswordChange"/>
 <ResultCond name="lockWarn" next="IdmPasswordLogin" />
 <ResultCond name="nowLocked" next="IdmPasswordLogin" />
 <ResultCond name="locked" next="IdmPasswordLogin" />
 <ResultCond name="tmpLocked" next="IdmPasswordLogin" />
 <ResultCond name="failed" next="IdmPasswordLogin" />
 <ResultCond name="clientNotFound" next="IdmPasswordLogin"/>
 <ResultCond name="default" next="IdmPasswordLogin"/>
 <Response value="AUTH_CONTINUE">
 <Gui name="AuthUidPwDialog" label="login.label" encryption=" RSA-2048{AES-128-CBC}">
 <GuiElem name="lasterror" type="error" label="${notes.lasterrorinfo}" value="${notes.lasterror}"/>
 <GuiElem name="isiwebuserid" type="text" label="userid.label" value="${notes:loginid}"/>
 <GuiElem name="isiwebpasswd" type="pw-text" label="password.label"/>
 <GuiElem name="submit" type="submit" label="uidpw.button.label" value="Login"/>
 </Gui>
 </Response>
 <property name="login.service.connection.1" value="local" />
 <property name="admin.service.connection.1" value="local" />
 <property name="ticket" value="false"/>
 <property name="detaillevel.user" value="HIGH" />
</AuthState>

The encryption attribute consists of the following parts:

<public-private-key-enc-algorithm>-<public-private-key-enc-keysize>{<session-key-enc-algorithm><session-key-keysize>-<session-key-algorithm-mode>}

The following describes the encryption and decryption attribute parts:

Part	Description
public-private-key-enc-algorithm	default: -The algorithm for public/private key encryption. This algorithm is used to encrypt and encapsulate the session key.
public-private-key-enc-keysize	default: 1024The keysize of the key that is used to encrypt the session key.
session-key-enc-algorithm	default: AESThe algorithm for symmetric encryption. This algorithm is used to encrypt the actual data. The key will be generated on the client side and encapsulated using the public key sent from nevisAuth.
session-key-keysize	default: 128The keysize of the key used for symmetric encryption.
session-key-algorithm-mode	default: CBCThe algorithm mode for symmetric encryption.

At the moment, only RSA and AES-CBC are tested.