# A Usable Encryption Solution for File-Based Geospatial Data within a Database File System
## 3 Proposed Security Solution for Spatial Files
### Strong Encryption for Spatial Files  
Ensuring _end-to-end_ security for spatial files at the storage layer involves protection when the DBFS _access control model_ has been circumvented and also when these data are transferred onto other removable media for backup, destruction, and so on, and lie around unprotected. The field of Information Systems proposes six primary mechanisms for stored data encryption, with their respective advantages and disadvantages [65, 66, 67]:  
_(a) The Application-Integrated_ approach encrypts data at the application layer: that is, from within the application. While this is secure, all GIS client applications must be modified to support the encryption-decryption model. _(b) For DBMS-integrated_ encryption, entire database datafiles are encrypted, adding needless overhead. _(c) DBMS-based_ encryption encrypts only selected pieces of information. In our case, however, this approach has to be workable with various GIS applications. _(d) Operating-System-based_ encryption requires third-party encryption software for encryption, which could be difficult to integrate with GIS client applications. _(e) Operating-System-integrated_ encryption allows end users to encrypt files, folders, or file systems on different operating systems: however, the solution requires the encryption of entire database datafiles or the file system. _(f) Encryption-server-based_ approaches handle all encryption processing: however, they also requires modification of the GIS client applications. _(g) Storage-level_ encryption encrypts data at the storage subsystem, again adding unnecessary overhead. _DBMS-based_ encryption was chosen, as this approach only encrypts the spatial files stored within the DBFS database, preventing unnecessary overhead with regard to encryption of the entirety of the database datafiles. While this is similar to database record-level encryption, it differs through the need for pragmatic implementation, especially with the various GIS applications and protocol services. Since both encryption and decryption processes will be carried out within the DBMS server used by the DBFS, we used _symmetric key_ encryption where both processes can access the key, and in doing so, a public-private key approach was not needed. A public-private key approach would require GIS users to provide the private key for data decryption via a client application. In our automated approach, this would bring an extra step for users after login and require changes to client GIS applications to enable users to insert their private key. More details of the encryption scheme are described in the next section. Current encryption algorithms, such as AES, provide an efficient way to safeguard spatial files. To recover plaintext using an AES algorithm with an effective key length of 256 bits would take the strongest supercomputers today longer than the lifetime of the universe to break it [68]. As such, using the AES algorithm will make it impossible to make use of any secret information obtained from compromised database datafiles (that contain the spatial files) from the storage layer. The second component of our security solution comprises using encryption for spatial files within the DBFS. Subsequently, we investigated the performance of the AES algorithm when encrypting spatial files within ECMSDK against encrypting spatial files stored directly on the OS (e.g., _Windows NTFS_). We investigated the spatial file encryption speed within ECMSDK using the DBMS_CRYPTO_TOOLKIT provided with Oracle 11g XE Database [69] and the _OpenSSL_ encryption tool [70]. Table 1 compares encryption times in seconds for spatial files using the AES (256-bit) algorithm within ECMSDK and on Windows NTFS. In doing so, we carried out spatial file encryption and decryption in three scenarios: (a) within ECMSDK using Oracle DBMS_CRYPTO_TOOLKIT, (b) within ECMSDK using _OpenSSL_, and (c) within Windows NTFS using _OpenSSL_.