Wandering Key
Technology
Introduction
The Wandering Key technology allows to abolish the necessity of storing and therefore protecting by any means the actual symmetrical encryption keys while keeping the data safe and secure with existing encryption algorithms. Millions of unique keys associated with the object which initiated the process of either encryption or decryption are generated on-the-fly and not being stored anywhere. The technology can be applied to any field which requires protecting of sensitive data such as data warehousing, file systems, communications, etc.
There are many companies on the market today offering Key Management Solutions, but they all come down to the same standard approaches. It is either a Centralized Key Management as a most common solution with a Key Safe or a Vault dedicated to protect encryption keys or a Hierarchical (Onion) Architecture with a quite complex approach to access the keys.
The above mentioned approaches both share same weaknesses: the number of unique keys per object is limited and those keys are physically exist, hence do require protection.
When encrypting communications the following approaches are most commonly used: TLS and E2EE. TLS uses a man in the middle, usually a server through which the communication takes place. Typically the protocol implies the certification of parties and the use of asymmetric keys. E2EE communication is the direct exchange of encrypted data between parties. An example would be a digital radio or exchange of information between a drone and a control station. The communication with a drone is chosen here as a characteristic prototype, but it can be any communication that requires encryption. Common to these approaches is the fact that the set of keys is limited and it is typically One object–One key for the session of communication. Therefore in order to maintain safety in such systems frequent key changes would be recommended.
Wandering Key Technology
The technology relies on clusters and entities to manipulate virtual keys. The clusters imply database clusters, organizations, individual group of people, etc which coalesced to form a cluster. The entities imply objects within the cluster, such as database users, workers within the same organization, electronic equipment within a unit, etc.
Within a cluster each entity maintains a set of unique virtual keys not shared with other entities. The clusters are separate independent units which determine all possible keys which might be generated for any given entity. By design the keys between different clusters do not intersect.
In general the quantity of generated keys for each entity is determined by the task. In the provided example for the database engine the module will generate approximately 30M (33,554,431) of unique keys for each given entity, regardless of how many entities are present within the cluster.
If to engage, for example, astronomical objects here then a cluster can be imagined as an independent galaxy with a myriad of stars/entities and where each star has its own limited set of approximately 30M unique planets/keys.
Needless to say that the generation of encryption keys by the Wandering Key technology is
fundamentally different from the generation of session keys. Every entity has at disposal its
own set of associated virtual keys which are generated
on-the-fly as needed.
This picture represents a part of a database server architecture that includes the key generation module.
The module itself is an extension of the database engine and it is an essential part of the server when it comes
down to either encryption or decryption of data. This architecture is much simpler than the
centralized or hierarchical like approach for storing keys,
as it is no different from a typical server architecture. If to reiterate it again then the advantage of such
architecture is that the encryption keys are not part of the data, not stored anywhere, therefore cannot
be compromised.
When working with databases this approach allows not only to avoid the problem of key leakage, but also to reduce overall system administration and maintenance costs due to elimination of needless equipment dedicated to Key Vaults and such. Furthermore, this approach allows to reduce requirements for backup data storage centers, as the backups can be stored in public cloud services without resorting to expensive secure storage services.
Real World Testing
As it was mentioned above the number of keys generated for each entity is somewhat limited, and in current configuration for the database engine it consists of approximately 30M of unique keys. In real world applications the keys are not chosen sequentially as it is hard to imagine that there will be such a large number of records encrypted at once for a particular user/entity. Therefore the keys from the set are being chosen randomly and some issues caused by the random generator were expected.
To clarify a potential problem let's imagine that we have a set with only 10 keys available and want to choose 5 of those for encryption. In theory a pseudo random generator might yield a sequence of following numbers: 1, 11, 21, 31 and 41, from which we would determine that every time the key #1 should be used for encryption. Although in our case the set of keys is quite large, but the numbers produced by the random generator might exceed the number of keys in the set and the keys might be repeated. That is why the technology is called the Wandering Key as it is expected that once in a while the same key would be reused, but its usage would be unpredictable or in other words the key would wander.
The testing was carried out in Ubuntu Linux 22.04 LTS operating environment. The database server used for data processing was PostgreSQL 14.5. That server was functionally extended with the vlxaux.so key generation module to test the technology in a multi-user environment.
Key Wandering Test
In total 8 tests were performed with 10,000,000 of generated keys for each one. For this tests a single entity was chosen in order to figure out how many possible repetitions might occur.
The results of the tests are presented on histograms shown, while the second histogram below depicts the same
results in logarithmic scale. The following tables present more detailed information on the results.
What preliminary conclusions can be made? There was a small number of keys which were repeated 4 times each. All tests proved that the number of repetitions is negligible, no more than 4 repetitions of the same key per 10,000,000. Thus, on one hand we have some keys repeated, but on another hand the percentage of repetitions is quite low and it is less then 0.0001%. The number of repetitions can be further minimized by increasing the set of generated keys, which is easy to achieve given the resources permit so. But whether it would be practical or not remains uncertain, as to generate about 30M keys for each entity requires 16Kb of static memory, and if to increase each set, for instance, to a billion of keys there will be a need for about of 500Kb extra, which might not be feasible on busy servers.
The table below represents the total quantity of unique keys generated for each test, from which it can be concluded that roughly 100,000 of keys were seen at least twice.
| Test 1 | Test 2 | Test 3 | Test 4 | Test 5 | Test 6 | Test 7 | Test 8 |
|---|---|---|---|---|---|---|---|
| 9902286 | 9901876 | 9901682 | 9902294 | 9901827 | 9901961 | 9901820 | 9902049 |
In the table below is the actual data yield by each test. The leftmost column represents the number of repetitions found. The numbers in columns represent the quantity of keys which were repeated. Obviously when the number of repetitions equals to 1 it means that for those keys there were no repetitions detected.
| Test 1 | Test 2 | Test 3 | Test 4 | Test 5 | Test 6 | Test 7 | Test 8 | |
|---|---|---|---|---|---|---|---|---|
| 1 | 9805305 | 9804563 | 9804109 | 9805327 | 9804368 | 9804656 | 9804394 | 9804836 |
| 2 | 96254 | 96513 | 96833 | 96233 | 96751 | 96574 | 96678 | 96481 |
| 3 | 721 | 789 | 735 | 729 | 702 | 728 | 742 | 726 |
| 4 | 6 | 11 | 5 | 5 | 6 | 3 | 6 | 6 |
| 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
According to the first test 6 keys out of 10,000,000 were repeated 4 times each. Below is the table showing the wandering of those keys. The numbers represent the positions where the key was seen.
| Key 1 | Key 2 | Key 3 | Key 4 | Key 5 | Key 6 |
|---|---|---|---|---|---|
| 15422 | 978250 | 431848 | 1002805 | 201376 | 220589 |
| 892206 | 4681824 | 540492 | 1912177 | 1350439 | 894636 |
| 4172427 | 4704431 | 5493001 | 2482498 | 3997319 | 1809211 |
| 9425041 | 9549515 | 7018463 | 9764129 | 6658791 | 7713210 |
Since the tests were intentionally done for one single entity, it should be noted that some keys which were unique in one test were also seen in another while being unique in it as well. In other words the distribution among, say, 100,000,000 keys would be same as for 10,000,000 keys with the only difference that there will be more repetitions. In fact the combined set with 80,000,000 already generated keys yielded only one key repeated 7 times.
Test for Uniqueness of Generated Key Sets for Different Entities
For this test there were randomly chosen 50 entities and for each entity were generated 10,000,000 keys. The test passed with flying colors as not a single key was found to be common for that group of entities. Although such result was expected by design that quite laborious work was completed and all 1225 handshakes between 50 tables were made. To run more intensive tests does not seem necessary at this point, as technologically it is presumed that the keys are not shared between entities.
Performance of Key Generation Module
All tests including this one were performed on a machine with Intel i5-4690K CPU @ 3.50GHz processor. The average speed of generation was about 700,000 keys per second, from which it can be concluded that the module does not impede normal server operations.
Summary
Although the Wandering Key technology was initially developed for abolishing the storing of encryption keys within databases its possible applications go far beyond the database only practice. First of all for a normal use within a database cluster there is no practical need to have in hand tens or hundreds of millions of keys for each entity. Such necessity may arise for communication purposes or for encrypting of big file systems or for systems where the number of entities is limited. In such scenarios the number of keys per entity could be increased to billions to make sure that each sent packet is encrypted with a different key. For file systems the key could be changed for every encrypted page, this would prevent the necessity of breaking files apart and scatter those parts across the network, as it happens in today's practice.
Demonstration
The vlxaux.so extension of sqlite3 database engine was developed for demonstration purposes and it is available for download as a ready to use package. The extension works only in Linux environment and on x86_64 machines. The module utilizes AES CBC block cipher mode to either encrypt or decrypt data, and it is based on mbedTLS encryption library. Furthermore, the module incorporates various compression algorithms for more efficient storing of large data blocks.
The distribution package also consists of a powerful Password Management System as a working example and it is based on the vlxaux.so extension of the sqlite3 database engine. Besides, into the distribution is included a database with some personal data. While in that database the entities are exposed as they should be, the sensitive data cannot be decrypted, as it was created within another cluster and serves the only purpose to demonstrate the capability of technology.
The efile utility is another powerful tool utilizing the Wandering Key technology is included for demonstration purposes and it can be used as a general purpose utility to encrypt and decrypt files. It is available for download as a package from here. Needless to say that it is also limited to work only in Linux environment and on x86_64 machines.