Appearance
Access Control
SplitSecure is a distributed hardware security module. What that means is that we take secrets like keys and credentials and split them across multiple devices, leveraging the hardware security claims of each device. This allows us to offer superior claims to traditional hardware security modules, while being cheaper, more performant, and easier to manage.
Let’s give an example. Say your company has a server that requires SSH credentials to access. With SplitSecure, you can distribute the secrets required to access your server among the employees who are authorized to grant access to that server. The team collectively acts as a hardware security module protecting your secrets, but there is no single user who can grant themselves access, and there is no central system responsible for enforcing key access policy.
This is not only better security, it’s a better user experience. SplitSecure’s distributed approach means your team doesn’t have to struggle with HSMs or keep admin credentials hidden away for an emergency. You get all the convenience of a modern two-factor auth approval flow, with security claims as strong as a FIPS-140-3 Level 3 certified HSM.
TIP
And yes, we’re quantum resistant! SplitSecure’s hybrid cryptography supports pre and post quantum signature and key exchange algorithms.
The idea of using multi-user approval flows to gate access to critical secrets is not new, but historically it has been difficult to implement and inconvenient for use in enterprise. SplitSecure offers the simplest, easiest to implement, most customizable solution in-market, all while maintaining best-in-class security claims.
Let’s walk through the SSH server access example in detail so you can get a clear idea of what it’s like to use SplitSecure.
Example: SSH Server Access
SampleCo has a server that contains sensitive customer information. Access to the server that contains this information is protected by SSH, and the SSH credentials are protected by SplitSecure. An engineer, J. Doe, needs access to the server to perform a routine update.
With SplitSecure, the user never accesses the secret directly. Instead, they propose that an action be performed with the secret on their behalf. In this example, J. Doe opens the SplitSecure CLI and proposes the Grant Ephemeral SSH Certificate action. They are prompted for the information that action requires: how long should the certificate last, and to whom should the credentials be issued?
They select 30min as the duration of the ephemeral certificate and specify their own public key as the recipient, sending the proposal.
SampleCo’s process is that at least three engineers on the Core Security Team must approve access to the server, and that approval requires biometrics. Within seconds of J. Doe sending their proposal, the engineers on the Core Security Team get a Slack notification (or PagerDuty, or a push notification, or an email depending on settings) asking them to review the proposal. When they open SplitSecure, they find a request for a vote signed by SampleCo’s trusted execution environment.
The request for a vote contains all the information they need to know what they’re being asked to approve:
EXAMPLE
- Requested Action: Grant Ephemeral SSH Cert for (Server ID)
- Action Settings:
- Credential Duration: 30min
- Authorized Credential: (J. Doe’s Public Key)
SplitSecure supports biometric authentication on the iPhone and SampleCo’s security threat model allows it, so the engineers on the Core Security Team can approve the request through the SplitSecure mobile app.
TIP
This simple multi-user approval process (“At least three people must agree”) is not the only access control process SplitSecure supports. We support fully arbitrary single or multi-user approval processes, which can include multiple teams, hierarchies of users, or backup devices.
“This action can be approved by the engineer currently scheduled as on-call,” is a valid SplitSecure approval process. So is “the action must be approved by at least one C-level officer, two staff engineers, and an IT manager.” We’re highly flexible to different use cases.
Once at least three engineers mark the request for a vote as approved and biometrically authenticate on their iPhones, the proposal is approved. The trusted execution environment then sends a record of the vote to the audit log, and in return receives the final secret required to perform the operation. This ensures all operations are logged.
This process occurs almost instantaneously, and once logging is complete, J. Doe is issued the ephemeral SSH cert.
What Makes This Valuable
Ease of Use
The user experience in this example might not seem very different from the standard enterprise two-factor auth user experience: a user requests access to a secure system, the appropriate authorizer(s) gets a push notification asking them to review the request, and the authorizer(s) can approve or reject on their mobile device.
It doesn’t seem different because it isn’t different. SplitSecure’s UX very closely mirrors that of common enterprise two-factor auth applications. But SplitSecure does this while maintaining security claims equivalent to a FIPS-140-3 Level 3 certified HSM, and anyone who has worked with HSMs will affirm they are not that easy. We offer best-in-class security claims, with a UX that any user will find familiar and comfortable.
Good security doesn’t have to be hard to use. SplitSecure offers security suitable for protecting root accounts, break glass accounts, legally protected customer data, crypto wallets, and bank accounts, and does it in a package anyone can learn to use in minutes.
Cryptographically Secured Assurances
In the above example, J. Doe was not asking the team’s permission to access the server. He was asking them to use the cryptographic information stored on their individual devices to help mint the SSH cert. This gives strong cryptographic assurances that it is impossible to use the secret unless the specified approval criteria are met.
When enterprises deploy SplitSecure, they specify a number of teams – groups of users or devices. Each of these teams protects one or more secrets, and can authorize action to be taken with those secrets. The protected secrets are then broken up into shares, stored across the team’s devices. There is no central system that retains the secret.
What about the trusted execution environment?
SplitSecure uses a trusted execution environment (TEE) to coordinate the recombination of secret shares. This TEE has no privilege over the devices that store the shares, and by leveraging AMD SEV-SNP and Intel TDX technology, we can assert the secret shares are only ever unencrypted in-processor and no information is retained.
While an attacker could theoretically extract the secret by performing a highly sophisticated physical access attack on the TEE processor while the secret was in-use, the only organizations that reasonably have the ability to execute such attacks are major intelligence agencies. This is outside the threat model of most enterprises.
All of the rules SplitSecure enforces are enforced by how the secret is split. In the above example, SampleCo’s rule was “at least three engineers can approve access,” and so the secret is cryptographically split in such a way that at least three shares must be provided to mint the SSH cert. To enforce different rules, SplitSecure splits the secret differently, but the rules are always enforced by the cryptography of how the secret was split.
For an attacker to extract a secret from SplitSecure, they would need to steal enough of the distributed devices to meet the approval conditions and provide credentials (password, biometrics, etc) for each one. In the above example, they would have to steal three devices from the SampleCo Core Security Team, and then simultaneously provide credentials for each one – all before the theft was reported and SampleCo invalidated the devices.
Redundancy
With SplitSecure’s distributed cryptographic protocol, secrets are split across multiple devices, and approval processes are run by teams instead of by individuals. This ensures that no single employee has access to any secret, and that no employee is alone in being able to trigger any secure process. This protects enterprises from damage caused by the loss of critical employees or insider threat.
SplitSecure ensures you never risk losing a key again – accidentally or maliciously.
Least-Privilage Access
With SplitSecure, the user never accesses the secret directly – they request an action be taken on their behalf. Actions taken with the secret are executed in the SplitSecure trusted execution environment, using enclave services. Services are provided by SplitSecure for common use cases like minting certificates and keystore services, and enterprises can create custom enclave services to serve unique use cases.
This means that your security team can enforce a policy of least-privilege access. Secrets never need to be extracted from the network, and your security team can always approve the smallest possible action.
Flexibility
SplitSecure can be run on a wide range of devices – whatever is most suitable to the customer’s threat model. In this example, SampleCo used iPhones as their network devices, but other companies might allow android devices, while others might insist on FIPS-140-3 Level 3 certified USB devices.
Customers can also create custom enclave services to fit their unique use case. If an enterprise has a custom tool, they can allow SplitSecure to interact with it to securely take actions like adding new users or modifying settings.
Because SplitSecure allows custom actions and leverages the security claims of the hardware it runs on, it is easy to customize to a variety of use cases, industries, regulatory environments, and threat models