Rivetz believes that online services are significantly enhanced when a device can be trusted to be what it says it is and to execute instructions exactly as expected. Building upon a decade of industry investment in trusted computing, Rivetz is offering a platform that delivers on this goal.

A service provider generally has confidence in its own servers and network infrastructure. They are under administrative control and usually physically protected . However, nearly all services are delivered to users through devices the service provider knows very little about and over which it rarely exerts any control.

Rivetz changes this by offering service providers an oasis of trust in the uncertain world of consumer devices. Basic capabilities such as signing and encryption are executed in an area separated from the main OS. Keys can be generated and applied without ever being exposed in memory and can be attested to through a chain of endorsements traced back to the device manufacturer.

Our device code runs in the Trusted Execution Environment (TEE) available in many modern devices. The TEE is a hardware environment that runs small applets outside the main OS. This protects sensitive code and data from malware or snooping with purpose-built hardware governed by an ecosystem of endorsements, beginning with the device manufacturer.

When you can trust a device not to lie or leak secrets, you can form a much more reliable and simpler relationship with the device. It makes life easier and safer for the user and service provider alike.

To achieve this, first and foremost you need to know with confidence that a device is the same device it was before. You also need to be sure that a device won’t leak its secrets when asked to do something sensitive, such as a decryption or signing.

What Can I Do with Rivetz?

Rivetz enrolls a device and equips it with a service provider’s keys. Our APIs enable secure execution of a number of sensitive device-side transactions, including:

Get a reliable and anonymous device id

On request, Rivetz will generate a signing key for a device. The public key is hashed into a string that can be used to identify and communicate with a device. The private key remains locked in the hardware and can only be applied on behalf of the service provider that requested the ID.

Get a device to sign something

The private key of the device identity can be used to sign things, proving that this device was involved. The signing ceremony is executed in secure hardware such that the key is never exposed to the device’s normal processing environment.

Get a device to encrypt something

An encryption key can be generated on request and applied to any blob of data. Encryption/Decryption is triggered locally and takes place within the secure execution environment so as to protect the key.

Create a Bitcoin account

The device can be asked to generate a new Bitcoin account using the random number generator built into the Trusted Execution Environment.

Sign a Bitcoin transaction

The device can apply its private Bitcoin account key to sign a transaction and then return it to the service provider.

Secure Confirmation

Newer TEE environments support trusted display and input in addition to trusted execution. Trusted display enables a simple confirmation message, such as "confirm transaction amount," to be presented to an end user.

Join Devices to share and backup identities

Most users have a couple of devices. Rivetz allows those devices to be bound into a ring so they can interchangeably present themselves to a service provider on behalf of the user.

Rivetz is a toolbox for riveting the online world to the hardware we use to get online. By providing this basic set of features, we hope services across the web - from wallets to content apps - can provide a simpler and safer experience.

How does it work?

A Rivet will only respond to an instruction from a Service Provider that has been "paired" with the device. The Rivetz Network conducts the pairing ceremony, confirming the integrity and identity of both device and service provider. When a device is paired, it acquires the public key of the service provider, while the service provider gets a uniquely generated identity and a public key for the device.

As an example, a Service Provider might wish to create hardware keys in a device. This call is processed by the Rivet, a collection of trusted applications (TA) running within the TEE on the endpoint device, thus creating and storing the key in a secured environment. Different types of keys are available depending on the purpose, such as for crypto wallets or data encryption.

Each key may be governed by usage policies established when it was created. For example, the owner may require a secure confirmation from the user before being applied, and/or it may require that the request be signed by a Service Provider registered to the device.

While the Rivetz toolkit supports local calls, ideally all instructions are signed by the Service Provider. The Rivetz Library is used by all components to prepare and sign device instructions and interpret and sign the corresponding instruction results.

Rivetz Overview (Diagram)

Trusted Execution Environment

There is a class of applications that benefit greatly from strong assurance of their origin and clear separation from the execution of other applications. This assurance and separation is provided by what is known as a Trusted Execution Environment (TEE). Applications running in this environment are known as Trusted Applications (TA).

Unlike an application running on the primary OS and memory stack, a TA running in the TEE has access to cryptographic primitives that can be exercised without the OS snooping. On certain platforms, it also has direct access to user input and display to ensure a private interaction with the operator of the device (See "Trusted User Interface" below).

While the technology has been pursued for well over a decade, it is only recently that devices with support for a TEE have become available. Intel began delivery of commercial solutions in 2011 and Trustonic, an ARM joint venture, launched in 2013.

Deploying an applet into a TEE is akin to delivering a dedicated hardware device. Execution and data are cryptographically isolated from any other function of the host.

Rivetz and the TEE

While most applications of Trusted Execution technology have been directed towards enterprise security or digital rights management (DRM), Rivetz provides a TA that is focused on the needs of trusted devices, such as ensuring the keys used between the service provider and endpoint are protected during generation and use.

Rivetz and the TEE (Diagram)

While different TEE environments follow very different architectures, the Rivetz toolkit is designed to present a uniform interface to the application. The Rivetz Adapter provides a native API that translates calls into the secure environment.

As with all trusted applications, Rivetz cannot be installed and initialized without a Trusted Application Manager (TAM). A TAM secures a relationship with the device manufacturer, signing all TA’s that may be loaded into the device. In this way the TAM provides assurance about the provenance and integrity of both the TA and the TEE.

Trusted User Interface

Some devices support Trusted User Interface (TUI) which renders an image on screen directly from the Trusted Execution Environment. This feature can be used to ensure that the displayed image is from a confirmed source. Images rendered with Trusted Display are drawn directly from the TEE to the display and are thus not available for capture by any other applications running on the endpoint. Additionally, touchscreen input is routed directly to the TEE, providing secured user input.

In the Android ARM environment, TrustZone hardware will 'freeze' the normal world OS while secure world OS is being displayed. It functions like a hardware switch where only one entity can be in control. In this way, trusted input is established by ensuring no foreign application can sniff the user’s screen taps. If a sensor fires, such as an incoming phone call, the TUI will be stopped and normal OS operations will resume.

Device Attestation

The TEE offers the promise of protected execution and key privacy, which can only be trusted if the TEE itself is known to be real and uncompromised. This trust is built off of mechanisms put into place by the supply chain. First, the hardware manufacturer provides a mechanism to protect an initial endorsement key embedded in the device before it leaves manufacturing. Next, a core TEE software provider, such as Trustonic, provides a safe environment to install and run TA’s. When the TA is installed, the TAM provides an attestation that the root keys were in fact established during device manufacture and thus present a valid TEE environment. Finally the Rivetz TA bootstraps off these trusted keys to provide application keys that can attest to the trustworthiness of the device.

Component Architecture

Component Architecture (Diagram)

On the client-side device, Rivetz is comprised of two distinct elements. The Rivet is the actual Trusted Application code that executes in the TEE, and the Rivet Adapter is the native application that marshals commands to the Rivet on behalf of local or network requests.

The Rivet is largely about storing and applying keys, of which there are three types: Privacy keys (for encryption), Identity keys (for signing) and Coin keys (for cryptocurrency). The keys are protected in the Rivet’s secure storage area and can be utilized by the Service Provider that requested their creation.

The Rivetz Library is used for preparing and signing instructions to be delivered to a Rivet and also the Rivetz Bridge, which is used by Android applications to make cross-process calls into the Rivetz Adapter.

Rivetz also runs the Ring Manager, which is a service offered to end-users for managing a collection of devices for the purposes of backup, identity sharing, attestation and more.

Component Interaction

Most use cases start at the device and are initiated by a user, but engage the Rivet to protect the request. We can only really trust data/instructions that are under the control of the Rivet, or the Rivetz Network which is hosted online. Identity keys shared during pairing establishes a relationship between these two endpoints.

This diagram depicts the sequence of calls that might take place to issue an instruction to a device.

Component Interaction (Diagram)

Transaction Signing

While one can call the Rivet Adapter directly to exercise most functionality, the majority of applications will want to sign instructions with their registered Service Provider key. Device keys can be created with a policy that stipulates that they require a signature.

The Rivetz Library is used by the service provider to package and sign instructions. The instruction is delivered to the Rivet, which in the course of execution produces a result record signed by the device, lending assurance to the service provider that the transaction was completed with the intended party.

Identification and Pairing

Rivetz is built on a chain of cryptographic trust that begins with the device manufacturer. Various TEE environments differ in the particulars, but follow a similar pattern.

Identification & Pairing (Diagram)

The TAM installs the Device Rivet by encrypting it uniquely for the device hardware and pushing it over the air to the endpoint device. The Rivet is provisioned with public identity and privacy keys of the Registrar component of the Rivetz Library, enabling it to securely communicate with the Registration Authority. Until it receives an instruction to enroll, signed by the Registration Authority, it won’t do anything else.

On first run, the Rivet will announce itself to the Registrar, which creates and signs a request to generate an identity key in the Rivet. The Rivet verifies the authenticity of the request and responds back with the public key of a newly generated identity key pair. Note that the security of the untrusted portions of the device that initiates the enrollment process is not critical. We only need to ensure that when it does enroll A) it is a real TEE environment, so that B) it will always be the only device that can assert the newly created identity.

Key Types

Rivetz provides a flexible architecture that supports a wide variety of different algorithms, curves, key sizes and usage rules. However, most applications just need keys that are well protected and are used properly. To simplify the API, we use pre-defined key types that cover the majority of use cases.

Key Type Name Characteristics


Purpose: Secret Sharing

Public-Key Crypto: ECC CDH operation only — key derivation and scheme implemented outside TEE

Parameters: Secp256k1


Purpose: Privacy

Public-Key Crypto: ECC CDH (C1, 1)

Parameters: Secp256k1

Hash: SHA-256

Key Derivation: NIST SP800-56A Concatenation KDF 1

Encryption: ECC CDH (C1, 1)

Integrity: HMAC


Purpose: Identity/Integrity

Public-Key Crypto: ECDSA

Parameters: Secp256k1

Hash: SHA-256


Purpose: Cryptocurrency

Bitcoin-compatible: See Bitcoin Signatures

Public-Key Crypto: ECDSA

Parameters: Secp256k1

Hash: SHA-256


Purpose: Identity Keys

ssh-keygen default ecdsa key type: Elliptic curve default

Public-Key Crypto: ECDSA

Parameters: Nistp256

Hash: SHA-256