Although we have talked at length about the Lattice1, we have not yet given an in-depth view of its companion — the SafeCard. This article will attempt to outline our vision for the SafeCard as both a cold storage option and as a mechanism to scale public blockchain networks.

Background

The SafeCard is meant to be a PIN protected, unpowered physical key store. This allows storage of digital secrets offline, but also gives a familiar experience of spending money with a chip card.

GridPlus is using the Status Keycard Applet as a template for the SafeCard Applet. We are also using the accompanying Keycard SDK. As such, we are designing the SafeCard to be at least partially interoperable with the Status Keycard.

The SafeCard applet was developed using Status’ Keycard Applet and SDK

Unique Features

Although the SafeCard applet is a fork of the Status Keycard applet, there are a few differences that we have implemented:

1. Master seeds are stored on the card and may (optionally) be exported

This option is declared when the seed is generated or loaded and may not be changed once set. If the user wishes to export a card’s seed, an interface must establish a secure connection with the card and pass the correct PIN to export the seed. If the user chose “no” to exportability when the seed was loaded/generated, the seed cannot ever be exported from the SafeCard.

Status does not currently store or allow export of master seeds (instead it stores the parent private key, a derivative of the master seed). This is likely because their card’s main interface is near field communication (NFC) — NFC is known to be an insecure means of communication, though it may be acceptable for a user who is spending small amounts of money on the go or utilizing a card for 2FA. By contrast, the GridPlus SafeCard is designed to interface with the Lattice1, which is contact-only and draws exclusively secure screens (i.e. powered by the secure compute environment which is enclosed in an anti-tamper laser directed structure (LDS) mesh).

2. SafeCards are authenticated with a GridPlus certificate and can prove origin to all interfaces

At the time of installation, the SafeCard applet generates an “identity” key pair using entropy from the card’s physically unclonable function (PUF). This key pair may, at any time, be used to sign a cryptographic challenge and reveal its public key (i.e. “identity”). GridPlus signs this identity (with its own publicly known ECDSA key pair) and loads the certificate (signature) onto the card. Once loaded, the cert is always visible, but it may never be edited or removed from the card.

Think of the PUF as a physical fingerprint projected onto digital space

Interfacing with a SafeCard

The use of certificates allows SafeCards to prove that they are authentic to any interface they may come across. By default, the Lattice1 secure compute environment (SCE) serves as the interface. Whenever a contact-chip card is inserted into the Lattice1, its SCE first requests the card’s certificate and then its signature on a cryptographic challenge before prompting the user to enter a secret PIN to unlock the card. If at any point the card is unrecognizable or cannot prove its origin via a valid challenge, response, or certificate, the Lattice1 will either notify the user or terminate the connection. This mechanism gives much greater assurance that the card is not a fake and/or a phishing scheme.

Because the SafeCard’s applet may not be edited or re-installed without deleting its identity key and certificate, this scheme prevents against supply chain attacks that other hardware wallets may encounter.

Provisioning Process

In order to give this assurance, GridPlus goes through a strict provisioning process for creating new SafeCards:

GridPlus installs the applet on a new SafeCard, which generates an identity key (ECDSA key pair). GridPlus asks for a signature on a cryptographic challenge plus the identity public key. GridPlus validates the identity key’s challenge signature and then signs the corresponding public key before loading the signature as a certificate onto the card.

Note that the same provisioning process happens for the Lattice1’s onboard key store, which exists in the same type of secure element as the SafeCard and runs the same applet.

Certificate Extensibility

Although SafeCards are designed to hold one certificate at a time (which, recall, is just an ECDSA signature), it is possible to spread the trust to more than one party using non-interactive signature aggregation techniques such as muSig. In this way, several individual authorities may sign the card’s public key and aggregate their signatures together, producing a single aggregated signature and signer public key. If any subset of authorities collude to produce and certify invalid or malicious cards, the aggregated signature would not be valid and Lattice1 authentication checks would fail.

Furthermore, if other card issuers (e.g. Status) wish to implement the SafeCard API (or some subset of it), they may add certificates as well and the user’s interface may select which certificate issuers to trust. We plan to expand this optionality in future versions of the Lattice1 firmware.

SafeCard Verification on the Lattice1

Once provisioned, the card is shipped to the user, who sets it up as follows:

Insert card into the card slot to connect with the Lattice1. The interface is activated via the secure compute environment. Lattice1 generates a random hash and asks for a signature by the identity key. This returns a signature and the public key, which can be validated. Lattice1 asks for certificates. Once it receives them, it checks the signatures against the identity public key and the public key of the certificate signer. We expect the cert to be a signature of the identity public key by the certificate signer. Once the Lattice1 verifies that the card is authentic, the user may proceed setting up the card (either by generating or loading a seed). Once set up, the user may spend funds or view balances.

Because the SCE executes logic in a secure and trusted environment, we have some trust in the certificate verification process. This is what we refer to as a secure interface, which is contrasted by insecure interfaces such as standard card readers (which may also interact with SafeCards, but users shouldn’t necessarily trust those interfaces with high-value keys).

SafeCards IRL

SafeCard Use Cases

We believe SafeCards provide the most secure and robust mechanism for storing digital secrets in physical space. Many of these mechanisms (tamper resistance of the Lattice1, secure communication channels with cards, etc) are standards in the traditional payments industry — GridPlus seeks to bring these standards to the world of crypto.

Having secure hardware and trusted cards leads to several use cases that are either enhanced relative to existing hardware wallets or are entirely new.

Cold Storage

The most immediate and obvious use case is cold storage. A user can rest assured that his card cannot be used without a PIN code. Furthermore, the PIN code of the user’s real SafeCard cannot be phished by attempting to unlock a fake card, as the Lattice’s SCE will detect that a fake card does not have a valid certificate.

In future firmware updates, the Lattice1 will use multiple cards to leverage multi-signature or secret splitting techniques (e.g. Shamir) to introduce further mitigation of risk related to storing your high-value private keys.

Scaling

Because the card applet is open source and all instances of it are signed by GridPlus (in the form of identity certificates), we have confidence that every SafeCard is running the correct software. If an attacker were to attempt to fake a card, he would not be able to replicate the certificate and all interfacing with the Lattice1 would fail. Furthermore, if an attacker were to try to reinstall the card’s applet, the identity (and certificate) would be lost.

This chain of trust allows us to enforce consensus by hardware, creating a previously unexplored off-chain (and, really, offline) avenue through which to approach scaling public blockchains. We will have more details on this design in the near future.

Identity and 2FA

Use of SafeCards need not be restricted to holding and spending cryptocurrencies. The seed can easily produce key pairs that may be used as a second means of personal authentication. The SafeCard’s compact size makes it easy to carry and use.

In cases where the digital keys are less valuable (e.g. for 2FA), the SafeCard would not necessarily need the Lattice1’s secure interface, though high value logins could still use it.

Another visualization of the PUF. Imperfections in the manufacturing process translate to entropy which cannot be extracted.

Summary

The SafeCard introduces a new set of features allowing users to store digital secrets in what we believe is the safest way possible, given available technology. But the SafeCard is not only a key store — it is also a mechanism for identity and could serve as an instrumental piece of infrastructure for the nascent crypto industry.

SafeCards are now available for pre-order at the GridPlus store, with delivery expected in Q3.

— — —