The cryptographic functions ENCRYPT and DECRYPT of SESAM/SQL enable you to encrypt and decrypt the sensitive data of a database.
Sensitive data is protected against unauthorized access by encryption. Only the users who know the “key” can decrypt the data. The sensitive data of a database which is operated in a insecure environment can also be protected in this way.
SESAM/SQL uses the Advanced Encryption Standard (AES) of Rijndael with a 128-bit (16byte) key in Electronic Codebook Mode (ECM). General information on the AES is available on the internet at: http://csrc.nist.gov/
Detailed information on the cryptographic functions of SESAM/SQL is provided in the “ SQL Reference Manual Part 1: SQL Statements”.
Key management
The security of encrypted data depends mainly on the security of the keys used. Keys must be redundant and stored at different places, if necessary also on different media. Their storage strategy is part of the security policy.
The AES uses the same key for encryption and decryption (symmetric encryption method). If the key is known, sensitive data can be decrypted directly because only the key is secret, but not the encryption method. The key cannot, however, be changed any number of times as all the encrypted data would have to be decrypted and encrypted again using the new key.
When the key is lost, encrypted data can no longer be decrypted. For security reasons, SESAM/SQL leaves no internal trace of the key or of unencrypted values.
For security reasons, it may be necessary to save “old” keys to read encrypted data from backup copies.
Saving encrypted data
Encrypted data is only saved in its encrypted form in SESAM/SQL. This applies not only for the spaces of the database but also for the indexes, the logging files (DA-LOG, TA-LOG, WA-LOG) and the temporary files of the utility functions.
CAUTION!
However, in the main memory of the DBH and of the client applications both the unencrypted data and the key are still (after ENCRYPT or DECRYPT has been used) visible in plain text. Dumps of such areas contain confidential data and must be treated with particular care.
After the DBH and the client applications have terminated, the main memory areas can no longer be accessed. Dumps and cursor files (see "Cursor files for retrieval statements", SES*.CURSOR.* file names) should be deleted not just logically but also physically (e.g. using the BS2000 command DELETE-FILE ...,OPTION = *DESTROY-ALL).
In the BS2000 user ID in which the DBH is running it can happen (e.g. because of administration intervention) that files (e.g. CO-LOG file, traces, dumps) are created which may contain keys or the encrypted data in decrypted form. Consequently this BS2000 user ID and also the administration access to the DBH should also be protected.
Other analysis tools can also make keys and data visible in plain text and store them. Particular notice should be taken of these. For analysis purposes you can create a log of the SQL statements and their user variables using the SESCOSP utility routine, see the “ Database Operation” manual.
NULL values
NULL values become NULL values again when they are encrypted.
Privileges and encryption
Privileges permit access to tables, to columns and (via views) to rows of a table, see section “Access protection based on privileges in SQL”. They also define what operations (e.g. INSERT) are permissible on these objects. Privileges have a greater functional scope than encryption, but they do not cover all security aspects.
The encryption of sensitive data complements the privileges, e.g. in the following cases:
Privileges can permit access to sensitive data.
Particular roles (e.g. the universal user or the owner of a table) have all the privileges for an object.
However, encryption only permits such users to decrypt sensitive data if they also know the key.
ENCRYPT() enables individual columns of a table or even individual values to be protected against unauthorized access.Privileges control access in the SQL system only.
They do not prevent access using other means (e.g. the BS2000 command SHOW-FILE). Encryption, on the other hand, prevents unauthorized reading using any other means.Privileges apply for all SQL statements of a transaction.
When encryption is implemented using different keys, sensitive data with different security requirements can also be encrypted differently, even within one and the same transaction.In the case of privileges users identify themselves by the application which was used or by the access to the operating system which was used. SESAM/SQL can, for example, not distinguish between two users with the same access. In the case of encryption they can, however, differentiate because of their knowledge of the keys.