- 11 minutes
Bunkyr is a key-management system that generates encryption keys to protect a user’s sensitive data through the use of familiar sign-in methods, eliminating the need for paper recovery codes and seed phrases. For example, a user can generate a backup encryption key for their cryptocurrency wallet just by signing in to their existing Google account, without worrying about the underlying complexity. Keys are derived from multiple distributed pieces of information, meaning that, as long as the same information is provided, a user’s key can be regenerated at a later date without Bunkyr ever storing it.
Keys generated by Bunkyr are derived from three components, all of which must be present to reconstruct the key:
While the generated keys can be used for any purpose, Bunkyr is intended to be used as a backup mechanism for encrypted data, to protect against a user losing their password (or other primary key). Users never see any Bunkyr interface, and the complexity of the cryptographic hardware is hidden behind a standard REST API.
Bunkyr’s security is anchored by the hosted cryptographic hardware: each user’s key depends on the unique analog properties of each particular hardware instance. Bunkyr does not know which hardware instances are mapped to a given key - that information is encrypted with a key only provided during the key-generation process. Bunkyr must also be provided the user-specific token by the integrating service provider, which is used as input to the cryptographic hardware. With this architecture, Bunkyr’s system knows neither the hardware instances nor does it have the unique input to that hardware required to generate the key.
The final piece is a token provided by the end user, generally an identifier from the end user’s social sign-in (OAuth) token, provided directly to Bunkyr by the OAuth provider1. Some OAuth providers - such as Sign in with Apple - even return different identifiers for the same user to different sites, meaning that no attacker could obtain this identifier without access to Bunkyr’s internal API keys. This is then combined with output from the cryptographic hardware to generate the user’s final key, which is returned to the integrating service provider for use in encrypting the user’s sensitive data.
When a key is generated for the first time, Bunkyr does generate some components in plaintext, but they are never stored in a manner accessible to Bunkyr - some, like the user-specific token, are returned to the integrating service provider, then securely deleted; others, like the specific hardware instances used, are stored encrypted with a key that Bunkyr does not have access to until it is provided by the service provider.
Magic attempts to accomplish many of the same goals of Bunkyr; namely, both share the primary purpose of seamlessly authenticating and releasing encryption keys for end users. The encryption keys released by Magic are stored with protection from Hardware Security Modules (HSMs) hosted by Amazon Web Services (AWS). The HSMs can perform secure encryption and decryption based on information stored directly inside the hardware, allowing the user’s encryption keys (that are released back for use in the integrating service) to themselves be stored encrypted and controlled by the HSMs. End users directly authenticate with AWS to decrypt their encryption keys using the HSMs, which are then provided back to their browser and/or the service provider that is integrating with Magic.
The validity of these security assertions as they relate to providing non-custodial key management are examined in further depth below.
A sample diagram of how passwordless authentication can be achieved with AWS Cognito is below, obtained from the official AWS blog4.
The section of note in this diagram is under the “Custom Auth Flow Triggers” grouping: in this example, the Lambda functions are written and controlled by Magic, generating the information that is then sent to the user via email. At any point, the entity that controls these functions can modify them or log the values they produce, thus obtaining the link that would be sent to the end user and could be used to log in as them to AWS Cognito.
Even if this is not the exact architecture that Magic has implemented, they are fundamentally still the ones in control of this authentication portion of releasing a user’s encryption keys and thus are always at risk of compromise. Magic (or an attacker with access to their systems) could still do things such as silently changing the user’s email address in their system to point to a malicious one or enabling verbose logging in AWS5. Both would allow malicious access to a user’s account, and as this is how the user authenticates to the HSMs, being able to masquerade as the user grants full access to their keys. As the saying goes, “not your keys, not your crypto”.
Magic claims that they have removed their permissions to use their AWS-hosted HSMs to decrypt a user’s key, and thus only the end user has that access. Permissions in AWS are controlled via Identity and Access Management (IAM) policy documents, with an example below from the IAM documentation6:
On a high level, these policies provide access control to specific actions and services (and individual resources inside services), and these policies are the only way to control resource permissions in AWS. Magic’s removal of the permissions for their HSMs have thus been accomplished by putting into place a policy that explicitly denies access to decrypt using the HSMs (for anyone except the end user).
However, even if Magic has put an extremely strict policy into place, what is stopping them from revoking it? Absolutely nothing stops Magic from regaining access to the HSMs since they always control what policies are active in their own AWS accounts. The access to revoke this policy may be strictly controlled, but fundamentally it is still controlled by Magic and as such could be used by a malicious actor or forced to be used with a court order.
In Magic’s architecture, the end user’s actual key is stored encrypted (with information from the HSMs) in Magic’s infrastructure, so that the user can retrieve it at any point even if they lose their primary device. This would normally be a perfectly acceptable architecture (Bunkyr also stores portions of the key-derivation information encrypted), but only if the key to decrypt such information is not accessible to Magic.
As we have just discussed two possible ways that Magic could regain access to use the HSMs (either by masquerading as the user or restoring direct HSM access), this is fundamentally insecure - at all points in time, Magic has access to both the user’s encrypted key the necessary information to decrypt it!
Magic’s claims of being non-custodial do not hold up under further scrutiny, since they can always regain access to the user’s key without that user signing in. Since those keys can be directly used on the Ethereum blockchain7, they can then be used to, for instance, directly authorize malicious cryptocurrency transactions on behalf of the end user. At the very least, these keys are what ultimately identify the end user to the service provider integrating with Magic, so Magic has the capability to perform any action the user could on that service.
For clarity, Magic appears to be taking satisfactory precautions to protect against these attacks and it would still take a skilled attacker to exploit these issues; none of the analysis above is intended to convey that Magic is using or would improperly use their access to user’s keys, only that they have the technical ability to do so. However, the fact that they do have this access at all means their claims about being non-custodial are misleading.
Bunkyr solves many of these issues, with no ability to arbitrarily reconstruct a user’s key - keys are derived from three pieces of information distributed between Bunkyr, the integrating service provider, and the end user (via their OAuth provider). Further, the information that Bunkyr stores (the mapping of a given user’s key to particular hardware instances) is stored encrypted with a key provided by the service provider, and Bunkyr has absolutely zero access to it except transiently during the process of key generation. This means that, even if an attacker gained total control of Bunkyr’s system, the user’s key is not at risk without further compromises of both the service provider and the end user’s OAuth provider.
As a bonus, with Bunkyr only being the recovery mechanism for a user’s key, a user cannot be denied access to their wallets or other encrypted information if Bunkyr experiences an outage or data loss. With Magic being the primary login method, users could lose access to their funds or other important assets if Magic goes down (or have to go back to relying on seed phrases, which have to be set up in advance and thus may not exist).
Magic has an extremely intuitive login process, but their claims of being non-custodial are generous at best as they (or an attacker who gains access to their systems) can always access the user’s Ethereum private key. Bunkyr can provide the same seamless experience to end users, while eliminating the possibility of users losing assets or having sensitive data leaked if Bunkyr is compromised. Further, an outage or data loss on Bunkyr’s side does not risk end-user data loss, whereas Magic represents a single point of failure for a user’s keys.
All of these benefits come at less than half the cost of Magic, which starts at $0.05 per user per month8. If you’re interested in keeping your users and their important assets truly secure with Bunkyr’s scalable and fast key-management API, we’d love to get in touch. You can request a demo or reach out directly to our engineering team for more information or to get started with the integration process.
The recovery methods are not restricted to only OAuth and can include any source that provides a stable token to Bunkyr, including an installed app or hardware authentication device ↩