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 member is running a powHSM device with a UI version
[See UI on Github]
and a Signer version
[See Signer 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.
This powHSM is running an Intel SGX enclave with MRENCLAVE ,
built using the following parameters (this hash can be verified by
manually building the firmware from the source code using the given parameters):
| Checkpoint | |
|---|---|
| Minimum difficulty | |
| Network | |
| Authorizers file | |
For instructions on how to verify the MRENCLAVE by building the firmware with the given parameters, please read this document. For details on what the Intel SGX enclave 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 attestation shown next.
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 | |
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.
The message digest shown above is contained in the enclave-generated SGX quote (shown next -- see the report data field). This has been dynamically verified on your browser using the CryptoJS library. You can manually verify said digest using any library or tool of your choosing. The inclusion of this digest in the SGX quote, together with the rest of the certification chain up to the root of trust (Intel itself), constitutes proof of this message being generated in an authentic Intel SGX enclave with the given MRENCLAVE (contained in the SGX quote shown next).
In the table above, the signature is a valid signature of the SHA-256 digest of the message in the same table, signed by the attestation public key from the table shown next. This has been dynamically verified on your browser using the CryptoJS and Elliptic libraries. You can manually verify said digest and signature using any library or tool of your choosing. On the other hand, the MRENCLAVE can be manually verified by building the powHSM SGX enclave from source as shown in the hash and parameters section above.
In the table above, the signature is a valid signature of the
SHA-256 digest of the message in the same table, signed by
the
quoting enclave public key from the certificate shown next.
On the other hand, the report data component of the signed
message is the SHA-256 digest of the concatenation of the
public key
(without the 04 prefix) and the auth data fields
when interpreted as hex-encoded byte arrays. This has been dynamically
verified on your browser using the
CryptoJS
and Elliptic libraries. You can manually verify said
digest and signature using any library or tool of your choosing.
In each of the X509 tables above, a summary of the contents of the corresponding X509 certificate is shown alongside its full PEM representation. From top to bottom, each of these certificates has been signed by the next, forming a certification chain that goes all the way to Intel SGX's root of trust certificate. Parsing and verification of each of these certificates has been dynamically performed on your browser using the Peculiar X509, CryptoJS and Elliptic libraries. You can also manually verify the validity of each of these certificates using any library of your choosing.
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.