The security model
Ledger Enterprise assumes your browser can be compromised, and is built so that this is survivable.
Three layers
Your organization's keys never leave the secure hardware. Private keys are generated and held inside a Hardware Security Module (HSM). They are never sent to your browser, never held in a user's session, and cannot be exported. Signing happens inside the hardware; only the signature comes out.
Your governance is enforced by hardware, not software. Approval Rules are not a browser check that a determined attacker could skip. They are enforced at the point of signing, within the HSM. An operation that does not satisfy its Rule does not get signed, whatever the browser was told.
Users approve with their own key, not with your organization's keys. The HSM cannot sign on their behalf, it needs approvals from the designated users who own their own keys. Where the user's key sits depends on how the Master Administrators created your user.
It can be a PSD user. The user's key is a Personal Security Device (PSD), held on a Ledger device. The Ledger device has its own screen, and it displays what you approve. It reads the operation from the secure hardware, not from the page in front of the user.
A Master Administrator can instead create an API user. This creation is a Request that the Master Administrator quorum approves. An API user holds its key in your organization's systems. It approves over the API with that key. There is no second screen to check. Your own systems must provide that check instead.
What the device protects you from
This section covers approval on a Ledger device. A user who approves without one has no second display, so these checks do not apply.
The threat is a compromised browser, or a compromised machine. It displays one operation and requests another: a different recipient, a different amount, a different deposit address.
The device renders the operation from the secure hardware. A substitution therefore shows up as a mismatch between the device and the browser.
Important: If the device and the browser disagree, stop. Decline on the device. Do not retry. Contact support. A mismatch is not a display glitch.
Declining on the device does not reject a Request that you approve. It only interrupts your approval, and the Request stays pending for the other Approvers. To stop the Request, also select Reject in the interface. A Creator who declines on the device while creating a Request is a different case: the platform rejects the new Request. See Declining on the Ledger device.
The device display is the authoritative one in two places:
On a send, the recipient and the amount shown on the device are the authoritative values.
On a receive, the deposit address shown on the device is the authoritative one. See Receiving assets.
What it does not protect you from
Device confirmation covers the integrity of an operation. It does not cover the merit of one.
A correct transfer to the wrong counterparty
The device confirms the address you chose, not that you chose well. Verify new counterparty addresses through a second channel and use Whitelists.
A whitelisted destination that turns out to be malicious
A Whitelist records that your governance permits a destination, not that the destination is safe
A smart contract that behaves unexpectedly
Approving an interaction authorizes the call, not its consequences
Social engineering that gets a genuine approval
If you are persuaded to approve a real transfer, every layer works exactly as designed
Important: Approval steps distribute a decision across people. A single mistaken or coerced individual is then not sufficient to move value. A quorum of one places the whole decision with one person.
The practices that Ledger recommends for these cases, and for devices, recovery sheets and workstations, are in Security good practice.
Separation of duties
Administrators set the Rules. A Master Administrator creates and approves each change to a Policy, a Whitelist or an existing Account. Operators create and approve transactions. An Administrator cannot create a transaction, and an Operator cannot change a Rule. The platform enforces this split.
A change to what an Account may do is itself a Request, and it appears in Requests. A change to a Policy also appears in the History of that Policy. No individual can make it quietly.
Related
Last updated