Encrypting Processes and Public Key Infrastructure in Regard to Data Safety and Security in Database Systems

International Journal of Emerging Technology and Advanced Engineering

311

Encrypting Processes and Public Key Infrastructure in Regard

to Data Safety and Security in Database Systems

Anna Plichta

, Szymon Szominski

1_{Faculty of Physics, Mathematics and Computer Science Cracow University of Technology ul. Warszawska 24, 31-155 Krakow,} Poland

2_{Second Author Affiliation & Address Faculty of Electrical Engeineering, Automatics, Computer Science and Electronics AGH}

University of Science and Technology Al.A.Mickiewicza 30, 30-059 Krakow, Poland

Abstract—We can distinguish three basic properties of information security, which should be implemented in nearly all IT systems: confidentiality, integrity and availability. Confidentiality means to protect the information against unauthorized access. Integrity is mentioned as a warranty of authenticity of information; it is also connected with protection against unauthorized interference. Availability means that users have access to the database, but their access needs should be met. The databases security strategy is not only concerning the cryptography. User access control, backup strategy, recovery rules, security audits and using only safe connection methods are also important. All the elements mentioned above are necessary, but nowadays they aren’t sufficient.

Keywords— database security, ,encryption, Public Key Infrastructure.

I. INTRODUCTION

If the attack on the database happened, the aggressor can be external or internal. The external aggressor is a person who tries to connect to the database from outside of our system, so the one should go through a few security technologies such as firewalls or unauthorized access detection systems, the aggressor also should fight with the connection without authorization. The task of attacking our system becomes so easy, when we talk about the internal aggressor. This type of person usually has some information about topology of the network, also he or she has an authorized access to the internal network. Because the number of external aggressors is much higher than the ‗internals‘, companies take their attention only to them. Although that, companies usually are not thinking about the risk, which comes out of the internal aggressors. As we mentioned above, the internal aggressor‘s task is very easy, they have better access to the system. Database administrators should also notice the threat of the internal attacks. Administrator has access to all information stored in database, so if he cooperated with an aggressor, he can hide or delete evidences of intrusion. Here comes the cryptography, the database administrator is no more dangerous to the database.

Attacks can be classified by frequency of attacks (permanent or single attack). Permanent attack is when the intruder returns to the database after first connection to perform next attacks after which the attacker disappears. Single attacks are more hazardous and harder to discover – the aggressor connects once, finds ―useful‖ information and disappears. Permanent attack is easier to detect and set up an alert.[1]

II. BUILDING ACRYPTOGRAPHIC INFRASTRUCTURE

Project of a cryptographic database protection, which will guarantee high security level (for data and keys), well scalability and key management in whole lifecycle is a difficult task and needs some strategic planning.

A. Application architecture

Typical scheme is a database placed in three-layer application environment. Those three layers are:

 Presentation layer

This layer is provided by www servers, which provides websites acting as GUI. In addition, on those websites can be placed special applets or source code, which is being run on the workstation.

 Application layer

It contains application servers. This layer should process requests coming from the presentation layer; it interacts also with the database layer. Results obtained by application layer are sent to presentation layer, which shows them for user. Application layer is present, when the source code is connected with business intelligence.

 Database layer

International Journal of Emerging Technology and Advanced Engineering

312

The mentioned layers provide external service for web server. Presentation layer is connected to the Internet, so when we look at all three layers, they‘re creating an extranet. This three-layer architecture is sometimes used for business corporation applications, but in that case the presentation layer is visible only from intranet.

On the figure below is presented three-layer architecture for extranet, in which between each layer is implemented firewall mechanism. Traffic in such architecture is in the way showed by arrows. Presentation layer can connect only to application layer, there‘s no possibility to connect with database layer directly. All incoming connections from the Internet are allowed only to connect to the application layer, access to other is denied. If on office server is stored additional business code, the intranet can connect via the same firewall, which is using for internet connections.[3]

Fig. 1. Model of the functioning of the e-learning (Source: Kevin Kenan, Cryptography in the Database: The Last Line of Defense,

PWN, Warszawa 2007, p. 59)

In contrast to the internet traffic, here the traffic coming from intranet would have access to each layer, but the connection should be established from the intranet – that‘s a requirement. So now we have a question – where to place cryptographic mechanisms which are protecting database? First, they shouldn‘t be placed in presentation layer, because it is the most accessible layer. Second, there would be no direct access for cryptography to database, because it would be blocked by other firewalls. However, some encryption mechanisms are set up in the presentation layer, e.g. HTTPS encryption support or encryption for protecting data which is stored in primary memory. For such solutions, the mentioned above case is inconvenient. Omitting the presentation layer, there‘s no more elements of configuration, which we should take care of. So finally, the answer for the question depends on desired security level, localization of customers and budget for hardware, software and salaries for employees.

B. Cryptographic architecture

Cryptographic architecture is an elastic modular system, which is easy to adapt in many situations. When the modularity and elasticity is rising, also the level of security rises. Important is to maintain balance between security and functionality. As the figure shows, the project contains seven components, three data stores and four processes. Also there is shown some interactions taking place during encryption.

A safe for keys is responsible for storing keys and should provide very strong protection. Access to keys has only the crypto machine, sometimes also the key manager. The best solution in giving access to the safe is to give it only for the personnel, who are responsible for safety and crypto machines. Although that, the safe must be configured to provide encryption for the keys taking from safe, and this entire encryption should use separate special key. As it was mentioned in the previous chapter, modern machines have its own safes for keys. Key protection is one of main goals for these machines. A good example of crypto machine is, mentioned before, HSM. But if we are using a local machine, the safe should be implemented separately. During the encryption process, key is outside the safe, which is a problem – because access to the machine implies also access to safe. This is a real disadvantage for local machines and their safes. Better separation between machine and safe accesses provides HSM machines.

Safe is a component which have stored the value of key, ID of key (distinctive for each safe), attributes describing the proper algorithms, possible ways to use and rules of operation. Safe, in its own environment, is responsible for transferring keys to crypto machine, creating new keys, getting current keys, removing keys and configuring their attributes. When we would use a database terminology, there‘s one-to-many relation between machines and safes, but between machines and keys, there‘s one-to-one relation.

Key documentation is a module which can define keys and crypto machines according to the cryptographic provider needs. Key documentation forms an abstraction layer, with which the provider can use many key safes, even if ID of those keys is identical for two separate keys stored in different safes. In order to change the machine-safe pair, only the update of key documentation is needed. In documentation the below listed information is stored:

 ID of alias

 Alias value

 Key family

International Journal of Emerging Technology and Advanced Engineering

313

 Key‘s activation date

 Machine

 ID of key

ID of alias is unique in each safe and it is used to identify the entire key in the whole cryptographic system. ID of key identifies the entire key only inside the safe. Alias value is key‘s name or label, which is stored as alias. Each key can belong to one of the key families, key documentation stores this membership. Possible key states are: awaiting, live, expired, withdrawn and removed. State of the key is defined by its status and activation date. Status can have one of these three values:

 Active

 Expired

 Withdrawn

Please notice that two last values are the same as possible key states. In case that a key is active, the state depends on the activation date. So if the activation date is placed in the future, the key with active status has awaiting state. This one, which has the most actual activating date, is live. Other keys, which have state expired, have also activate date older than the activate date of current live key. Information about machine describes how to use the key.

Of course, higher availability of documentations means the risk of attack is also higher. Offline attack isn‘t a big threat, because in documentation there is no information, which can be helpful to attack the cryptography

mechanism. Although, in the online attack the

documentation can be changed. This modification can affect in data destroying and then, the data must be recovered from backup. This type of threat is applicable also to databases not protected with cryptography, when online aggressor will modify the database. There are two types of attack directed to weaken the security. First is deleting all keys in key documentation or to make them inactive. Then the aggressor makes the system unable to encrypt data, because there‘s no key able to do it.

Second type of attack is based on introducing a declassified or removed key as a live key. If there‘s removed key substituted, crypto machine should give an error and force system to use the default key. When the declassified key is used, aggressor gets an access to three keys: waiting, expired and withdrawn and he can use all of them. The best method of protection against this type of attack is decrease number of keys holding these states.

The keys, which are most exposed to declassification, are withdrawn keys, then comes expired keys, and last, but not least, awaiting keys. There‘s a good solution: expired keys should become withdrawn as soon as possible and withdrawn should become removed quickly. Also awaiting keys should be generated only few months before their activation date. Key manager - To create, change or delete key, system administrator use key manager. This is a

component cooperating with key safe and key

documentation. Significant number of operation made on keys makes necessity to modify both key safe and key documentation – and that‘s a task for key manager. Manager can connect many safes and documentations and that implies strong access control and authorization mechanisms. Declassification of key manager means to declassify whole cryptographic infrastructure.

In order to make key distribution easier, manager creates so called key zones – independent collections of keys and aliases. No one alias points to key from outside the zone and key and its alias belongs only to one zone. If key manager does any operation (e.g. creates new key), it is done only in the entire zone. That means the documentation can be assigned to one zone and all documents belonged to this zone has identical alias set. In one key safe can be stored keys from many zones, but then must be met a requirement: each key should belong to one zone. Safes and machines have a one-to-one assignment, which makes the documentation of a zone which use many safes have aliases for keys that are used in many machines. Direct access to documentation has cryptography provider.

International Journal of Emerging Technology and Advanced Engineering

314

Fig. 2. SQL Server encryption key hierarchy (Source: http://msdn.microsoft.com/en-us/library/cc278098(v=sql.100).aspx

When administrator is logging in to the key manager, it saves, to which zones he can have access. After logging in, administrator choose a zone to make modifications. In order to make some, key manager should identify key documentation for this entire zone and then ask authorization storage for encrypted authorizations and receipt. In the described project, to decrypt an authorization, key manager use its own documentation and safe. Key manager can use authorizations in order to get access to the zone, placed usually in one or few databases. If administrator‘s command needs access to key safe, he need to define, which key safes he need access to. Safe definition can be made explicit (administrator enters list of key safes) or can be done by key manager, which is specially programmed and know, which keys are needed and where they are stored. After safe definition, access is granted in the same way as access to documentation. Because project is serving many documents in zone, the process mentioned above is really rare. It is recommended to use simple zones, in which single set of machines and safes is in use only in one zone. If it‘s not applicable, we should try to maintain single documentation in zone and make safes being shared.

Cryptographic provider is a central point of our system. Provider gets data from customer, then it looks for proper key documentation and runs crypto machine. After encryption or decryption process, machine returns a result of operation to provider, which creates a receipt.

Receipt and result are sent to customer. Usually a cryptographic provider is placed on application server and

contains some components: services interface,

documentation interface, initial element, machine interface, encryption module and receipt manager.

Only the services interface can be used by other modules. This interface allows only inputting commands from customer: encryption or decryption. Customer, when is generating a command, sends plain text data and key family. Provider then is using documentation interface. Normally the documentation is stored in database, so documentation interface must have access to this database. When using the documentation interface, there is a possibility to get key alias, information about crypto machine, key ID and algorithm. Initial element plays double role here: it is responsible for providing initial vectors or initial counter value and, where applicable, it provides service for supplements.

Each operation (encryption or decryption) needs to be confirmed. In encrypting case, cryptographic provider generates a receipt for customer. When decrypting, provider needs to have a receipt to read required metadata. Receipt is a data structure which typically contains key alias, initial vector or number of counter requests in operation. The management is done by receipt manager module. Similar to other infrastructure elements, also the provider is exposed to attacks. Usually provider attacks are trying to weaken one of its components.

International Journal of Emerging Technology and Advanced Engineering

315

Providing security means in general to reduce number of entry points to application, to provide a strong application defense mechanisms and to check the application code if it met requirements of safe programming.

Customer is a component integrated with business code and it is responsible for protected data management. Because cryptographic customer should be always accessible when encrypted data should be processed, it is stored usually on application server. In applications, which offers separate components for business purposes and database connection, the customer would be integrated with database interaction code. Customer is responsible also for receipt management required to decrypt data. Receipts can be stored in a separate table or they can share one table with encrypted data.

In case of using separate table, each table storing encrypted data has its own receipt table. This type of table contains columns for key aliases, initial elements and foreign key pointing to base table. The structure of this table depends on key range in base table. Each key range has its own column in receipt table, which stores key alias. Each encrypted column has assigned to it special column holding its initial element. Each row of the receipt table is associated to one row from base table with foreign key. According to these rules, a table, which is served by narrow range keys, has at least 2n+1 columns, while the base table has n encrypted columns. All encrypted columns have their own initial value columns. If keys have narrow ranges, those columns have also their individual ranges. For each column, separate alias keys are stored. Foreign key is saved in another additional column. Sometimes the number of column can be increased in order to store creation date, updates or receipt identifiers. If we would look into the cryptographic customer from the inside, it should be able to define key family and range which the entire column belongs to.

Suppose that we have four columns, customer sends four encryption requests and as a result it has four encrypted elements and four receipts. Customer saves this data in suitable columns and updates receipt table. It is recommended that each receipt should have identical key alias, saved in the field which matches its range and to save the initial element got from receipt in each field. Sometimes there's a situation when base table cannot save encrypted data, especially when base tables are a part of application, which belongs to another cryptographic provider. We cannot simply make changes, because these changes can make a break in application functionality, revocation of the service or have negative influence on updates. The solution for this problem is to store protected data in special columns in receipt tables.

Applications which have access to original columns should be changed in order to deal with encryption. When we will think about attacks on customer, they can be targeted on business code, so the security level should be the same as for cryptographic provider – coding should be used.

Protected data means data which should be encrypted. End users, personnel who process data, www clients and key administration personnel interact with system. Also we have some automatic tasks entering, processing or

downloading encrypted data. Interactions between

components of infrastructures are started by administrator who uses the key manager, creates new key in safe and adds it to documentation. During documentation modifying administrator assigns key to family and sets up its activation date.

There‘s an interesting situation when customer has data for encryption. It sends this data to provider to encrypt them and it defines which key family should be used. Using the documentation our provider check, which key in family is live and which safe and machine are assigned to it. Provider also gets other metadata, e.g. initial vector. All information is sent to crypto machine, which gets matching key and starts encryption process. After encryption, data is returned to provider. Provider generates receipt containing ID of key and other properties. Receipt with cryptogram is sent to customer, which saves it to database. When a decryption is needed, it sends it back to provider with receipt. Provider gets required information; check in the documentation if this key is valid, when result of the test is positive, it sends a decryption request to crypto machine. Results of decryption are sent back to provider, which passes them to customer.[2],[4-6]

III. SUMMARY

Nowadays information is crucial, so databases and any applications connected with encrypting systems should be well secured. To sum up: encrypting is one of the most important barriers protecting databases and security of such encrypting system depends on the precision of created hazard model. Chosen encrypting method affects the size of database and strength of the security systems protecting it. Moreover one should design encrypting systems carefully, for unwise solutions may pose a threat to the database instead of tighten it.

REFERENCES

[1] Buchmann J. 2006. Wprowadzenie do kryptografii. Wydawnictwo Naukowe PWN, Warszawa

International Journal of Emerging Technology and Advanced Engineering

316

[3] Kenan K. 2007. Cryptography in the Database: The Last Line of Defense. PWN, Warszawa

[4] Kryptografia. Teoria i praktyka zabezpieczania systemów komputerowych (wykłady z kryptografii) -

http://wwwcs.uni-paderborn.de/fachbereich/ AG/ agmadh/

WWW/german/LehreKuty/kryptografia/

[5] Ogiela M. 2000. Podstawy kryptografii. Wydawnictwa AGH, Kraków

[6] Stokłosa J. 1992. Kryptograficzne metody ochrony danych. Wydawnictwo Politechniki Poznańskiej, Poznań