Skip to content

Latest commit

 

History

History
66 lines (50 loc) · 3.12 KB

heartbeat.md

File metadata and controls

66 lines (50 loc) · 3.12 KB
Raw

powHSM heartbeat

Abstract

This document describes the feature known as "heartbeat", which allows an end user to acknowledge the state of a running powHSM installation.

Heartbeat and attestation

Just like the attestation process, the heartbeat feature makes use of the Hardware Abstraction Layer's endorsement mechanism to prove to the end user a given state of the device and its running applications. Nevertheless, and as opposed to the attestation process, the heartbeat feature itself does not include the chain of certification all the way up to the manufacturer, but rather leverages the previously generated attestation process artifacts for this purpose. For more details about this and the attestation process, see the attestation documentation.

Goal

The main goal of the powHSM heartbeat mechanism is enabling the end user(s) to have access to periodic proof of the state of a running powHSM installation. This proof includes information such as the current recorded best block and the last signed pegout transaction, allowing users access to a day-to-day follow up with each of the PowPeg members' key keepers, and in turn and more importantly also proving the ongoing use of these devices on the PowPeg.

Heartbeat gathering

The heartbeat gathering is accomplished via an additional protocol operation, and as mentioned above, only includes the heartbeat message, public key and signature, leaving the chain of certification out of the equation and up to the end user -- who should have access to the attestation public key chain of certification -- to verify.

Signer heartbeat

To generate the heartbeat, the Signer uses the configured endorsement scheme to sign a message generated by the concatenation of:

  • A predefined header (HSM:SIGNER:HB:5.2:).
  • A 32 byte value corresponding to the currently known best block hash.
  • A value corresponding to the first 8 bytes of the last successful authorized signed operation's transaction hash.
  • A 16 byte user-defined value. This value can vary and could be, for example, used as a timestamp reference for the end user.

This signed message guarantees that the device is running a specific version of the Signer that is up-to-date with the RSK blockchain and that is actively signing pegout transactions.

UI heartbeat

To generate the heartbeat, the UI uses the configured endorsement scheme to sign a message generated by the concatenation of:

  • A predefined header (HSM:UI:HB:5.2:).
  • A 32 byte user-defined value. This value can vary and could be, for example, used as a timestamp reference for the end user.
  • A 32 byte value corresponding to the currently authorized Signer hash.
  • A 2 byte value corresponding to the currently authorized Signer iteration (unsigned, big-endian encoded). For details on this and the authorized signer hash, refer to the signer authorization documentation.

This signed message guarantees that the device is running a specific version of the UI that only allows a specific Signer version to run, alongside with all other enforcements implemented in the specific UI version itself.