Product
Oct 9, 2024
A “Hardware Wallet in the Cloud”: Introducing BONKbot’s Next-Gen Key Management System
TLDR:
We’ve turned BONKbot into a non-custodial “hardware wallet in the cloud” - but WITHOUT compromising on UI / UX or latency.
You’re the only human who can access your private key and initiate transactions.
BONKbot can NEVER censor you.
Use 2FA to protect your BONKbot even if your Telegram is compromised, with Face ID / Passkeys to come.
BONKbot provides instant pre-transaction protection even if underlying smart contracts (Pump.fun, Raydium, Jupiter, etc) are exploited
We’ll be rolling this out to all BONKbot users over the coming weeks.
You DO NOT need to do anything right now - the initial rollout phase is automatic.
At BONKbot, we’re obsessed with creating a more user-friendly, more powerful, and more secure experience for traders like ourselves.
We also hate shitty UI / UX.
That’s why building on Telegram was a no-brainer for us. Fast and mobile-friendly, powerful yet simple - it’s everything we wanted to deliver with the weekend hobby we called BONKbot.
But as users flooded in, we began to see Telegram’s potential to help us deliver a paradigm shift in the crypto user experience for millions of people, not unlike the mobile revolution.
And we weren’t the only ones - BONKbot’s rapid growth formed a key part of Pantera’s thesis for their largest investment ever.
Yet, one of the enduring critiques of Telegram bots is the security risk of being custodial. Using them has been considered an unsolvable tradeoff between better UI / UX and worse security assumptions.
Is that tradeoff worth it? If you’re trading shitcoins - absolutely.
Successful shitcoining is all about speed, particularly clean UI / UX and ultra-fast and reliable trade execution. And you’ll never beat a BONKbot user to a trade if you’re clicking through a website, mobile app, or fumbling with your Ledger, or even using another bot.
Sadly, not everyone is a shitcoiner (yet). And if we’re to onboard millions onto Solana via BONKbot, the tradeoff between security and providing a delightful, powerful user experience is unacceptable.
But what if we could get rid of this tradeoff entirely?
What if BONKbot could be effectively as secure as a hardware wallet, while crucially keeping the slick Telegram-based mobile experience that our users love?
Well, after 9 months of building, we’ve done it.
And we’re thrilled to start rolling it out to BONKbot users over the coming weeks.
Here are the key benefits for you:
BONKbot becomes non-custodial:
You’re ALWAYS in control of your assets
BONKbot cannot block you from using your assets
Only YOU can initiate transactions
BONKbot is protected even if your Telegram is hacked:
Use 2FA to guard SOL withdrawal, private key export, and, optionally, token whitelisting
Face ID / Passkeys to follow
Pre-tx verification protects you even if Raydium, Jupiter etc. are exploited
Custom WASM modules predefine every transaction type's "shape", and verify that each transaction behaves EXACTLY as it should
<0.5ms tx verification with blazingly fast signing
Moving to a seed phrase wallet model:
With one seed phrase, BONKbot can deliver our upcoming multiwallet feature without you needing to store individual private keys for each wallet
It’s important to note that while we have dramatically raised the bar for security, you must still be extremely careful with where and how you store your seed phrase.
Once you’ve exported your seed phrase from our system, we can’t protect you if, for instance, you paste it in your Notes app and your phone is compromised!
First of all - why did we build this ourselves?
Because there’s nothing available that provides exactly the level of security we seek while preserving BONKbot’s slick user experience.
Key management is one of the hardest parts of cryptographic systems in general - not your keys, not your crypto, etc.
Since BONKbot is controlled by the user via the Telegram app, the actual keypair isn’t stored on and controlled by the user's device. Instead, all keys are managed by the BONKbot backend system.
From day one, we’ve exercised the maximum level of security possible over our user's keys under this model. In our first version, we used a cloud key management service (KMS) to securely store the keys and only make them accessible to authorized processes. All keys are encrypted while not in use, and access is tightly controlled so that only the BONKbot backend is able to request signatures by the user's key.
However, we’ve hit the limits of what existing systems can provide:
Relying on cloud KMSs leads to vendor lock-in, limiting our flexibility
The general purpose design of cloud KMSs prevents us from implementing finely-tuned, granular control over the keys, required for securely implementing features like limit orders and more sophisticated and customisable event-driven execution
We want to maximize our security and compliance beyond what we can do with cloud KMSs or third-party KMS solutions
Third-party KMS solutions add unacceptable levels of latency and technical supply chain risk
To achieve exactly what we wanted, a new solution was required - so we had to design and build it ourselves.
Introducing: BONKbot’s Next-Generation Key Management System
The requirements for our system are clear:
No human other than the user has knowledge of and access to the user's private key
This includes anyone working at BONKbot, cloud providers, the datacenter, or anyone else
ONLY the user can initiate transactions
All transactions match the user's intent of what a transaction shall accomplish
Yes - BONKbot is an intent-based wallet! We’ll be diving into the implications of how we plan to take advantage of this in a future article.
The user is protected even if the underlying smart contracts are compromised
Point 3 is reasonably easy to accomplish with applications on a user's device, but to achieve points 1 and 2 on a remote system would effectively be to put a hardware wallet in the cloud. And protecting the user against irregular behaviours of the underlying smart contracts is an unprecedented level of protection that goes beyond robust key management security.
Nevertheless, it’s a challenge we gladly took on, and here’s how we did it.
WARNING: everything below is pretty technical - please enjoy responsibly.
BONKbot’s next-generation key management system (“KMS”) is a custom software & hardware development that implements a Hardware Security Module specifically tailored for crypto transactions.
On the hardware side, we use dedicated server hardware configured and installed by our engineers. All servers feature AMD server processors with Trusted Platform Modules (Version 2). Management Engine and remote management functionality are disabled, and the system is configured to allow Secure Boot of BONKbot signed images. In addition, RAM encryption is enabled.
Crucially, each KMS server can ONLY boot our new key management software.
Our KMS software is a custom unikernel implementation based on a hardened, minimal linux kernel and our KMS application. Kernel and application are baked into a single binary that is directly booted by the server's firmware. The whole boot process is measured by the Trusted Platform Module (TPM) that controls access to the instance's identity key. Only pre-determined firmware, kernel, and application versions have access to the identity key that is controlled by the TPM. Any unauthorized modification of any system component will make the system unbootable and prevent access to the identity key.
This setup allows us to remotely verify that only an authorized KMS application is running on our servers and that all components are in an authorized state. We use the TPM's remote attestation features and the identity key to then set up the KMS master key that is used to encrypt and authenticate all other keys managed by the KMS. The master key itself is shared between all instances of our KMS, but at no point is it available to any engineer. Only authorized systems can decrypt the master key with their identity key.
The KMS application itself consists of two separate processes that run in isolation. These processes are the only code that runs on our KMS servers (other than the OS kernel itself). There is no remote management or shell available. All parts of the KMS application are written in a memory safe language and statically linked. The processes of the KMS application are:
Message bridge:
Sends and receives messages through a message bus to provide an API for the BONKbot business logic, and to synchronize the encrypted key database with other instances of the KMS.
Signer:
Manages storage of encrypted private keys and answers signature requests by the business logic.
Each of these processes is isolated and implemented with minimal permissions. The central Signer process has no access to networking and is not exposed to remote access. It will only accept requests through the Message Bridge.
The Signer generates the user's private key and stores it encrypted and authenticated in a local key-value database. The user's key is cryptographically coupled to the user's Telegram identity so that manipulations of the database do not expose keys to unauthorized users. Only knowledge of the master key allows reading the database.
When a signature is requested, the user's encrypted private key is read from the database, decrypted, used for the signature, and immediately overwritten in memory. The user's key only exists in memory for the time it takes to calculate the signature so that exposure to attackers that have access to the server's hardware is minimized. Even if the AMD memory encryption is circumvented, an attacker will have to perfectly time the attack to gain access to a single key.
But doesn't this make the KMS master key the vulnerable part?
Yes, and that is why we employ a protection method initially introduced by OpenSSH to protect keys against side channel attacks.
Instead of storing the master key directly in cleartext, we instead create a linked list of memory pages that contain random data. The hash of these pages when read in the correct order decrypts the master key. Access to the master key is in turn only realized during key generation and signature requests. We then constantly mutate the list of memory pages and their content to prevent the master key from being leaked to memory scanning techniques. In addition, all power management functions are disabled to prevent freezing memory regions and processes.
How do we ensure that all transactions match the user’s intent?
While the above methods protect the user's private key against leakage, we also have to implement a meaningful method to allow the user (and only the user) to initiate transactions that reflect their intent.
This is where BONKbot's authorization mini-app comes into play, delivered seamlessly within BONKbot. Our authorization infrastructure combines cryptography and human-readable translation to create a "commit-reveal" game that ensures any output accurately reflects the intent of you, the human user.
Whenever the BONKbot business logic requests a signature from a user's key, the signer process generates a human-readable description of the transaction to be signed. This description is sent by the Signer directly to the user via a mini-app. Simultaneously, the Signer generates multiple random strings that each reflect a decision that the user can make about this transaction. When the mini-app displays the description of the transaction to the user, several buttons are made available for the user to express their intent.
When the user clicks any of these buttons, the associated random string is sent back to the KMS application. Only the Signer process knows which random string corresponds to which user decision. No other party can predict or manipulate this communication between user and Signer.
Depending on the user's choice, the Signer will then create the requested signature or deny it. No human other than the user through the Telegram application can signal authorization to the signer. And since the Signer created the human-readable description of the transaction, no manipulation of other parts of the BONKbot infrastructure can trick the user to authorise a transaction that does not reflect his intent.
This process also allows the business logic to request authorization for future transactions. Here, the signer verifies that the future transaction precisely matches the user's intent as communicated at an earlier moment. This allows us to minimize the times that a user has to make a decision and it allows us to automatically create transactions when the user is not responsive - such as is required for limit orders. Still, the user remains in control. Only authorized intent can initiate a transaction signature, and authorization can be revoked by the user at any time.
What if you want even more security?
You’ll be pleased to hear that we also integrate additional authorization methods. Users can enable 2FA if they would like the option to export their private key in the future, and Passkey support (e.g. Face ID / biometrics) will be implemented in due course.
This means that even if someone compromises your Telegram account, they can’t drain your SOL or export your private key without your Passkey or 2FA, keeping your funds safe.
Moreover, we also implement an optional token whitelisting system whereby the user may whitelist each new token they wish to trade via 2FA / Passkey authorization, after which point the token may be freely traded without further authorization. This provides an even further level of protection which prevents transactions from being conducted against any unauthorized tokens, particularly ones that may be toxic or maliciously manipulable.
So how do you protect users against underlying smart contract exploits?
Every transaction is verified to behave exactly and only as it is supposed to against a predefined set of constraints before it is executed - all in less than 0.5ms.
Each transaction type executable via BONKbot (e.g. SOL withdrawal, Raydium v4 swap) is defined ahead of time by a custom WASM module that is hashed and authorized by the user. These modules establish the “shape” of each transaction type by defining a Constraint made up of properties that are relevant to each specific transaction type. Examples of these properties include, for instance, Max_sol, Destination_Address, Mint, etc.
The WASM modules then validate that every user transaction is exactly as defined, with precisely zero added instructions, before execution. Any Transfer, Swap, or even a CreateIdempotent instruction will only output to the user's address or a PDA derived from the user's address.
This set of constraints effectively amount to an intent which can be later executed. This key primitive unlocks a huge design space of secure event-driven execution, uniquely for BONKbot - and we’re excited to share more about our plans for this technology in the near future.
Additionally, we make use of an immutable and non-upgradeable Fee Contract (audited by OtterSec) which wraps swaps and other transactions that result in a positive SOL / output token increase for the user, and verifies that this positive delta indeed occurs. Only after this has been verified is the BONKbot fee transferred to a BONKbot fee address. This ensures that it is impossible for the BONKbot fee mechanism to be misappropriated as a means to drain user funds.
What if Telegram itself goes down? How do you keep the user in control of their assets?
Upon first signing up to BONKbot, the user will be presented with their newly-created seed phrase for local backup. This only happens on account creation while there are no assets controlled by the key yet.
After the user has confirmed possession of the seed phrase with a word-based interaction game, the Signer then prevents future seed phrase access unless Passkeys or 2FA are activated. This ensures that the user always has control over their assets while simultaneously keeping the seed phrase securely protected by the KMS.
So what happens now? When does this KMS go live?
Creating this system is one part of the challenge - deploying it to our existing 416,000+ user base without downtime is the second part.
We will execute a 3-phase rollout as follows:
Phase 1:
Over the next few weeks, we will progressively enable the KMS for batches of users. One after the other, user keys will be migrated from the current system into the new system, and authorization (as described above) enabled. The user will also be able to export their new seed phrase alongside their current private key - although migration will be enabled in Phase 3.
At NO POINT will this require the user to enter a private key anywhere.
At NO POINT will this require the user to transfer any funds.
The user does not have to trigger the process.
Phase 2:
Users will be notified about backing up their private key and seed phrase. This process can be triggered by the user at any point, but over time we will progressively enforce it for all users. This is because having a copy of your private key is essential for you to maintain control over your assets at all times.
In addition, this step is necessary to activate our upcoming multiwallet feature.
At NO POINT will this require the user to enter the private key anywhere.
AT NO POINT will this require the user to transfer any funds.
Phase 3:
We will migrate the old user keys to keys that are generated on the KMS, i.e. the seed phrase wallet received by the user in Phase 1. As part of this process, you will be able to seamlessly migrate your assets from your old private key over to your new seed phrase wallet.
At NO POINT will this require the user to enter a private key anywhere.
At NO POINT will this require the user to transfer any funds.
The user will be asked to authorize transactions within BONKbot.
Conclusion
Once this rollout is complete, BONKbot will have set a new standard for security and user protection, while crucially preserving the UI / UX and ultra-low latency that our users love.
It’s been a long road to get here, but we’re in this for the long haul.
And we’ll never take shortcuts at our users’ expense to give them the experience they deserve.
This next-generation Key Management System is just one element of what we’ve been building at BONKbot, and we can’t wait to share more about what’s to come!