Lattice1 Security Features
Last updated
Last updated
When we designed the Lattice1, the highest priority and our biggest focus was - of course - the security of your funds. The Lattice1 has a smaller attack surface than legacy hardware wallets because it's got two totally separate hardware environments inside the box. We also took into account some unusual edge case attack vectors like reading your inputs from radio frequency emissions - people have demonstrated capturing Ledger PINs and seed phrase words this way without a physical connection to the device. Let's have a look at how the components work together (feel free to come back to the diagram above for reference if needed).
The two separate hardware environments are the General Compute Environment (GCE) and the Secure Compute Environment (SCE, also sometimes called Hardware Security Module, HSM). You can think of them as two independent computers that can communicate with each other (we'll get to how they do this) but they are still segregated at the component level. Both the GCE and the SCE are responsible for different tasks that need to be performed in order for the Lattice1 to properly work.
The GCE software runs on Linux and can connect to the internet (either via WiFi or Ethernet). Our security model operates under the assumption that it's always compromised (even though that is unlikely) - this means that no sensitive data such as your private keys is stored on or goes through the GCE, ever.
The secure part of the Lattice1 is completely cut off from the outside world - it is enclosed in what we call a tamper mesh - more on that below - which prevents physical attacks. The SCE is a microprocessor that runs embedded code in C and is responsible for all actions within the secure part of the device - communicating with the GCE, getting transaction messages signed, generating screen images and more.
There are no factory or engineering debug features that would allow direct access to the SCE. This means you have a flexible always-online device, but your private keys are completely inaccessible from the internet.
All these secure elements inside the Lattice1 are enclosed in an anti-tamper security mesh which is like a tripwire that will erase your secrets if a physical intrusion attempt is detected.
The anti-tamper mesh is a Laser Directed Structure (LDS) mesh - you could say a 3D maze of tiny electrical traces with a waveform running through it constantly. If it's shorted out or the waveform is altered - the device bricks. This essentialy prevents 100% of physical attack attempts.
The security mesh is always active but may be armed or disarmed according to your preference. If you arm the mesh and it detects a tamper event, your Lattice wallet and all secure data will be erased and the device will be permanently unusable. You must choose to arm or disarm the mesh as part of the setup process - this ensures your wallet is protected against intrusion attempts (if you choose to arm) from the moment you create/import it on the Lattice.
The mesh can then be armed or disarmed at any time in System Preferences -> Security & Privacy -> Configure Security Mesh, but this of course requires PIN entry into your device. You can see if the mesh is currently armed or disarmed in the top left corner of the Lattice screen. If your device's mesh has been triggered while disarmed, you will not be able to re-arm it but you will be able to use the Lattice without the mesh armed.
We recommend arming the mesh on for most users most of the time. Keep in mind, though, that if the mesh is triggered while active (e.g. from dropping the Lattice too hard), your Lattice wallet and secure data will be deleted. You may wish to disarm the mesh for e.g. travelling or moving where you'd be transporting the Lattice on a bumpy ride.
Tamper detection is controlled by the SCE and is active even when the device is not plugged in the socket. The Lattice1 has enough power stored in its batteries to power the tamper mesh for around 5 years when unplugged. The battery will also last at least 20 years when plugged in, so you should get decades out of your Lattice1 (at least).
By default, the multiplexer is connected to the SCE, so in order to send a message to the mailbox, the GCE has to request access (the SCE needs to switch the mux connection to the GCE). A set of two simple one-way GPIO connections (one for the GCE and one for the SCE) is used for this - we call this the doorbell.
Both the Secure Enclave chip and SafeCard chips are made with a GridPlus-issued certificate that allows the device to actually use the private keys stored on these chips for signing transaction requests. Inserting a SafeCard or any other card with a PUF without a GridPlus cert will result in the Lattice1 not recognizing the card.
The large 60hz touchscreen is important for both UX and security, the screen image is drawn by the SCE and stored on a graphics RAM (GRAM) which cannot be hacked as it's only a memory. The screen allows you to see what you're actually signing even if your phone, computer, or even the Lattice1 GCE are somehow compromised. Touch display input is sent to the SCE directly via I²C. This diminishes the likelihood of man in the middle attacks like we see with USB legacy hardware wallets.
If you have a hardware wallet and you don't verify what you're signing on a secure screen, you're not getting a security benefit at all.
The components we use for the Lattice1 are sourced from multiple hardware manufacturers in different locations - this means that a supply chain attack would have to span three continents and involve multiple governments.
The Lattices uses a TRNG (true random number generator) to ensure wallets generated on the device or SafeCards using the device offer the highest level of safety possible. We of course also support 24-word seed phrases as per BIP39.
You can read more about random number generation on the Lattice here:
Here's how the whole communication process works:
A signature is requested via the internet and this request lands in the GCE.
The GCE rings the doorbell to request access to the multiplexer (and the mailbox).
The SCE gives access to the GCE (losing access itself - only one connection at a time can be made).
The GCE puts a signature request into the mailbox, switches the mux back over to the SCE and rings the doorbell to let the SCE know it has a message waiting.
The SCE reads the signing request from the mailbox, after which it's deleted.
The SCE draws the device screen image and shows you what you're signing.
After you approve, the request hash is sent to either the Secure Enclave (SE) or an inserted SafeCard to be signed with your private keys.
A signed message is retrieved from the SE or the SafeCard.
This message is put into the mailbox by the SCE and access to the mailbox is given to the GCE.
The SCE rings the doorbell to let the GCE know it has a message waiting.
The signed message is read by the GCE - the message is then deleted from the mailbox and the signed message is passed on to the app that made the request - and the transaction is signed.
Although the GCE and the SCE cannot directly connect to each other, they pass signing requests and signatures through a size-limited (limiting the payload to a fixed memory size eliminates overflow attacks) storage - which we call the mailbox. Only one side can connect to the mailbox at a time. When the message inside the mailbox is read, it's automatically deleted.
This is done through a (mux - data selector), a component that selects between inputs and connects the selected input to a single output line. At a time, the mux can be connected either to the GCE or the SCE - there's never a direct connection between the two, all messages are passed via the mailbox.
The Secure Enclave is where your private keys to the built-in Lattice1 wallet are stored on the device. The SE is actually a chip which has a (you could say it's a physically encrypted flash memory) almost identical to the one used in the SafeCards (and in standard credit/debit cards as well). Each PUF is unique and copies of it are impossible to create.
