Grid+ has talked extensively about the agent (version 1 now known as the Lattice1) in its whitepaper —at a basic level, this device can function as an always-online hardware wallet that the average person can easily use. However, we have designed the Lattice1 to have capabilities that far exceed those of any hardware wallet in existence today. This article will discuss how the Lattice1 device will function as a generalized “remote signer” capable of managing cryptocurrencies, digital identity, and more.

Remote Signing

Consider a standard mobile (or desktop) cryptocurrency wallet. One could argue that every wallet application consists of three technical components:

User Interface: This is the main logical element of the wallet. It interfaces with both the persisted user data (e.g. cached addresses and transaction history) and network nodes (e.g. a Bitcoin full node), which allow it to display account information to the user. Transaction Builder: This component is responsible for applying the protocol of the given blockchain network (e.g. Bitcoin) to convert parameters (e.g. “to” address, amount to send, etc.) into one or more hashes that make up a transaction. Note: in Ethereum, each transaction is represented by a single hash, whereas in Bitcoin each consumed input has its own hash to sign — there can be one or many inputs per Bitcoin transaction. Transaction Signer: This is arguably the most important part of the wallet application. This is the logic that uses a private key to cryptographically sign one or more hashes and returns the signature(s).

In this context, we get a sense of how a cryptocurrency wallet application can be logically separated into components. Although all of them are important, I want to focus on the latter two pieces.

Separating the Signer

As a thought experiment, let’s consider what it would look like to remove the transaction signer and put it on, say, a cloud computing machine:

Logically, this functions as before (now with more network interfaces), but of course if you’re reading this you’ll know the obvious problem with this design: you have to store your private key on the cloud.

Now bear with me, but let’s extend this thought experiment to now throw the transaction builder in the cloud too:

What we are left with is the bare minimum functionality for a wallet application: the user interface. Without having to worry about the protocol-level mechanics of building transactions or cryptographically signing them, developers are able to spend more time competing on the best looking, most useful wallet application that they can build.

In a sense, this is exactly what we are building with the Lattice1: we have separated the protocol and cryptographic functionality away from the application layer. Of course, we aren’t storing any keys in the cloud: we’re putting them in a secure chip within the Lattice1.

Securing Components and Separating Concerns

Although you may not think of it this way, existing hardware wallets already separate the Transaction Builder and Transaction Signer components from the wallet application. This is why you are often able to utilize your favorite wallet application UI with a hardware wallet.

However, one could argue that existing hardware wallets make a major sacrifice in usability by requiring the user to plug in and unlock the wallet every time she wants to use it. This may be fine for low-volume use (e.g. moving coins every few months), but it will not suffice if we are to use digital signatures (from securely stored private keys) in our everyday lives.

The Lattice1 introduces a more usable, robust, and secure connection between application and transaction builder/signer components.

The above figure shows the breakdown of our separated wallet components in terms of Lattice1 hardware:

Standard Chip: For now, this chip simply manages a connection between the application(s) and the secure chips. This is what distinguishes the Lattice1 from other hardware wallets, as it facilitates a wireless interface between application UI and Transaction Builder/Signer components. We will discuss this interface more in the next section.

For now, this chip simply manages a connection between the application(s) and the secure chips. This is what distinguishes the Lattice1 from other hardware wallets, as it facilitates a interface between application UI and Transaction Builder/Signer components. We will discuss this interface more in the next section. Secure Chip 1: This holds the Transaction Builder component, which is responsible for building transaction hashes from input parameters provided by the application requesting the signature. This chip exists only on the device.

This holds the Transaction Builder component, which is responsible for building transaction hashes from input parameters provided by the application requesting the signature. This chip exists only on the device. Secure Chip 2: This holds the Transaction Signer component, which again is responsible for securely holding private keys and making signatures. This chip exists both on the device and in each Safe Card.

We will soon discuss what guides the Transaction Signer to actually make a signature. But first, let’s see how an application can make a connection to the device.

Making a Connection

The process of connecting begins with what is known as a pairing, which is established through a key exchange protocol somewhat similar to Bluetooth. This pairing is represented by storage of a curve25519 public key on-device, which comes from an ECDH key exchange between the application (which holds the corresponding private key) and Secure Chip 1 on the Lattice device (which generates a unique curve25519 key pair of its own for this pairing). Note that this key pair is completely separate from any cryptocurrency-related private keys, which are stored in Secure Chip 2.

Suppose an application wants to pair with a user’s Lattice1 device. Let’s walk through the setup process. Note that the following screens come from the Grid+ mobile wallet application, which is currently under development. However, any application UI would be capable of making this connection via the Grid+ Software Development Kit (SDK), which we will discuss soon.

Step 1: Find device by serial number

The first step to pairing is to find the user’s agent based on a serial number. Note that this step may not be necessary if the Lattice can connect with the app on a local area network. This is an option we plan to explore in the future.

Step 2: Transfer a Secret Code (Out of Band)

Once the app can talk (insecurely) to the Lattice1, the next step is to generate a secret code on the application side and sign a hash with that code using a secp256k1 private key (the application needs both this and the curve25519 key, which is used for encryption/decryption).

When the user presses the “Pair” button, the application will send a message to the Lattice requesting that the pairing process begin. Once the message is received and parsed, the Lattice1 displays a place for the user to enter the same code that is displayed on the application.

If the user enters the code correctly, the Lattice1 can recover the secp256k1 public key used to sign the hash and stores both that and the curve25519 public key, which is also sent in the payload.

Step 3: Establish a Read-Only Permission

Once paired, the Lattice1 will give permission for the requesting app to view addresses and a few other pieces of data (obviously not including private, or even public keys). This permission can also be used to request signatures that the user must authorize on the screen of the device. This could be useful if an app needs the user to trigger a one-off signature (as opposed to automated signatures).

State of a Pairing

In summary, a pairing is created by a user entering a pairing “code” out of band (largely to prevent man-in-the-middle attacks).

The app stores the following:

A 32-byte private key

The Lattice device stores the following (in the single pairing object):

The secp256k1 public key, which is used to check signatures on future requests The curve25519 public key, which is used to decrypt payloads of future requests

With this setup, the application has established a secure connection. There is a bit more complexity left undiscussed (such as using 1-time keys for future requests and a separate pairing code generated by the Lattice1), but the above should leave you with a general idea of what’s going on.

Remote Signing

Now that the application is paired, we can use it as a generalized Transaction Signer, just like any other hardware wallet. Unlike other hardware wallets, however, the paired application is capable of communicating with the device wirelessly.

Once the pairing is established, we are now able to request a signature on some piece of data, which is of course parameterized and built in the Transaction Builder (on Secure Chip 1).

Manual Remote Signing

As mentioned above, the pairing process also creates a minimal “permission”. The application may request a signature using this permission in a way similar to existing hardware wallet transactions: the Lattice1 device displays transactional data to the user and must wait for the user to hit “accept” on the touch screen.

However, there are a few technical differences that are worth noting:

The data must conform to a pre-defined “schema”. These will periodically be released by Grid+ as use cases emerge. Examples might include ETH transfers and BTC transactions (either P2SH or P2PKH — we anticipate releasing with segwit functionality using wrapped P2SH transactions). The app must have permission to send these requests in the first place. If this permission is turned off (or was never created), all manual requests will be rejected automatically.

If these conditions are met, the app can request a signature and the response will be returned to the app once the user accepts on her agent device.

Automatic Remote Signing

Perhaps the more interesting functionality is that of “automatic” remote signatures. Examples include recurring payments and keep-alive messages.

Automatic signatures utilize what we call “recurring permissions”, which require a pre-defined schema (just like manual signatures) in addition to a set of “rules” on the data that will be signed in the future. Such a permission might look like this:

{

schemaIndex: 0, typeIndex: 0, rules: [ null, null, null, null, null, null, null, null, null, 'equals', '0x39765400baa16dbcd1d7b473bac4d55dd5a7cffb', null, 'equals', 1000, null, 'equals', '', null, ], timeLimit: 10000

}

Let’s go through it line-by-line:

The schemaIndex corresponds to a published “schema” to which remote signature requests will conform. In this case, 0 represents an Ethereum transaction.

typeIndex indicates a specific type of Ethereum transaction. It is a set of further restrictions for the schema type. In this case, 0 represents a standard Ethereum transaction, which means the data field must be equal to '' . This is another way of saying only ether transfers are allowed within the context of this permission.

rules correspond to specific rules on variables in the payload. For example, an Ethereum transaction looks like this:

[ nonce, gas, gasPrice, to, value, data ]

The rules correspond to these parameters in order, with each rule itself being a three-item array of format: [ typeOfRule, value1, value2 ] . The last value is often left empty and if no rule is prescribed, the requester can set the whole row to null .

The above rule set is saying that only requests sending exactly 1000 wei to address 0x39765400baa16dbcd1d7b473bac4d55dd5a7cffb will be accepted.

Finally, timeLimit indicates how many seconds must elapse between requests. In this case, the requester can only send a request once every 10,000 seconds. One second (or more) too early and the request will be denied.

Application SDK

All of the previously discussed functionality is made possible through a Grid+ Software Development Kit (SDK); this SDK will be released as an open source node.js module. We hope that developers wanting to build applications with a separated, internet-connected, secure signing service will experiment with the SDK and integrate with the Lattice1 device. Although Grid+ is building a mobile wallet application, this too will be open sourced as an example of how to leverage the Grid+ SDK.

Although the API is not finalized yet, the below Javascript snippet is an example of what using the SDK may look like:

const Sdk = require('gridplus-sdk');

const sdk = new Sdk({ btcNode: 'localhost:48332', ethNode: 'localhost:8545' });

const req = {

type: 'eth-transfer',

rules: {

value: { 'equals': 1000 },

to: { 'equals': ' 0x39765400baa16dbcd1d7b473bac4d55dd5a7cffb' }

},

interval: 10000

} sdk.createAutomaticPermission(req, (err, res) => {

... do stuff ...

})

Keeping it General

Although this article mostly discusses the Lattice1 remote signing functionality in the context of cryptocurrency transfers, it is important to highlight that using an abstracted “signer” allows applications to request signatures on any data that is parametrizable. One can imagine, for example, a data schema that represents parameters of a legal contract:

{

signer: "Amy Joe",

timestamp: "09-10-2018Z22:00:00",

counterparty: "Bob Ross",

data: "This is a legal contract. Signer agrees to pay counterparty 1 BTC by 09-10-2019Z22:00:00."

}

Just like an Ethereum transaction, this schema could be serialized and hashed according to some agreed-upon protocol. Amy Joe’s signature on this piece of data would represent her commitment to the expressed legal contract.

This is just one example of the utility of digital signatures. Grid+ believes the biggest blocker of this utility is access to a secure, available signing service. With the Lattice1, the key used to sign this (and other legal contracts) is controlled by the user, but accessible to any application that the user chooses to pair.

We hope that this article sheds a bit more light onto what we are trying to accomplish on the Lattice1 side at Grid+. As mentioned in the previous article (and whitepaper), the first application of this remote signing functionality will be the Grid+ Texas electricity retail service. We hope that this will jumpstart an ecosystem that leverages our new infrastructure to utilize digital cryptographic signatures in new and unique ways.