Development Story of the Delivery Encryption Module

Hibernate 6.x Compatibility Issues and In-House Module Development

Ahead of the launch of a new delivery system in September 2023, the Delivery Platform Development Team needed to migrate existing plaintext data to encrypted form and handle encryption/decryption at the application level. Considering concerns over vulnerabilities in existing open-source libraries and the difficulty of responding to future requirements, they built their own encryption module, cowcow-enc.

Three candidates were reviewed for automatic entity encryption/decryption. JPA @PostLoad was ruled out due to unnecessary update queries caused by dirty checking on read, and Hibernate PreLoad event was ruled out due to a bug (HHH-16350) that caused it to malfunction in a Spring Boot 3.0.4 (Hibernate 6.x) environment. Ultimately, they adopted the JPA @Converter approach, which does not use reflection and allows decryption even during JPQL queries.

Applying Envelope Encryption and Optimizing Data

cowcow-enc applies Envelope Encryption using a cloud provider's master key. By immediately discarding the encryption key and storing the encrypted data together with the encrypted encryption key, this approach lowers the risk of key theft and enables the entire envelope to be transmitted together during end-to-end communication.

Notably, unlike general-purpose open-source solutions, it removes unnecessary header information, achieving a 10%~30% reduction in data size. In addition, to eliminate the overhead of base64 encoding, it uses byte-only data types in PostgreSQL, MySQL, and others to improve storage efficiency.

Testing and Performance Validation

To ensure the module's stability, Property based tests were conducted using fixture-monkey. Robustness against unexpected input values was verified through 1,000 rounds of encryption/decryption tests with random values and priority testing of edge cases (EdgeCasesMode.FIRST). To confirm behavior in a real application environment, Spring Boot version compatibility issues were resolved via the cowcow-tests module, and it was confirmed that CPU and memory usage remained stable in an M1 MacBook Pro environment.