17 4 7 Encrypting the Job Queue Details

You are here:

17.4.7 Encrypting the Job Queue Details

To switch this feature on it's a simple matter of starting the Job Queue with the parameter QENC=Y. Once its started you submit jobs exactly the same way as when encryption is not being used.

Disclaimer
LANSA does not warrant the effectiveness or otherwise of any of the cipher algorithms in the Open SSL library. You should perform your own due diligence before using any part of LANSA which makes use of the ciphers. A suggested starting place is the book Network Security with Open SSL by John Viega et al, published by O'Reilly. The ciphers made available by LANSA are as follows:
AES 256, Blowfish 128, CAST5 128, DES 64, DESX 192, Triple DES 2 Key, Triple DES 3 Key, IDEA, RC2(TM) and RC4(TM). There may also be patents current for some of these ciphers. It is up to you to ensure their usage does not contravene any patents. LANSA accepts no responsibility whatsoever for any contravention of patents.

Technical Details

Firstly, the only symmetric encryption algorithm currently supported is AES 256 using CBC mode (Cipher Block Chaining) and an Initalization Vector (IV) also known as a 'seed'. Other ciphers may be used but they are not currently supported by LANSA and have not been tested. You use them at your own risk. There is an x_run parameter CIPH which is passed directly to the Open SSL API EVP_get_cipherbyname. Refer to the Open SSL documentation for further details.

The public key must be RSA because it is the only OpenSSL public key algorithm that supports key transport. LANSA uses 2048 bit modulus with RSA_F4 and Blinding ON (stops timing attacks).

Envelope encryption is the usual method of using public key encryption on large amounts of data, this is because public key encryption is slow but symmetric encryption is fast. So symmetric encryption is used for bulk encryption and the small random symmetric key used is transferred using public key encryption.

The Private Key is kept in the memory of the Job Queue Monitor. Thus there is no security issue except that you can debug the process, hence the right to debug should be revoked.

The Public key, of course, is available to all users and is written out to a file in the job queue directory.

A new key pair is produced every time the Job Queue is started.

Each job has a new seed. This seed is essential as the data is very similar for each job queue file. The Open SSL crypto API default behaviour is to provide a random seed.

Only the job queue monitor determines whether encryption is being used or not. If it is on, the key pair is created and the public key written out to a DER binary format file. Clients check for the existence of this public key file. If it exists, the client produces a random seed (IV) which is used to produce a unique symmetic key (Session Key) which is encrypted with the public key. The Session Key is then used to encrypt the job queue data. The IV, the encrypted Session Key and Encrypted job queue data, are written out to the job queue file. The structure of the encrypted job queue file follows:

Structure of the Job Queue file:
<IV length><IV><Session Key length><Encrypted Session Key><encrypted data length><encrypted data>

The RSA public key is named after the symmetric cipher lookup string, for example, aes-256-cbc.der. Thus the name of the file can be used to look up the symmetric cipher. Note that this may be confusing as this file contains the RSA asymmetric key, not the symmetric key.

When the Job Queue Monitor starts up, it firsts deletes all existing .der files and all existing job details before generating the Key Pair and outputting the new public key.

Responsibilities:

	Job Queue Monitor
		1. Generate key pair. 2. Output public key to <named symmetric cipher>.der e.g. aes-256-cbc.der. 6. Read the data file. 7. Decrypt using in-memory private key (RSA asymmetric cipher) and clients Session Key (named symmetric cipher).
	Client
		3. Read public key (RSA). 4. Generate Session Key for use with named symmetric cipher provided by server. 5. Create the data file, encrypting with appropriate keys.

X_RUN Parameters:

CIPH - Cipher Name defaults to aes-256-cbc. case sensitive as it's passed as-is through to the OpenSSL library. This parameter is also available with the Built-In Functions GET_SESSION_VALUE and SET_SESSION.

QENC - Use encryption with Job Q Monitor. (This is ignored by submitters of jobs to Job Queue)

If a job is submitted to an encrypted job queue, it can only be executed by that INSTANCE of the job queue Monitor. Once the Job Queue monitor is stopped and restarted, a new private key is generated which will not be able to decrypt the existing batch jobs. Clients do not need to be restarted, but neither can they submit any jobs until the Job Queue Monitor is running and has generated the Public Key.

@@@ here