Introduction to Sepior Key Management
as a Service (KMaaS)
Sepior KMaaS in a nutshell
Sepior makes it easy for SaaS-providers to encrypt their customers' data in a way so that the
customers retain full control over the encryption keys.
Sepior uniquely provides client-side encryption and key management in a manner which is
100% cloud-based without compromising on security.
This is made possible through the application of Multiparty Computation, an exciting research
area within modern cryptography.
100% cloud-based yet secure
Forms of “encryption as a service” have been available for some time now from what industry
analysts have referred to as Cloud Security Gateway (CSG) or Cloud Application Security
Broker (CASB) vendors. CSG/CASB providers offer a range of features from data loss
prevention to malware protection, intrusion detection, and encryption and key management.
Sepior focuses solely on the encryption and key management dimension of such systems.
The typical architecture used by a CSG/CASB when encrypting data stored at a SaaS-provider
is the so-called proxy integration model. This model is similar to an application level firewall, and
all calls to the protected service (e.g. Salesforce) must be routed through the proxy (so that data
can be intercepted and encrypted). To achieve this, the proxy must replicate the API of the
protected service.
Sepior’s integration model relies on working together with the SaaS-provider to ensure
seamless integration of the required encryption functionality. To this end, Sepior’s service
exposes a KMaaS API which is integrated directly into the SaaS-provider’s protected service
(e.g. in the JavaScript in the browser). Alternatively, Sepior has integrated with selected IaaS
providers such as AWS, Azure, and Google to allow 3rd party (using Sepior’s KMaaS) encryption
of customer data in those services.
Another concern to consider for CSG/CASB providers is where the service is deployed. This
can fundamentally be split in two options: on-premise or cloud.
This decision is particularly relevant for encryption and key management. The U.S. National
Institute of Standards and Technology (NIST) - the federal technology agency that works with
industry to develop and apply encryption technology and standards - states:
“It must be noted upfront that in all architectural solutions where cryptographic keys are stored
in the cloud, there is a limit to the degree of security assurance that the cloud Consumer can
©2015-2016 Sepior ApS - All Rights Reserved
Page 1
expect to get, due to the fact that the logical and physical organization of the storage resources
are entirely under the control of the cloud Provider.”1
In essence, NIST is saying that the cloud model for deployment cannot be fully secure.
An important consequence of Sepior’s novel technology based on Multiparty Computation is
that this statement is no longer true - more on that below.
The benefits of using a cloud-based deployment model are the traditional cloud benefits like
reduced capital and resource investment, scalability, and improved user experience.
The other option, the on-prem-model, is able to provide a very high level of security, but it incurs
a high cost for installation, operations, and maintenance.
In summary the existing market basically presents a business who wants to protect their data in
the cloud with a trade-off between two paths:
1. Choose security through an on-premise solution, or
2. Choose ease-of-use and cost-reduction through a cloud-based solution.
With Sepior you can get both!
The Sepior solution
Distributed trust
From a security point-of-view, the core idea is that instead of trusting a single cloud provider (or
a SaaS-provider) you just have to trust that some (chosen) number of cloud providers do not
collaborate against you or that the same number of providers are not compromised
simultaneously. We call this distributed trust.
The way our system works is that an instance of the Sepior Key Server will be running on
multiple servers provided by different IaaS/PaaS providers (e.g. AWS, Rackspace, IBM, Azure).
If desired these can also be in different jurisdictions (EU, US, etc.).
As an example of a file sharing application, say this number (called the trust threshold) is 2. To
ensure availability we use redundant servers – say we have three servers total. We denote this
a 2/3 setup. As long as no two servers are compromised the confidentiality of system is intact,
and as long as no more than one server is down the system is available.
Our protocols are designed to work for any T/N setup as long as 1 ≤ T ≤ N. In practice a realistic
configuration may be an 8/10 setup, and KMaaS may scale to a setup as large as 97/100 with
further optimization using tailored algorithms (such a setup would be extreme and it may not be
a best practice to expect 97 servers to be available at all times).
1
http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7956.pdf - p.16.
©2015-2016 Sepior ApS - All Rights Reserved
Page 2
In other words, if you use an 8/10 setup, the two core threat actors against the system are
mitigated as follows:
●
●
A malicious insider at a SaaS-provider must work together with insiders at 7 other SaaSproviders.
The outside attacker must compromise 8 different SaaS-providers.
With respect to availability, even if two of the 10 SaaS-providers running key servers are down,
the system will still work.
High-level architecture
A concrete running instance of Sepior will have a number of components and actors. While
various integration scenarios are possible, one such example is a SaaS-provider who supports
Sepior KMaaS as an add-on to their standard service plans. In this scenario, the main actors
are:
●
●
Partner or the SaaS-provider - the SaaS-provider who has integrated with the Sepior
KMaaS API using the Sepior SDK.
End-customer - the customer of the SaaS-provider; the main actors are the employees
of the end-customer who are using the application from the SaaS-provider, as well as
one or more admins with control over who has access to the system and who may
monitor the key servers.
The core component is the key server. A key server is responsible for doing the key
management and cryptographic operations. In the specific example integration scenario
described above, the setup will consist of N key servers running at locations chosen by the endcustomer and configured with a threshold T also chosen by the end-customer.
©2015-2016 Sepior ApS - All Rights Reserved
Page 3
From a security point-of-view the system has the following properties:
●
●
●
●
●
●
Distributed trust - the T/N setup.
All keys are generated in a distributed fashion by the key servers. As can be seen in the
diagram, a key is split into N shares. Each share contains no information about the
actual key, and no key server ever sees more than its own share of the key!
Encryption is done using a stream cipher built from AES-CTR.
The key servers will support two different modes of operation
○ Cloud-side: the file is sent (encrypted using a temporary key) to the key servers
that perform the encryption.
○ Client-side: the shares stored at each server are exported to the client needing to
do en- or decryption.
The key servers may optionally support pro-active security, meaning that all key material
is replaced at regular time intervals by re-encrypting (re-keying/key rotation) the file
under a new key.
No matter which mode of operation is used for encryption, decryption, or re-encryption:
○ No key server sees anything but its own share of the key
○ No key server sees cleartext file
The alternate modes of operation have different pros and cons:
En-/decryption
Pros
Cons
Cloud-side
Keys are never recombined.
All files to be encrypted
must be sent back and forth
between the client and the
key servers.
Client-side
Only a very small amount of
data is sent between the key
server(s) and the client (128
or 256 bit per key server)
Keys are recombined.
However Sepior uses a
unique key for each file and
each key is only recombined
on clients with that exact file.
So if the client is
compromised the attacker
might as well exfiltrate the
cleartext file.
Customer experience
To offer Sepior KMaaS as part of a SaaS solution, the cloud service provider (Sepior’s partner)
must integrate the SaaS application with the Sepior Key Management System. To do this two
things must be done:
1. Users and objects in the SaaS solution must be mapped to the domain model used by
Sepior.
2. The application code must use the Sepior SDK to access keys and do crypto operations
(SDKs are currently available for Java, JavaScript, C#. Other platforms like iOS and
Android will be available in the near future).
©2015-2016 Sepior ApS - All Rights Reserved
Page 4
For the end-customer (the customer of the SaaS-provider), the tasks to start using Sepior
KMaaS are as follows:
1. Decide where to run key servers.
2. Configure how users authenticate towards the key servers.
3. Deploy and monitor the key servers through a portal provided by Sepior.
Sepior’s KMaaS is the industry’s first true cloud-native KMS based on distributed trust. Sepior
invented the cryptographic protocols required for a practical Virtual Hardware Security Module
(VHSM) leveraging Multi-Party Computation (MPC) – the enabling technology behind the
KMaaS. Sepior gives businesses full control over the encryption keys used by their SaaSproviders without relying on any single SaaS-provider, and at SaaS economics.
©2015-2016 Sepior ApS - All Rights Reserved
Page 5