From January to July 2024, I worked at CERIST on an autonomous Key Management Solution for cloud environments. The topic was practical: keys should be generated, stored, rotated, and used without turning the application into the security boundary.
The work made me think about lifecycle first. A KMS is not just an encryption wrapper. It has to answer awkward questions: who can ask for a key, where does the key live, what happens when a user leaves, how do you revoke access without breaking every dependent service, and how much trust do you put in the cloud layer itself?
I built the project as a complete service rather than a short demo. The useful part was the discipline around interfaces: clear API boundaries, separation between key material and consumers, and enough logging to explain what happened later. That experience still shapes how I read security architecture offers. I look for the boundary, then for the place where the boundary will fail.
What I can bring to an internship from this work:
- Key lifecycle reasoning: generation, access, rotation, revocation, and auditability.
- Cloud-security thinking that stays close to implementation.
- A habit of writing security systems as services other developers can actually integrate.