Historical Tink encryption design journal
Tink is an open source library by Google that facilitates encryption/decryption GitHub - Google/Tink
These are the basic business requirements:
- All test data under the test data directory (already a property) should be encrypted manually by the user using the CMD tool. We should provide the user with a bat file that they can double-click, and it will encrypt all their data for them recursively. This is done outside the engine.
- All test data under the test data directory (already a property) should be decrypted automatically and recursively by SHAFT before any test execution.
- To automatically decrypt the data, SHAFT will accept some properties from the user to show the name of the key and any other parameters required by tinkey.
- This should be implemented to support both local keys and remote keys as per TinKey's documentation.
- All decrypted test data should be deleted automatically by SHAFT after any execution to ensure that only the encrypted files exist in SHAFT's test data directory.
- This concludes the initial business requirements, with area for future enhancements.
Implementation approach:
- work on the coded part
- adding the maven dependency
- adding the code to automatically decrypt data using local key
- adding the needed properties to enable automated decryption
- adding support for using remote keys
- adding the code to delete the decrypted files after execution is finished
- work on the tinkey binary facilitation part
- understanding how the binary works to generate new keys
- understanding how the binary works to encrypt files
- creating a .bat file that automatically encrypts all files in the testData directory
- bundling the bat/sh file with SHAFT to be generated for all projects
I will keep this document updated with my findings to document the entire thought process and implementation sequence.
Implementation steps:
- found the needed data here Dependency
- added it to the pom.xml
- found a java guide here JAVA Todo
- found that extra dependencies are needed for remote key management, added them to the pom.xml
- created a dedicated package and moved this file to under com.shaft.tools.security
- created a demo java class (GoogleTink.java) to start playing around with the implementation
- created a demo test class (src/test/java/testPackage.tink/demo.java) to call the encrypt method from and see how it works
- first attempt was successful and the file was encrypted as expected
- first attempt to decrypt the file was a failure, the file was wiped
- restoring from backup
- adding code to load from existing keyset
- pausing the first coding session
- starting the second session To use Tinkey you need a key. there are two ways to work through this, the more secure and the less secure. SHAFT will support both, because this is a key generation method and this can be achieved by the user running the single command in the above URL.
- to implement I will work with the less secure method, the plaintext keyset (local key file)
- downloading the latest tinkey binary was easy from this link
- extracted the binaries and failed to generate the key using the provided command
- reformatted it to "./tinkey create-keyset --key-template AES128_GCM --out-format json --out aead_keyset.json", ran it from powershell, and it worked
- a key.json file was generated successfully
- refactoring the code in GoogleTink.java to accept the path to the key file WARNING: the key json file must never be shared over source control but even if it was, generating a new key is a piece of cake
- attempting to run with the new algorithm
- data encrypted successfully
- data decrypted successfully
MILESTONE 1 REACHED || Initial Implementation Success
- creating property file to manage the two needed external variables
- TODO: add logs / report steps
- TODO: create loop to automatically and recursively encrypt/decrypt all the test data subdirectories/files
- testing encryption/decryption flows after migrating to properties
- TESTS PASSED
- implementing logging and reporting (Note to self: do not over-do it, keep all private data off of the logs and reports, and don't attach any files in the execution report.)
- implementing loop to automatically and recursively encrypt/decrypt all the test data subdirectories/files
- resolving issues with existing FileActions methods to facilitate reading files recursively
- creating tests to encryptAll and decryptAll test data
- TESTS PASSED
MILESTONE 2 REACHED || Extended Implementation Success
- TODO: integrate with SHAFT listeners to decrypt before all and encrypt after all seamlessly
- done for the three execution modes (TestNG, Cucumber Native, Cucumber Test Runner)
MILESTONE 3 REACHED || All Requirements Implemented Successfully with several enhancements
Current user Experience:
- User will follow the instructions under tinkey.properties file to create a keyset (plaintext or cloud encrypted via KMS)
- User will add the two needed properties in this file
- SHAFT_Engine will decrypt the data before execution (if encrypted)
- Execution will behave as expected
- SHAFT_Engine will encrypt the data after execution
- No manual user interaction required