# A Usable Encryption Solution for File-Based Geospatial Data within a Database File System
## 3 Proposed Security Solution for Spatial Files
### Encryption Challenges for Files within the DBMS  
Here, we outline the several challenges that were faced while implementing the encryption of files within a DBMS. These relate to how encryption algorithms are implemented, how DBMS handle large data, and how to obtain optimum encryption performance.  
**Reducing physical read-write operations:** Reduction of data transfer and lookup is a critical component of database optimization and has impacts on the realized speed and performance of a database. Ideally, database read/writes are kept to a minimum as, in a practical sense, this results in a more seamless experience for the user whereby only the data that are needed are loaded and written. To reduce expansive disk I/O read/writes, _more_ data should be read in each read-write operation. However, this is limited by two factors. The first is the _maximum_ allowable data storage in a scripting language: in our case, the VARCHAR2 datatype in Oracle PL/SQL is limited to 32,767 characters (32 Kb) [63]. The second is the _amount_ of input bytes that an encryption algorithm allows: that is, the AES encryption algorithms provided by Oracle within the DBMS_CRYPTO_TOOLKIT [64]. The amount of information that can be read by the AES encryption mechanism is a critical element of security. The algorithm parses data in 32 Kb chunks to limit the potential of data leakage in the case of errant data being exfiltrated in the process of transfer. _However_, with the small size of the transfer, this increases the number of calls that are required to ensure the user has the information he/she needs at the time of usage. Increasing this to a larger amount reduces physical I/O read/writes.  
**Encrypting files larger than the database buffer cache:** The DMBS server returns an error when encrypting files larger than the Oracle DB cache size, indicating no more _free blocks_ left in the DB cache. For GIS, the cache size matters. Point clouds, high-resolution satellite data, and other large data formats often require dynamic data streaming between the hard disk, database servers, and main memory (RAM) in the user's computer. Management of this is a complex dance, and cache size is a prime determinant of the size the stream can stage between access reads and writes. One could increase the _DB buffer cache_ size to a very large value, and this should not be an issue, as in DBMS today, servers with 128 GB RAM (memory) are a common solution. However, GIS data are now often large enough to outpace the available cache size. Thus, in our approach, _dirty buffers_ are written to disk regularly by encrypting each file in large chunks and issuing the COMMIT statement multiple times during encryption or decryption.  
**Excessive redo log generation:** Traditionally, for any changes made to the database, DBMSs create new entries in the _redo log files_ for recovery purposes. For large spatial files, this raises excessive logging overheads in the form of additional CPU time and disk space usage. To improve encryption performance, the NOLOGGING setting for _Oracle Large Object_ (LOB) can be used.  
**Searching encrypted file data:** Core organisational functions require searching information that has been encrypted. Differential privacy focuses on allowing users to query and retrieve aggregate statistics from spatial data without viewing individual data points, and it is possible that we can integrate these algorithms (instead of AES) in the future if they become open-source and their security has been tested and proven by the research community. Nevertheless, ECMSDK allows custom attribute (_metadata_) to be defined and associated with files, which can be used for searching. Since encryption only encrypts the file content, these custom attributes can be used for searching, preventing the need to search the encrypted content itself.