I wouldn't say "nothing"–it's certainly not complete control but it reduces the attack surface. I don't control the proprietary password manager I use, but the fact that I control the encryption keys and they don't means I'm less vulnerable to attacks on their service infrastructure.
EKM does not provide the same security as a password manager for the content (i.e. Slack messages and passwords). In this case Slack is still able to request a key from the KMS in order to perform operations over the messages (search, archive etc). Those keys generally have some sort of expiration on them by default (hour, day, etc) before they're rotated. However, during that window the key could be copied and used w/o the "reason" being logged. More realistically, the security threat is that there is a bug somewhere that while the data is unencrypted in memory it accidentally logs some proprietary data into a secondary system that is not encrypted with the same EKM system... EKM is a bit of shell game but everyone loves some good security theatre.
You forget that this is supposed to protect the enterprises against hostile action by Slack itself. This, of course, it does not do, as slack could simply change the application to accept an additional key, or to just do what they want done without any request.
I don't understand that about companies. The trust situation just doesn't change:
Before "managing their own keys", they
have to trust Slack to not break their security
After, they
have to trust Slack to not break their security
But I've seen enterprises take and in fact insist on this often. It never seems to matter that this is a useless gesture. A signed contract that they won't break their security, which is a far less invasive and easier measure, is better. At least that provides some recourse.
I would argue that your threat-model is wrong in this scenario. EKM isn't there to protect you from the company that you're using, it's to protect both you and the company from legal overreach.
I work at a company that does EKM for its customers. It doesn't force us to secure our customers' accounts, it allows us to secure them. We get to say things like "I'm sorry, we are unable to pull this data" rather than having to convincingly argue why we shouldn't. This makes us very happy. Maybe we can be forced to break things in such a way as to eventually get any future data you submit, but that's a whole lot more difficult / expensive for the government than the typical "all ur data are belong to us plz" requests.
Yes, if the service provider is malicious, EKM isn't going to save you from them. But if the service provider is not malicious, it can save both you and your service provider.
It is a perfectly sensible threat model to exclude government intervention. Perhaps more sensible, on the grounds that the government can always make your life hard in other ways, and the government can get away with not following the law. There are lots of meaningful attackers who are unaffiliated with the government, and it's absolutely worth protecting against them.
This does not result in a change of threat model at all. That's what I've been pointing out. It does not protect against anyone at all, nor does it make you more vulnerable to them.
It does not exclude government intervention at all. The government still has the power to compel a change in the code that works with the encryption keys. When that happens, exclusive access to the keys, to put it mildly, won't matter.
If you think differently, let's see you put your actual trust in this process. You keep access to all your encryption keys and passwords, I even promise not to copy them, but you log into your web banking using a web browser I control. Which is the equivalent of the situation discussed here: I control the code interpreting the encryption keys, you control the encryption keys. Depending on your bank's authentication method I may or may not be able to copy the keys, but either way I'll be able to, say, change a bank transfer you make to my liking, which is really the point anyway. So I will transfer a suitable fee for your education, let's say $100, "without access to" your encryption keys to some charity of my choosing. Deal ?
Does EKM let you actually borrow a copy of the key instead of just doing operations remotely (like an HSM would)? Ugh, then yes it's security theatre. But I'm also surprised regulators are fooled; there's a reason they usually want HSMs on-prem.
