Managing Cryptographic Keys

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on email

Recently, Slack announced their new Enterprise Key Management (EKM) product, which allows users to manage the cryptographic key material used to encrypt (and authenticate) their data hosted in Slack. Here, we will briefly look at why Key Management matters, what we like about EKM and what we think is missing.

Keys Are Power

Key management is one of the most important and challenging aspects of using cryptography correctly. Whoever controls the keys controls the data. Deciding how keys are managed determines how power and control are distributed amongst participants. The challenges this involves grow increasingly in larger organizations, which will likely have a myriad of users, data, groupings and subgroupings, projects, work flows, etc. Each of these aspects imposes new restrictions and requirements on how, when and by whom any different data should be accessible. All of this needs to be reflected in how the key material protecting the data is managed. Who has access to a particular set of keys and under which conditions? Where and how is key material stored? Who can create, refresh, distribute, revoke and delete key material? These are the kinds of questions that any comprehensive security strategy will have to address under the umbrella of Key Management.

Recognizing the importance of this (not to mention at the request of users with legal and regulatory Key Management requirements), Slack has introduced its EKM system, which lets its users store, manage and use their keys via Amazon’s AWS Key Management System (KMS). While details about how exactly Slack’s EKM solution works don’t seem to be public knowledge yet, the general idea seems to be that users’ key material is stored by Amazon, which manages (and uses) it at their discretion.

A Step in the Right Direction

Without a doubt, allowing users a more fine-grained control of their keys — not mention encouraging them to be more mindful (and hopefully systematic) about their key management policy — is a valuable contribution to the wider state of security and a step in the right direction for everyone involved.

Moreover, an optimistic reading of the press releases around EKM leave open the possibility that the system is designed to significantly reduce the trust Slack’s users are forced to place in Slack itself. For example, if Slack’s users authenticate themselves directly to Amazon, then Slack may no longer have access to users’ keys (assuming, of course, that Amazon enforces such restrictions). In other words, users no longer need to trust Slack with (at least some) of their data.

If EKM is indeed designed with this property, then it reflects part of an important “best practice” principle in security design: minimal necessary privileges. If you don’t really need access to some piece of data, then you should not have access to it. If you don’t need to have a particular capability, then you shouldn’t have it. Concretely, if Slack doesn’t need access to its users’ data then, all things being equal, it’s better if they don’t have access to the data.

The Path Left Untrodden: End-to-End Security

It’s hard to understate the importance of least necessary privilege when designing security solutions. Moreover, the truth is that we could ask for a lot more privilege reduction than EKM seems to provide. Ideally, we should be shooting for end-to-end security and access control models. After all, only the user needs access to their own data. So what we want is a key management system where only the user has access to the keys (and thus the data).

Unfortunately, it looks like for EKM this won’t be the case. While the details remain unclear, one thing does look pretty certain already; EKM involves generating, storing and managing the entire life cycle of keys in the AWS cloud. Ultimately, this means that Amazon — not the user or Slack — owns those keys. In reality, this means that Amazon has access to data. And that, pretty clearly, violates the least privilege principle.

Why does that matter? Well, it introduces unnecessary risks. While it may often make engineering or financial sense to host encrypted data in the cloud, we believe the argument for doing this with key material is much weaker. Using EKM, all Slack users are forced to trust Amazon in a very strong sense. Users’ keys are hosted on devices they neither own nor control, managed by personnel they can’t vet and are subject to legal/regulatory court orders they have no visibility into. In fact, since they don’t own the devices hosting the keys, they don’t really have any way of knowing if or when the key material is accessed beyond what Amazon tells them.

At the end of the day, only users need access to their own data. Not their ISP, not their SaaS providers and not third-party cloud providers. That’s why Wickr’s platforms are all designed with end-to-end security in mind. When it comes to key management, all key material is managed directly by end-points — i.e. by the users themselves. Wickr doesn’t manage keys on users’ behalf, nor outsource key management to any third party. Instead, Wickr’s job is to provide its users with tools they need to intuitively (and transparently) manage their keys on their own.