Lattice1 Security Features

Lattice1 Secure Architecture
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 - our CEO has demonstrated capturing Ledger PINs and seed 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).
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.
General Compute Environment (GCE)
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 in or goes through the GCE, ever. 
Secure Compute Environment (SCE)
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 image 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.
Tamper mesh
All these secure elements inside the Lattice1 are enclosed in an anti-tamper 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 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).
When the battery runs out, the device will brick and delete all data!
Mailbox, Multiplexer, Doorbell
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) FRAM 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 multiplexer (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.
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. 
Secure Enclave (SE) and SafeCard Slot
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 PUF (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.
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.
Large Touchscreen With Support for Smart Contract Definitions
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.
Signing Process
Here's how the whole communication process works:
1.
A signature is requested via the internet and this request lands in the GCE.
2.
The GCE rings the doorbell to request access to the multiplexer (and the mailbox).
3.
The SCE gives access to the GCE (losing access itself - only one connection at a time can be made).
4.
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.
5.
The SCE reads the signing request from the mailbox, after which it's deleted. 
6.
The SCE draws the device screen image and shows you what you're signing.
7.
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. 
8.
A signed message is retrieved from the SE or the SafeCard.
9.
This message is put into the mailbox by the SCE and access to the mailbox is given to the GCE.
10.
The SCE rings the doorbell to let the GCE know it has a message waiting.
11.
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.

Lattice1 - Previous

Lattice1 Concept

Next - Lattice1

Lattice 1 Power Supply

Last modified 6d ago

Copy link

Contents

Lattice1 Secure Architecture

General Compute Environment (GCE)

Secure Compute Environment (SCE)

Tamper mesh

Mailbox, Multiplexer, Doorbell

Secure Enclave (SE) and SafeCard Slot

Large Touchscreen With Support for Smart Contract Definitions

Signing Process