Introducing Offline Signer

Today we're introducing Offline Signer, a new product inside the Dfns Key Management suite. Offline Signer lets institutions generate, store, and operate signing keys on dedicated, air gapped hardware, with no network path between the key material and the internet at any point in the key's lifecycle.

The motivation is regulatory. Over the past several years, working with clients across Japan, South Korea, Singapore, Hong Kong, and the UAE, we've watched the same requirement appear in regulator after regulator: a defined (and usually high) portion of customer assets must be held as offline keys. Different jurisdictions use different vocabulary, including "cold," "offline," and "air gapped," but the intent is the same. A class of keys that an attacker on the internet cannot reach, even theoretically, because no path exists from the public internet to the key material.

Offline Signer is our answer for institutions that need a high security air gap to satisfy that requirement, but are not ready to stand up full data center computation to get there.

What Offline Signer is

Offline Signer pairs a server side coordination layer running on Dfns with a set of air gapped hardware security modules operated by the client. Keys are generated inside the HSM during a genesis ceremony and never leave it. (We will soon enable an additional workflow for generating keys outside of a genesis ceremony.) Transaction requests are exported from Dfns as a bundle, physically transported to the air gapped environment via inert media rather than over any network, signed inside the HSM, and the resulting signatures are imported back into Dfns and broadcast onchain.

What the design gives you:

• True physical isolation. Keys live inside a dedicated, certified hardware security module, not on a consumer device, and with zero network connectivity. This reduces the threat surface and meets air gap compliance requirements.
• Key provenance. Each asset key is generated in device with accompanying attestation. This enables provenance, control, and auditability throughout its lifecycle.
• Full audit trail. Every operation is signed by the hardware itself, creating an immutable record of events. All system actions (genesis, clone, credential rotation, and others) and all transaction requests are captured server side on Dfns, including inputs, outputs, approvals, and timestamps.
• Compatible with the rest of the Dfns platform. Policies, entitlements, transaction lifecycle management, and webhook flows all work exactly as they do for online keys. The offline part is the signing, not the orchestration.

Offline Signer is an investment in asset security. It requires HSM hardware, dedicated operator workstations, ceremony procedures, and security trained staff. It is a tool for institutions whose security teams already understand what air gapped operations entail, and whose regulators expect to see that understanding evidenced.

For larger institutions that want a fully managed, multi party offline custody operation with hardened operator workflows out of the box, we continue to recommend IBM's Offline Signing Orchestrator (OSO). The Dfns Offline Signer can be the right entry point. IBM OSO is the right destination at scale.

Why store in Offline Signer

Aside from your local regulatory requirements, there are three main reasons:

1. Hardware-tied root of trust. Using an offline signer you know where your keys are and how they have been used at all times. This is made possible through hardware attestation available in an enterprise grade HSM. The Offline signer gives you non-extrable secrets, de-risked cloning operations and the durability of managing your own fleet of devices but at a market entry price.
2. High assurance cryptography.  Device quality, audited firmware, high assurance build and secrets management in app. 
3. No operator risk. The Offline signer relies on payloads to be delivered and returned from the field. Done in correctly this can lead to transaction errors or misdirection of funds. The Offline Signer ensures that all payloads were policy approved through Dfns SAS and immutable while in transit.

Why we didn't build it on a phone

A reasonable question is why we built Offline Signer the way we did, rather than the simpler thing some competitors do: install an app on a fresh consumer mobile device, put the device into airplane mode, and call that cold storage. Fireblocks publicly describes its Cold Wallet app as transforming "iOS devices into secure, air gapped, crypto signing devices" using QR based transaction signing on a phone in airplane mode.

We chose not to build it that way. We think the industry should stop building it that way, and we think regulators should stop accepting it. Our reasons are technical, not philosophical.

Regulators accept the phone on “airplane mode” models because incumbents pushed it, not because it is sound. This is the part that bothers us. A large enough market footprint can normalize a practice that is technically weak, and we have watched that happen with mobile device cold storage. Customer balances grow, exposure compounds, and the underlying control gets weaker relative to the threat environment over time, not stronger. It is not future proof. We do not think it should be a permitted control for storing keys that protect institutional scale customer assets, and we expect that view to be increasingly shared by regulators once the next generation of mobile OS exploitation against custody apps becomes public.

Putting institutional signing keys on a consumer phone, regardless of what the settings menu says about airplane mode, is not cold storage in any sense that survives serious adversarial review. It should be called what it is, which is a software wallet on a device with the radios barely disabled. It should not satisfy a regulatory requirement that exists to protect customers from internet-resident threats.

When to use Offline Signer

Offline Signer is the right product for clients who:

• Need to satisfy a regulatory requirement for offline key storage in markets like Japan, South Korea, Singapore, Hong Kong, the UAE, and increasingly the EU under MiCA
• Are launching a new digital asset business line, releasing a new product, or running a regulated experiment, and want to do it at a cost efficient entry point without compromising on the underlying security model
• Have security professional staff who can operate air gapped ceremonies, and who want direct control over the offline environment rather than a fully outsourced managed service

For clients running offline custody at production scale, with large balances, multi party ceremonies, and the operational maturity that demands a fully managed offline custody operation, IBM OSO remains our recommendation.

Offline Signer is available now. Get started: app.dfns.io