To provide data confidentiality and establish data integrity with minimal performance overhead, “Authenticated Encryption with associated data” (AEAD) ciphers have become mandatory for implementing transport security in TLS 1.3. However, these ciphers have yet to find wide-range adoption within the domain of security at rest. This is problematic since software-defined storage (SDS) systems provide even smallscale organizations with a cost-effective method of storing large amounts of data. At present, AEAD ciphers at rest are most commonly used to encrypt objects in the object stores of AWS, Azure, and Google Cloud. However, these ciphers are not applied to client-side encryption for other storage formats, such as block or file storage, resulting in asymmetric security guarantees across storage services. On the server-side, AEAD encryption has, to the best of our knowledge, also not been widely adopted. Since neither AEAD encryption on the client- nor server-side has seen a wide-range adoption, this paper compares the benefits and downsides of employing AEAD encryption on the client- or server-side within SDS systems. To establish this comparison, we implemented a client-side and server-side encryption approach in the widely adopted Ceph SDS system. Our study demonstrates that incorporating AEAD ciphers can be achieved with a write performance loss of less than $5 \%$, while ensuring a higher security level than traditional encryption-at-rest approaches. Most importantly, we managed to achieve these security gains for data stored in all available storage formats in Ceph.

Ceph portrays a resilient clustered storage solution with supporting object, block, and file storage capabilities with no single point of failure. Despite these qualifications, data confidentiality defines a concern in the system, as authentication and access control are the only data protection security services in Ceph. CephArmor was proposed as a third-party security interface to protect data confidentiality by adding an extra protection layer to data at rest. Despite the added layer, the initial design of the API needed to be more efficient in addressing security and performance simultaneously. In this study, we propose a new architectural design to address the associated issues with the preliminary prototype. Comprehensive performance and security analysis verify the improvement of the proposed method compared to the initial approach. The benchmark result has indicated a 37% improvement on average in IOPS, elapsed time, and bandwidth for the write benchmark compared to the initial model.