Patent Description:
<CIT> discloses a transparent encryption infrastructure which allows a user to point-and-click on columns and tables to encrypt data. The creation of triggers and views are also easily implemented, to encrypt and decrypt data, to manage the encryption keys and to grant and revoke access to a column. Public and private key pairs are hashed and encrypted with a valid password. The process or encryption starts by creating a randomly generated symmetrical key, encrypting the symmetrical key with the private key for each user authorized to decrypt the data, and storing the encrypted symmetrical key, along with the user's name and the column name, in the database.

<CIT> discloses a system, method, and computer-readable medium that facilitate key rotation without disrupting database access are provided. Generation identifiers that specify a particular encryption key are stored in association with cipher text of encrypted columns in database tables. When data is to be read from an encrypted column, the cipher text is read along with the associated generation identifier. An encryption key corresponding to the generation identifier is then read to decrypt the cipher text. When data is to be written to the encrypted column, a most recent encryption key is retrieved from the key repository to encrypt the data. The cipher text is then written to the encrypted column in association with the generation identifier of the key used to encrypt the data.

<NPL>, discloses a Format Preserving Encryption method by accumulating with Advance encryption standard (AES), eXclusive OR operation and a translation method for <NUM> digit numeric data.

It is an object of embodiments of the invention to protect personally identifiable information and other sensitive information stored in a database server system and/or communicated to/from a database server system. This can improve security, improve protection of personal information, aid complying with privacy regulations, reduce the risk of data leak, and facilitate that data can be used for more purposes than otherwise.

In a first aspect the invention provides a database server system for computer-implemented communication of electronic data between a computer-readable storage medium for storing such data and a computer-implemented application for performing at least one of create, read, update and delete operations to the data, wherein the data are structured in a first table of rows and columns defining a plurality of data cells, wherein the database server system is configured to:
receive read requests from users of the application to return, from the database server system to the application, data in at least one of the data cells, and perform a format-preserving encryption or decryption operation to the data in the at least one of the data cells prior to returning the data to the application, wherein the database server system is configured to carry out the format-preserving encryption and/or decryption operation in accordance with user rights governing if in respect of which data such encryption and/or decryption operation is permitted, wherein the database server system returns the data in decrypted form to users which are allowed to access data in decrypted form and returns the data in encrypted form to users which are allowed to access data in encrypted form.

Format-preserving encryption is to be understood in the present contest as a procedure encompassing an encryption algorithm constructed such that it can encrypt information of a certain type (e.g. an e-mail address) in such a way that the encrypted version respects the format of the certain type.

When applying "classical" encryption, in which the format of the data is not preserved, the encrypted data are typically binary, and will take up more storage space than the original data. Thereby tables, etc., need to be redesigned in order to accommodate the encrypted data. However, when applying format-preserving encryption, the original format is preserved, thereby allowing the encrypted data to be easily stored in a database, without requiring redesign of tables, etc., and without requiring additional storage space.

Furthermore, applying format-preserving encryption allows a number of operations to be performed to the data in encrypted form, thereby reducing the need for decryption of the data, because an application which performs such operations receives the data in the correct format, and the operations can therefore be performed on the encrypted data in the same manner as if the data had been decrypted. This increases performance as well as security. Finally, applying format-preserving encryption reduces the risk of erroneous handling of the data. For instance, in the case that a given user is not authorized to receive data in a decrypted form, then the data can simply be returned to the user in encrypted form, and the user will still be able to verify that the data are in a correct format, handle error messages, perform operation on the data as described above, etc., without decrypting the data.

The format-preserving encryption or decryption operation may preferably be a bijective operation, i.e. an operation which is injective (one-to-one) as well as surjective (onto). In this case, for each decrypted data record there exists one and only one encrypted data record, and for each encrypted data record there exists one and only one decrypted data record. Accordingly, an inverse function exists, and it is possible to uniquely restore the original data from the encrypted version of the data.

In one embodiment of the present invention, the database server system is a relational database server.

In one embodiment of the present invention, the database server system is one of:.

In one embodiment of the present invention, the format-preserving encryption engine is one of:.

In one embodiment of the present invention, the format-preserving encryption engine is designed such that the length of the encrypted version of an object is different from the length of the original object. This improves the security of the system, since it is not possible to derive the length of the original data from the encrypted version of the data.

In one embodiment of the present invention, the view providing access to encrypted and/or decrypted data is defined on one database whereas the table storing the actual data is stored on another database.

According to this embodiment, users and applications with access rights which allow access to the actual data, can be granted access to the database where the table storing the actual data is stored, whereas users and applications without such access rights are not granted access to this database, and may instead be granted access to the encrypted version of the data. This improves the security of the system, since it can be efficiently ensured that an unauthorized user or application does not gain access to the decrypted data. However, it is not ruled out that a user or application which is allowed to access the actual data opts to only access to the encrypted version of the data, in the case that a given task does not require the actual data, but can instead be performed on the encrypted version of the data.

In one embodiment of the present invention, users and/or their group membership or authorizations are queried from a user access/rights management system and/or a directory service system, such as Active Directory or LDAP. Active Directory and LDAP are examples of central systems for handling user and user rights. Thus, according to this embodiment, a centralized handling of users and corresponding user rights is provided.

The database server system according to the invention may comprise a format-preserving encryption and decryption engine for performing the format-preserving encryption of the data.

The system may be further configured to manage encryption keys and/or user rights. According to this embodiment, encryption keys and/or user rights are managed at the system, i.e. locally, instead of via a central system. This provides a simple setup.

The read operation may be implemented through an SQL view, and/or create, update and delete operations may be implemented through an SQL Trigger.

According to this embodiment, existing software or application may access the data without realizing that a security layer has been added, i.e. the security layer can be added in a manner which is transparent to users or applications needing to access the data.

The SQL Trigger may comprise one or more SQL Triggers, and at least one of the create, the update and the delete operations may be implemented through the one or more SQL Triggers. This also allows the security layer to be added in a manner which is transparent to users or applications needing to access the data, similarly to the embodiment described above.

The first table may be identified in the database server system by a first name, and the database server system may be configured to perform the following steps prior to receiving the read request and/or the create or update request from the application:.

According to this embodiment, the procedure can be implemented on an existing database, which is already being used by one or more applications, in a manner which ensures that the previous applications continue to be operational, without requiring that the previous applications are constructed or designed to support the protection provided by the procedure defined by the present invention, and without requiring changes to the existing programming code.

The database server system may be configured to perform at least one of the create, the update and the delete operation through the one or more SQL Triggers.

The data may be stored in an encrypted version in the computer-readable storage medium, and the database system may be configured to:.

According to this embodiment, the data can be protected while "at rest", i.e. while it is stored in the database. However, the data is still available in decrypted form in real time, or nearly in real time, to authorized users and applications.

A first subset of the data cells may include non-encrypted data, and a second subset of the data cells may include encrypted data. The database server system may further include one or more identifiers for identifying the first and/or the second subset of the data cells.

This embodiment is particularly relevant in the case that data needs to be migrated from non-encrypted form to encrypted form. According to this embodiment, it is possible to encrypt data while the system is in use. The encryption operation is performed on the data, one line at the time. During this, the system remains able to respond to queries, since it "knows" which data have already been encrypted, and therefore require decryption, and which data have not yet been subjected it initial encryption, and therefore does not required decryption.

The database may comprise a plurality of first rows including non-encrypted and a plurality of second rows including encrypted data, and the database may further include, in respect of each of the first and second rows of data, an identifier specifying whether or not the data in each respective row is encrypted.

This embodiment may be regarded as a specific implementation of the embodiment described above.

The database may comprise a plurality of rows of data including encrypted data, and the database may further include, in respect of each row of data, an encryption key identifier for identifying an encryption key used for encryption of the encrypted data in each respective row.

According to this embodiment, the same encryption key may not necessarily be applied to all of the data records. Instead, the applied encryption key may differ from one data record to another, or from one group of data to another. This further allows easy switch or updating of encryption keys, e.g. in the following manner. At a given point in time, a new encryption key is put into use for data which is created or updated from that point in time onwards. Furthermore, and in parallel herewith, re-encryption of the data stored in the database is performed, row by row. This could, e.g., be done only at time periods with low load or activity in order to minimize the impact on performance of the system. Thereby it is possible to read the data at any time, regardless of whether or not a requested data record has been migrated to the new encryption key.

The data may be stored in a decrypted version in the computer-readable storage medium, and the database system may be configured to:.

According to this embodiment, the data may be stored in decrypted form, but certain users or applications will only receive the data in encrypted form. Companies or organizations using database server systems may have several database environments, including a production environment and a test or development environment. However, the system according to this embodiment allows tests to be performed directly in a production environment, due to the provide real time protection provided, i.e. a dedicated test or development environment is not necessarily required. This allows for a cheaper and simpler setup.

The database server system according to the invention may be further configured to receive configuration data, user rights data, and/or cryptographic keys from an external computer-implemented system for management of the configuration data, user rights data, and/or the cryptographic keys.

This allows for central control of configuration and management of access rights, thereby providing easy control and homogeneous protection of the data.

The database server system according to the invention may be further configured to carry out the format-preserving encryption and/or decryption operation in accordance with user rights governing if and/or in respect of which data such encryption and/or decryption operation is permitted.

According to this embodiment, access to the encrypted/decrypted data is controlled in accordance with specified access rights, as described above.

Data in a first one of the cells of data may be used as a tweak for the format-preserving encryption and/or decryption of data in a second one of the cells.

According to this embodiment, a significant increase in security can be obtained, because data contained in one field is taken into consideration when encrypting data in another field. This makes it more difficult to "guess" true data values from statistic analysis of the encrypted data For instance, if a column of the database contains postal codes, and it is not relevant to compare data based on postal codes, the format-preserving encryption and/or decryption may be performed based on a tweak taking data contained in another column into consideration. In this case the encryption of a given postal code may result in different encrypted versions. Thereby a malicious party gaining access to the encrypted data will not be able to derive or guess the true postal codes, e.g. by statistically processing the encrypted postal codes and compare this to actual postal codes.

The database server system may further comprise a second table storing a modified version of the data in the first table, wherein:.

and wherein the database server system is configured to return, in response to a read request from the specific user, a merged version of the data in the first and second tables.

According to this embodiment, encryption or decryption may be perform in advance, i.e. before the data is requested. Thereby processing power or CPU cycles runtime is not required when the data is requested, and performance of the system can be improved, and latency can be reduced. For instance, at least part of the data, e.g. the most frequently requested data and/or the least sensitive data, may be stored in an encrypted version as well as in a decrypted version.

In one embodiment of the present invention, the encryption engine installed in a database may cooperate with other software components such that other software components can encrypt data to be written to the database such that it can be written directly to the table holding data and/or read data in encrypted form and then decrypt it itself.

According to this embodiment, the data may be encrypted in advance, e.g. by the application which receives the data, rather than when being entered in the database.

In one embodiment of the present invention, different policies are defined. Each policy may for example govern one or more types of content. The policy may.

According to this embodiment, central control and management is provided, thereby allowing for consistent configuration, efficient control and the ability to maintain a central overview of the system, the users and the data. This is particularly relevant in the case that data needs to be compared across several systems, because in this case consistent protection of the data is required, in order to maintain a high security level, as well as in order to ensure correct use and comparison of the data. For instance, if different encryption keys have been applied in different systems, then it may not be possible to compare the data originating from different systems.

In case other software components also can encrypt/decrypt data, the policies may be shared with such components. This would allow the different software components to cooperate and individually encrypt/decrypt data in a manner that is compatible between the software components.

In one embodiment of the present invention, a database server has an ingestion table for temporarily storing recently received input data and primary table for long-term storage and for performing queries on data.

According to this embodiment, encryption of data may be decoupled from receipt of data. Thereby data may be received fast, and an acknowledgement of receipt can be generated immediately. Encryption and storage of the data in the database may then be performed independently of the receiving step.

In a third aspect, the invention provides a computer system comprising:.

The data security management system may be connectable to the database server system so as to enable at least one of:.

In a fourth aspect, the invention provides a computer system comprising:.

In a fifth aspect, the invention provides a data security management system for management of the configuration data, user rights data, and/or the cryptographic keys in a computer system according to the third aspect of the invention.

Embodiments of the invention will now be further described with reference to the accompanying drawings, wherein:.

<FIG> shows how data stored can be read when stored in a database where selected cells are stored in encrypted form using format-preserving encryption.

The SQL select statement executed against the database hits a view (this may be unknown to the user/application using the database; they may believe that they are performing the query directly against a table). The view is constructed such that the encrypted cells are decrypted using format-preserving encryption before the result sent back as result to the SQL select statement.

The view may be constructed such that it verifies the identity of the entity performing the query and determines if that entity is entitled to receive data in decrypted form. If the entity is not entitled to receive data in decrypted form, data may be returned in encrypted form, the cells otherwise holding encrypted data may be returned as empty, or an error may be triggered.

For some applications, it this process may be reversed such that data is stored in non-encrypted form but is encrypted before being returned as result to the select statement.

<FIG> shows how data can be encrypted before being stored in a database where selected cells are stored in encrypted form using format-preserving encryption.

The SQL insert statement executed against the database hits a view. This view has a trigger defined which is activated by the insert statement. This trigger is constructed such that the relevant cells are encrypted using format-preserving encryption before being stored in the actual table.

The trigger may be constructed such that it verifies the identity of the entity performing the query and determines if that entity is entitled to write data in encrypted form. If the entity is not entitled to write data in encrypted form, data may be written in non-encrypted form (information indicating that the given cell is not encrypted may be appended to the data stored in the cell, stored in another cell, stored in another table, or kept elsewhere), or an error may be triggered.

<FIG> shows how data can be encrypted during an update operation.

<FIG> illustrates an example of how rows can be encrypted under different keys and how it can be identified if a row is encrypted or not. In the example, the "Key" column indicates if a given row is encrypted (a non-NULL value means that the row is encrypted, the NULL value indicates that the row is not encrypted). If the row is encrypted, the "Key" column identifies that key to use for decrypting the encrypted cells of the row. It is furthermore illustrated how a user without decryption permission gets an unaltered copy of the encrypted data whereas a user with decryption permission gets a decrypted copy of the encrypted data. The example furthermore illustrates how different encryption keys will result in differently encrypted data. In the example, all rows in decrypted form contains the same values column-by-column, whereas they contain different values column-by-column since they are encrypted using different keys (and one row is not encrypted at all).

<FIG> illustrates how data can be stored in both encrypted and decrypted form. Depending on the user's permissions, either the encrypted or the decrypted version of the data is returned. The functionality of <FIG> can also be implemented by other means, such as for example by storing the encrypted data in one table and the decrypted data in another table.

If data is stored in both encrypted and decrypted form (in same table, in different tables, or otherwise), then appropriate functionality/logic may be applied (e.g. via SQL Triggers) to ensure that eventual updates to data in either form is applied appropriately to the other. For example: If a record is updated in decrypted form, then the data should be encrypted such that the encrypted form is also updated. In this way, it can be assured that encrypted and decrypted data are kept in sync.

<FIG> illustrates how encryption can be deployed on an existing database already used by a user or an application. Before encryption is deployed the user or application accesses a table directly. In order to deploy encryption, the following steps are carried out:.

Hereby, the user or application can operate exactly as before the encryption was deployed, but now with the security features offered by the encryption. This may be combined with the techniques illustrated in <FIG> in order to allow for the encryption process of step <NUM> to be performed at a later point of time (eventually multiple steps each processing a portion of the data) and/or in parallel with the user or application's access to the data without interfering with the application.

<FIG> illustrates how to manage, monitor, and configure encryption of data in a database. The Data Security Management System is operated by an operator (e.g. via a browser). The Data Security Management System interacts with the Database in order to perform one or more of the following operations:.

The server labelled "Application using Database" symbolized an application accessing data on the database. This application typically accesses the database under a user account to which the application's rights are linked. A human user may access the database in place of the application.

The database may for example store encryption keys itself (for example in encrypted form), retrieve keys from a Key Vault and/or from the Data Security Management System. If the database stores keys itself in encrypted form, then the master key used to decrypt the keys may be retrieved from a Key Vault or from the Data Security Management System.

User credentials, access rights, group membership, etc. may be handled by a user access/rights management system or a directory service system such as Active Directory or LDAP.

Claim 1:
A database server system for computer-implemented communication of electronic data between a computer-readable storage medium for storing such data and a computer-implemented application for performing at least one of create, read, update and delete operations to the data, wherein the data are structured in a first table of rows and columns defining a plurality of data cells, wherein the database server system is configured to:
- receive read requests from users of the application to return, from the database server system to the application, data in at least one of the data cells, and perform a format-preserving encryption or decryption operation to the data in the at least one of the data cells prior to returning the data to the application,
wherein the database server system is configured to carry out the format-preserving encryption and/or decryption operation in accordance with user rights governing in respect of which data such encryption and/or decryption operation is permitted,
wherein the database server system returns the data in decrypted form to users which are allowed to access data in decrypted form and returns the data in encrypted form to users which are allowed to access data in encrypted form.