I’m a bit late to the party, but this morning I learned that AWS is ending support for a feature called “SSE-C” for encrypting data in S3 in April. Normally in security when we hear a cloud provider is getting rid of a capability, we get annoyed, but in this case I think it’s a great decision. In this post I’ll quickly cover what SSE-C encryption is, how it was starting to be used for nefarious purposes, and your alternative options. Which you’re probably already using anyway since I can’t remember the last time I found an organization using this feature for anything built in the last 10 years.
SSE-C was always a bit of a weird feature. And even though it isn’t widely used, as it comes to an end I think it’s interesting enough, especially with its role in ransomware, to spend a few minutes saying goodbye.
SSE-C stands (well, stood) for “Server Side Encryption- Customer-provided keys”. It allowed you to provide an encryption key when you put an object into S3. That key was used by S3 to encrypt the data for you, and was then wiped from memory. The key was never stored, and the customer was totally responsible for their own key management.
Why did this exist? Well, it was launched before we had any other ability to encrypt on the AWS side with a key a customer could control. SSE-C allowed you to encrypt your data using keys you controlled, that AWS couldn’t ever recover or abuse (without sniffing in-memory, which would break all their contracts and would likely be an existential event).
Using SSE-C was a pain since it was required in all API calls and you, the customer, needed to self-manage the key. This wasn’t built into key management solutions and required custom code in your application accessing S3. I honestly never once encountered someone using it in the wild. Maybe we would have seen it more if KMS hadn’t appeared so soon. If you were going through the trouble of your own key management, from both an operational and security perspective, the odds are client-side encryption was a better option than SSE-C (encrypting your data before putting it in S3, which I used to see not infrequently).
Here’s an example of a script using SSE-C in the AWS command line. Yeah, not super painful but not super fun:
SSE_C_KEY_MD5=$(openssl dgst -md5 -binary sse-c-key.bin | base64)
SSE-C is something I think we included in one iteration of the CCSK training class, then promptly ignored. It was there, but not widely used, and was more of interest as a conceptual demonstration than a tool I would actively recommend. Between KMS, CloudHSM, and client-side encryption there really wasn’t a place for it.
Which is why I was kind of impressed when I found out there was a ransomware campaign leveraging SSE-C. This was pretty devious. Here’s how it worked:
While slow, this attack was interesting for a few reasons:
This was not a widespread or common attack technique! But SSE-C is a feature that isn’t really recommended anymore, and there are many better alternatives. I’m not sad in the slightest that AWS is deprecating it.
Look, for a moment let’s pretend one of two of you are using SSE-C. I mean, we all know you aren’t, but I feel like I need to leave some recommendations here.
For the vast majority of S3 encryption, just use KMS. If compliance is an issue, use it with a Customer Managed Key (CMK). If you want the ability to cut off AWS, you can use a CMK with your own key material.
If you have data that absolutely needs to be isolated from AWS and you still want to use S3, use client-side encryption. This is how I long managed my personal backups; I used a backup tool that put my files into S3 with a key that never left my system. (I still do this, just not with an S3-based service anymore).
SSE-C never really took off. It was an odd duck approach released before we could manage our own keys in AWS, and when local encryption was performance limited. It’s impressive some adversaries got creative with using it in ransomware, and thus provided AWS to end a feature that should have crossed the rainbow bridge years ago.
Share this content on your favorite social network today!
Monthly updates on all things CSA - research highlights, training, upcoming events, webinars, and recommended reading.
Monthly insights on new Zero Trust research, training, events, and happenings from CSA's Zero Trust Advancement Center.
Quarterly updates on key programs (STAR, CCM, and CAR), for users interested in trust and assurance.
Quarterly insights on new research releases, open peer reviews, and industry surveys.
Subscribe to our newsletter for the latest expert trends and updates
We value your privacy. Our website uses analytics and advertising cookies to improve your browsing experience. Read our full Privacy Policy.
Analytics cookies, from Google Analytics and Microsoft Clarity help us analyze site usage to continuously improve our website.
Advertising cookies, enable Google to collect information to display content and ads tailored to your interests.
© 2009–2026 Cloud Security Alliance.
All rights reserved.