Encryption

(As of 4.30)

Encryption encompasses a number of different operations. These operations can be used independently or in combination to meet different needs. We use industry standard encryption available through OpenSSL. Three technologies are widely used for encrypting data. BR supports the first two listed below through its ENCRYPT and DECRYPT functions.

Overview

1. Symmetric key ciphers – where the same key is used to encrypt and decrypt data. You can specify a key to encrypt some data and later use the same key to decrypt the data.

2. Hashing routines – one way routines that take data and convert it to a hash value. Sometimes these are thought of as checksums such as MD5 sum. Hash values are always the same length regardless of how big the hashed data is. A 10 gb file will have a hash result that is the same length as a 200 byte file. Hashing routines have a number of specific uses:

• Verify that data has not changed.
• Verifying that two files are the same.
• Validating passwords – this is based on the concept that if two values have the same hash value the values are equal. Using this technique improves security because it allows a server to store passwords in an unrecoverable format. Even the server software is unable to regenerate the original password. It is only capable of checking if the hash of a password matches the stored password hash.

Interfacing With Other Programs (encryption type and initialization vector)

There are a number of different types of encryption that BR supports through OpenSSL: AES, BLOWFISH, DES, triple DES, RC4 and RC2. Most symmetric key ciphers are block ciphers meaning that they encrypt one block at a time. This means if you have a bit message, it is broken up into multiple blocks and each block is encrypted. The block size can be set as (128, 192, 256) bits. Some encryption types don't support all of these values so STATUS ENCRYPTION should be checked to see what encryption types are available in BR. Besides block size, there are also various schemes for blocking data. One might expect that using 256 bit blocking would simply take every 32 bytes and call it a block. This is not done though because there is a possibility that this would cause patterns in the encrypted data. To prevent this, there are various schemes known as codebooks which change the way data is blocked. Wikipedia explains this in more detail. If the encryption type is not specified AES:256:CBC:128 will be used. To be compatible with other programs the entire encryption type must be specified (cipher: key length: codebook: invitialization vector length).

Initialization-vector – this is used to cause the same data encrypted with the same key to have a different encrypted result. This is significant because otherwise an attacker looking at data seeing the same encrypted result twice would know that the key and the unencrypted data have not changed. Regardless of whether or not you are concerned about this potential security issue, the standard encryption methods require this value so interfacing with other programs may require you to use it. It is a common practice to use a random number for this value and store the value at the beginning of (ahead of) the encrypted result. This is what BR does if this parameter is omitted.

As an example:

ENCRYPT$(“test”, “key”) 

Produces a string containing “random number initialization vector”&”encrypted result”.

If the initialization vector is explicitly specified as in: ENCRYPT$(“test”, “key”, “AES:256:CBC:128”, “RANDOM”) the result would be simply “encrypted result”.

DECRYPT$ has the same arguments as ENCRYPT$ with the exception of the first parameter which is the encrypted data. DECRYPT$ expects to be used with the same key$, encryption-type$, and initialization-vector$ as was used to encrypt the data. As with ENCRYPT$, if key$ is not specified, the value from the OPTION statement will be used. If encryption-type$ is not specified, “AES:256:CBC:128” will be used. If the initialization vector is not specified, it will be assumed that the encrypted data starts with an initialization vector.

Hashing Routines

Three common forms of hashing are allowed in BR. They are MD5, SHA, and SHA-1. These are also provided through the ENCRYPT$ function specifying a null key$ value:

ENCRYPT$(data$, “”, “MD5”) ENCRYPT$(data$, “”, “SHA”) ENCRYPT$(data$, “”, “SHA-1”)

Hashing is also referred to as Message Digests or digests. This is what the MD in MD5 means. There is no way to restore data that has been hashed. Hashing is a one way function so DECRYPT$ will yield an error.

Asymmetric Encryption

Asymmetric key encryption is also known as public/private key encryption.

Public/private keys are created as a pair by a key generator. They are a pair, and it is not possible to have two public keys for the same private key or vice versa. With regard to public/private key pairs, what one key encrypts the other key can decrypt, and neither key can decrypt what it has encrypted. When a private key is used to encrypt data, the result is called a signature because everyone who has the public key can decrypt it.

This technique is used for:

Signing (using certificates) – A private key can be used to sign data. The result of such signing can be tested/validated with the corresponding public key.

Data encryption – A public key can be used to encrypt data. This data can then only be decrypted by the corresponding private key.

Hashes and signing are different but used together. Rather than signing a large block of data which would create a large signature, only the hash is signed to create much smaller fixed length signature data. When verifying a large block of signed data, the data is used to create a hash value and the hash value is compared to a decrypted signature.

Asymmetric encryption is not accessible through the BR ENCRYPT$, DECRYPT$ functions. However, it is used by our SSL client server connections and HTTPS. Certificates are most commonly used by SSL and HTTPS and are less useful for other application processes. In the Client Server model the client knows the server’s public key and the server uses its private key to encrypt and decrypt.

Encryption is invoked by Business Rules HTTP support as follows:

CONFIG HTTPS PORT port-number   [ LOG file-pathname ]
CONFIG OPTION  66   private-key-file-encryption-password
OPEN #400: “HTTP=SERVER”, DISPLAY, OUTIN

The BRSERVER executable directory must contain two files:

https-private.pem
https-cert.pem

These files are made by the following commands under Linux, MAC and cygwin for Windows: openssl req -new -x509 -out httpserver.pem -days 10000

(this will prompt for the OPTION 66 password)

mv privkey.pem   https-private.pem
mv httpserver.pem   https-cert.pem

This port specific service can then be accessed with browsers. When the specified port is accessed through a browser, BR establishes an HTTPS connection rather than an HTTP connection.