Guide to Rivetz Technology

Introduction

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 asked. 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 servers. They are under administrative control and usually protected physically. 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. Through the use of Trusted Execution technology we are able to provide a service provider with an oasis of trust in the unknown world of consumer devices. Basic capabilities such as "sign this", or "decrypt this" are executed outside the murky world of 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.

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.

What Can I Do with Rivetz?

Rivetz is all about trust in devices. We believe that a reliable relationship with a device can make for a much safer, easier and stronger relationship with an end user.

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, like a decryption or signing.

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.

Rivetz enrolls a device and equips it with a service provider's keys. Our API's 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 SP 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 normal processing environment of the device.
  • 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 RNG built into the Trusted Execution Environment.
  • Sign a Bitcoin transaction - The device can apply it's private Bitcoin account key to sign a transaction and then return it to the service provider
  • Secure Confirmation - (coming soon) 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 Service Provider calls Rivetz to create hardware keys in a device. Different types of keys are available depending on the purpose, such as for crypto-coins or data encryption.

Riveted keys are governed by simple usage rules established during creation. For example, a key may require that usage requests are signed by the Service Provider that created the key, or that the user confirms access through the Trusted User Interface.

A Rivet will only respond to an instruction from a Service Provider that has been "paired" with the device. Rivetz.net conducts the pairing ceremony as it is able to confirm 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 public key for the device.

While Rivetz supports local calls, ideally all instructions are signed by the Service Provider. This protects a device key from being applied by a rogue application. The _Rivetz Library is used by all components to prepare and sign device instructions and interpret instruction results.

Trusted Execution Environment

There is a class of apps that benefit greatly from strong assurance of their origin and opaque separation from the execution of other apps. This is known as a Trusted Execution Environment or TEE.

Unlike an app running on the primary OS and memory stack, an app running in a TEE has access to cryptographic primitives that can be exercised without snooping by the OS. On certain platforms, it also has direct access to user input and display to ensure a private interaction with the operator of the device.

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 concerned with enterprise security or DRM, Rivetz instead provides an applet that is focused on the needs of common web services. Crypto currencies such as Bitcoin have highlighted the need for consumer key security. Rivetz provides a native API that translates calls into a secure environment. While different TEE environments follow very different architectures, the Rivetz API is designed to present a uniform interface to the application.

As with all TEE applets, Rivetz cannot be installed and initialized without a Trusted Application Manager, or TAM. The TAM plays a role akin to a CA. A TAM secures a relationship with a device manufacturer and also signs all applets that may be loaded into the device. In this way the TAM expresses assurance about the provenance and integrity of both the applet and the TEE.

Trusted User Interface

Some devices support Trusted User Interface, or 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.

In the Anrdoid ARM environment, Trustzone 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 app 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.

On certain platforms, the Intel TEE runs in a separate processing environment in parallel to normal world OS processes. In this scenario, secure display can still be configured so as to present unpredictable input vectors, allowing secure input. For example, the user can enter a pin on a randomized pin pad.

Device Attestation

The TEE offers a 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 that is 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 Trusted Applications, or TA. 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 of these trusted keys to provide application keys that can attest to the trustworthiness of the device.

Component Architecture

On the client side, the phone or PC, Rivetz is comprised of two distinct elements. The Device Rivet is the actual Trusted Application code that executes in the TEE and the Rivet Adapter is the native app that marshals commands to the Rivet on behalf of local or online 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 crypto-currency). The keys are protected in the hardware shell of the Rivet and can be utilized by the Service Provider that requested their creation.

Each key may be governed by usage rules established when it was created. For example, a key can require secure display 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. Rivetz.Net provides this service of registering both Service Providers and devices and conducting an exchange of credentials.

The RivetzJ repository provides the open source Rivetz Library for preparing and signing instructions to be delivered to a Rivet and also the Rivetz Bridge which is used by Android apps 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, initiated by a user, but engage the Rivetz Server to protect the request. We can only really trust data/instructions that are under the control of the Device Rivet (the trustlet code), or the Rivetz Server which is hosted online. Identity keys shared during Pairing establish a relationship between these two endpoints.

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

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 such that they require a signature. This protects the keys from being leveraged by a rogue app.

The RivetzJ library is used to package and sign instructions server-side. The instruction is delivered to the Rivet and produces a result record which is signed by the device.

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.

The TAM installs the Device Rivet (our trusted applet) by encrypting it uniquely for the device hardware and pushing it over the air to the endpoint device. The Rivet is baked with public identity and privacy keys of the Registration Authority (Rivetz.net), 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 Registration Authority 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 wield 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
KEYTYPE_ECDH_SHARE_DEFAULT
Purpose: Secret Sharing
Public-Key Crypto: ECC CDH operation only - key derivation and scheme implemented outside TEE
Parameters: Secp256k1
KEYTYPE_ECDH_ENCRYPT_DEFAULT
Purpose: Privacy
Public-Key Crypto: ECC CDH (C1, 1)
Parameters: Secp256k1
Hash: SHA-256
Key Derivation: NIST SP800-56A Concatenation KDF 1
Encryption: AES-128 CFB Integrity: HMAC
KEYTYPE_ECSDA_DEFAULT
Purpose: Identity/Integrity
Public-Key Crypto: ECDSA
Parameters: Secp256k1
Hash: SHA-256
KEYTYPE_BITCOIN_DEFAULT
Purpose: Crypto Coin
Bitcoin-compatible: See Bitcoin Signatures
Public-Key Crypto: ECDSA
Parameters: Secp256k1
Hash: SHA-256
KEYTYPE_ECDSA_NISTP256
Purpose: Identity Keys
ssh-keygen default ecdsa key type: Elliptic curve default
Public-Key Crypto: ECDSA
Parameters: Nistp256
Hash: SHA-256

Developer Guide