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 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 of their 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.

Rivetz code runs in the Trusted Execution Environment (TEE), available in many modern devices. The TEE is a hardware environment that runs small applications in a hardware-protected location inaccessible by the main OS. This protects sensitive code and data from malware and other forms of attack by applying purpose-built hardware that is governed by an ecosystem of endorsements, that begins 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 must be able to assert that a device has not been compromised, i.e. it is the same device as before. You also need to be sure that a device won’t expose its secrets while performing sensitive operations such as a decryption or signing.

What Can I Do with Rivetz?

Since a device is equipped with a Service Providers' keys upon registration, the Rivetz Toolkit can 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.

Secure Confirmation

Some 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, allowing the user to respond to that request via trusted input.

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

Component Architecture

Component Architecture (Diagram)

On the client-side device, there are two distinct elements supporting both the application and trusted communication with the Service Provider;

  1. The Rivet is responsible for the creation, storage and application of 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.

  2. The Rivetz Toolkit provides the APIs that are utilized by both the local application and the Service Provider in order to access and operate using those keys.

On the Service Provider side, a server-oriented version of the Rivetz Toolkit is used to construct or destruct the signed instructions that are used as the Service Provider and device communicate through the Rivetz Network.

The Rivetz Network is comprised of a set of components and services provided either by Rivetz or one of its partners. some of these services include attesting to the state of the device, transaction authorization and confirmation, and the registration and pairing of Service Providers and devices.

Although not depicted here, Rivetz also provides 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.

How does it work?

The 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, which includes a trusted application (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 the key is used, and/or require that the request be signed by a Service Provider registered to the device.

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 executed while being totally inaccessible by a potentially infected device OS and/or user applications. On certain platforms, the TEE 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 that both the service provider and endpoint keys are protected during generation and use. While different TEE environments follow very different architectures, the Rivetz Toolkit is designed to present the application with a uniform interface to the functionality offered by the Rivet.

Rivetz and the TEE (Diagram)

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 TEE-enabled devices support a Trusted User Interface (TUI) which renders an image on the device display 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 the TUI 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

Rivetz is built on a chain of cryptographic trust that begins with the device manufacturer. 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.

Identification & Pairing (Diagram)

First, the hardware manufacturer provides a mechanism to protect an initial endorsement key embedded in the device before it leaves manufacturing. A core TEE software provider, such as Trustonic, provides a safe environment to install and run TA’s.

The TAM installs the Trusted Application by uniquely encrypting it for the device hardware and pushing it over the air to the endpoint device. 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. The Rivet is provisioned with the public identity and privacy keys of the Registrar, the component which acts as the Registration Authority for the Rivetz Network. The TAM will take no action until it receives an instruction to enroll, that is signed by the Registrar.

On first execution, 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.

Transaction Signing and Component Interaction

Depending on the particular use case, transactions may be initiated by either the device or the Service Provider. 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, and are used in the preparation and interpretation of instructions sent or received.

This diagram depicts the request / response sequence of calls that might take place when a Service Provider issues an instruction to a device.

Component Interaction (Diagram)

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.

A server version of the Rivetz Toolkit 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.

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: ECC CDH (C1, 1)

Integrity: HMAC

KEYTYPE_ECSDA_DEFAULT

Purpose: Identity/Integrity

Public-Key Crypto: ECDSA

Parameters: Secp256k1

Hash: SHA-256

KEYTYPE_BITCOIN_DEFAULT

Purpose: Cryptocurrency

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