There was an error while trying to fetch the bridge member details.
In order to verify 's public key, make sure you
have curl
installed and, in the command line, issue:
$
Paste the result of the command below, then click "Verify":
Parsed result for 's public key:
This member is running a powHSM device version
[See on Github].
This powHSM is running a Signer with hash ,
built using the following parameters (this hash can be verified by
manually building the Signer from the source code using the given parameters):
Checkpoint |
|
---|---|
Minimum difficulty |
|
Network |
|
For instructions on how to verify the Signer hash by building the Signer with the given parameters, please read this document. For details on what the Signer is and what role it plays in powHSM, please read our concepts section.
Name | Public key |
---|---|
(*) These keys use a different derivation path and are now deprecated. They will be removed altogether in future versions.
The SHA-256 hash of the public keys shown here has been dynamically computed on your browser using the CryptoJS library. If you want to double-check this computation, you can manually compute a SHA-256 of the concatenation of the underlying byte representation of each of these public keys, in the order shown. For this task, you can use any library or tool of your choosing. This resulting SHA-256 is present in the signer attestation shown below.
0x
The signature shown above is a valid signature of the given message by the signer-hash-tweaked attestation key (shown further down). This has been dynamically verified on your browser using the Elliptic library. You can manually verify the validity of said signature using any library or tool of your choosing. The validity of this signature, together with the rest of the certification chain up to the root of trust (Ledger itself), constitutes proof of this signature being generated in an authentic Ledger device running a Signer App with the given hash.
This powHSM is running a UI with hash ,
built using the following parameters (this hash can be verified by
manually building the UI from the source code using the given parameters):
Authorized signer hash |
|
---|---|
Authorized signer iteration |
|
Signer authorizers file | [See on Github] |
For instructions on how to verify the UI hash by building the UI with the given parameters, please read this document. For details on what the UI is and what role it plays in powHSM, please read our concepts section.
This powHSM is running a UI with hash . This hash can be verified by manually building the UI from the source code.
For instructions on how to verify the UI hash by building the UI, please read this document. For details on what the UI is and what role it plays in powHSM, please read our concepts section.
The signature shown above is a valid signature of the given message by the UI-hash-tweaked attestation key (shown below). This has been dynamically verified on your browser using the Elliptic library. You can manually verify the validity of said signature using any library or tool of your choosing. The validity of this signature, together with the rest of the certification chain up to the root of trust (Ledger itself), constitutes proof of this signature being generated in an authentic Ledger device running a UI App with the given hash.
0x
In each of the Attestation public key and Device public key tables shown above, the signatures shown are valid signatures of the corresponding messages by the following table's public key. In both cases, the signed message contains the certified public key, as shown. The last table only shows the root of trust. The validity of this certification chain has been dynamically verified on your browser using the Elliptic library. You can manually verify these signatures using any library or tool of your choosing. The validity of this set of signatures constitutes part of the proof of validity of both the Signer and UI attestations shown above. For more information on the attestation process, see the Ledger documentation.