It was unfortunate to read of an attack on the Bitcoin ATM industry last month, perpetrated against General Bytes and operators of their software stack. Any such attack undermines confidence in our industry and the work we've set out to do, which is to create simple, ubiquitous, and trustless onramps to Bitcoin acquisition. While our approach differs from that of General Bytes, our missions are shared, and there are lessons the industry as a whole can apply.

From the vulnerabilities we've seen exploited in the GB software, both last month and last year, we've garnered takeaways for our own software stack, some of which we're detailing here, along with the advantages to security which our operator system already provides.

Our approach

From the first release of our operator admin, we've taken a decentralised approach that removes as much trust in central services as possible. Operators run their own server, hosting their admin and wallets, secured by their SSH keys alone.

Early on, we decentralised further aspects, moving from third-party wallets to wallet nodes like bitcoind, and from a central service providing backend support for cash-out functionality to one hosted on the operator's own server.

Always, operators have enjoyed full access and permission over every piece of code that runs on their admins and machines. Fully-published, open to inspection, and free to modify.

Our approach has been one of solid fundamentals. All of the communication entry points are secure with tried and tested cryptography. Our machines perform certificate-based authorisation. Our admin requires TOTP 2FA, and you can even enable FIDO2.

Server infrastructure

Your Lamassu server instance is not shared. You are the only one that has access to it and it only talks to the services and machines you want it to talk to.

By design, Lamassu holds zero access to operators' servers, wallets, database, admin, transaction data, or even logs. Admin servers do not report back to us, so we have no knowledge of where they're hosted.

Data such as this we treat as toxic waste, and our aim has always been to be as zero-knowledge and permissionless as possible. While this approach can make support slightly more challenging (operators must volunteer logs, for example), it ensures there's no central point of attack upon funds (or for downtime beyond operators' control).

Machine security

Operators' machines pair with their admin servers via cryptographic certificates, and communicate via TLS-encrypted connections. These certificates ensure only machines originally authorised for a specific server can generate transactions. All unnecessary ports are firewalled, only permitting those for communication with operators’ servers and our update server.

The data which machines can upload to operator servers are also very limited, consisting of crypto addresses, ID and customer photos, and text entry, all of which are sanitised and none of which are executed. The most recent security issue on General Bytes machines was the result of servers running arbitrary data that was uploaded to them. No such operations are performed by our operators' servers.

Additionally, if you choose to offer paper wallets through your machine, the private key never leaves the machine, and only exists for the duration of the transaction and is immediately destroyed.

Updates

We have very limited communication with the machines: we can either update them or ask for debug logs. All of this communication is secured with a multisig GPG signature, so only things properly signed by us are executed on the machine, and only packages which have originated from our update server.

Operators alone have the ability to update servers. Server updates are accomplished by running a script which pulls down a pre-packaged server package, the hash of which is checked to ensure its integrity.

What’s next

We are working to deprecate the small amount of machine communication we currently perform by empowering operator servers with this functionality. This means that, while we are continuing to sign our update packages with the GPG schema, we don't want the power to push these updates ourselves.

We're also working on machine builds that are reproducible on the checksum level. Currently, if you build the packages yourself, you can diff them to check that files are exactly the same as ours, but because of compression metadata it also has a different checksum.

Lastly, we’re taking the steps to officially release our lamassu-server docker images. Once those are live we can lower the attack surface and improve both the reliability and cadence of our releases. In combination with a self-hosted npm registry, this also greatly reduces the risk of supply chain attacks, which right now are mostly being prevented by pre-packaging the server and manually pinning dependencies.

Hearing from you

To be clear, in our ten years there has not been a known exploit of our software. That's not to say it's invulnerable, or that some operators haven't followed our full precautions for securing their setup. Though it does speak to our approach, and the advantages of developing in the open. Quality software written from scratch is difficult. Securing it especially so. And it's all the more important when real money is on the line.

The beauty of source-available software is that you thankfully don't have to trust us on this, as everything is verifiable in our codebases.

Please reach out to us if you have any questions about our software and security precautions: inquiries@lamassu.is

If you should uncover any concern about a potential vulnerability in our software stack, we ask that you contact us securely over Signal.