Application
KDS
KDS FileSystem
File1 File2
RNG
Reader Writer
Storage
(3) (1) (4) (3,4,++) (1,2)
(2)
Figure 6.1: The flows of the “Everything using AES and random keys” for one record. The particular variation illustrated are the KDS housed keygen.
The writer appends a single record to the end of File1.
The reader reads File1 and retrieves the keys neccesary to decrypt the records.
6.4 Design: Everything using AES and random keys
The design for AES everywhere is one of the first ideas that are going to come up before they start looking at it. The idea is that every “record” is encrypted with AES with a random key. The key is than stored by a KDS
6.4.1 Operation Starting conditions
To initialise the system there is a need for a key management/distribution system (Faythe). This system controls who has access to what keys. There are two key generation designs the only difference is if it is Faythe or Alice that does the key generation.
Data ingestion
When a new record arrives alice generates a key, encrypts the record and sends the key along with it’s metadata to Faythe. Alternatively, Alice sends a request for a key along with the metadata to Faythe and Faythe does the key generation and sends the key to Alice. After the record is encrypted Alice Disposes o the keys.
Data consumption
To allow Bob to decrypt a record Bob needs to get the decryption keys for the records.
These can be retrieved with a request to Faythe using the metadata. To mitigate the
66 6. BUILDING A SYSTEM
problem of the large number of key requests the requests for keys could use search syntax. After use Bob disposes of the keys.
Once a result has been produced Bob encrypts the data either by generating keys and submitting them to Faythe or by having Faythe generate new keys for him.
Authorisation
Authorisation happens by telling Faythe that Bob should be granted access to a new set of data. Then Faythe will start approving requests from Bob for those keys.
6.4.2 Attacks Passive data attacks
For Eve to decrypt data she need to have access to each encryption key for each record. There are some data available in the metadata identifying each record.
Active compromises
Trudy could compromise Alice to get access to the records and keys passing trough while Alice is compromised. If keys are generated by Alice using an unsecure seed-vulnerable mechanism the keygen stream can be used to find future and/or past keys.
By compromising Bob Trudy would be able to access any data in a decrypted state in memory and any keys that may reside in memory. Because this is a system compromise of the compute platform, the mitigations of section 7.1 would not prevent this. These compromises assume that Trudy is able to gain memory access to the places where these kays are stored. The Java Virtual Machine (JVM) should try to prevent this.
If Trudy is able to compromise Faythe, every key is available for use. Faythe is the most valuable target in the entire system. For this system Faythe has full access to all keys and only denies/grants access based on access rules.
Privilege escalation
Wendy here refers to the user rather than the process. If the user-created part of the process has access to the decryption keys Wendy can embed them in the output data. Using these keys Wendy is able to retain access to data after her access has been removed. If the encryption system is transparent as described in section 7.1 Wendy would not have access to these keys.
6.4. DESIGN: EVERYTHING USING AES AND RANDOM KEYS 67 If there is an escalation exploit in Faythe’s systems Wendy could leverage this in order to get keys she are not authorised to access.
6.4.3 Encryption times Variables:
n Number of records to decrypt r Record length (KiB)
m Number of keys that need to be loaded to find all the required keys for the particular set of records. For the recordm > n.
The final time isnrecords withrKAES decryption time each. In addition comes a log(m) search time for each key, per record.
n(rKAES+log(m))
Now, it is possible to use a hashmap to negate the search times, but it will not provide a significant impact. It will still be included as a placeholder for a Application Programming Interface (API) call to a KDS for each key.
The real limiter of this solution is the memory usage. The system (or the KDS) needs to storemkeys in memory. If separate API calls to the KDS is used this does not impact the available memory on the compute node, but adds the delay of the API call to the decryption times.
The encryption times are similar, except they have a key generation and storage step instead of a search step.
6.4.4 Pros
– Fairly fast
– Secure as long as the key manager is keept secure – Can be made infinitely granular if needed.
6.4.5 Cons
– Generates a lot of keys, the key management itself might end up as “big data”
– A compromise of the key manager compromises everything.
– May exhaust the secure random key generator.
68 6. BUILDING A SYSTEM
Figure 6.2: The flows for the design “Everything using ABE”
In this case the public (encryption) keys are stored openly on the file system.
The cases here are “cold start” cases, there the application does not have any keys.
The decryption key displayed is “personal” to reader.
– If a too high degree of granularity is used, the keys and metadata may exceed the actual data in size.
6.4.6 Viability
“Very small” data
Very well suited, in some respects this mechanism is what is used for most imple-mentations that was looked at for existing data-at-rest encryption mechanisms. In their case a “record” is usually a file or a collection of files.
“Small” data
This will push the limits as the ciphertext would have to be matched up with the keys. If the metadata allows for a efficient search structure this is still viable.
“Big” data
Way too manny keys to keep track of, unless the data can be sifted using the metadata to a significantly smaller set.