You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: doc/acre.md
+61-1
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,8 @@ The main commands use `CLA = 0xE1`.
16
16
| E1 | 04 | SIGN_PSBT | Sign a PSBT with a registered or default wallet |
17
17
| E1 | 05 | GET_MASTER_FINGERPRINT | Return the fingerprint of the master public key |
18
18
| E1 | 10 | SIGN_MESSAGE | Sign a message with a key from a BIP32 path (Bitcoin Message Signing) |
19
+
| E1 | 11 | SIGN_WITHDRAWAL | Signs a Withdrawal message. The message being signed is the hash of the Acre Withdrawal transaction. |
20
+
| E1 | 12 | SIGN_ERC4361_MESSAGE | Signs an Ethereum Sign-In message (ERC-4361) in Bitcoin format. |
19
21
20
22
The `CLA = 0xF8` is used for framework-specific (rather than app-specific) APDUs; at this time, only one command is present.
21
23
@@ -392,6 +394,64 @@ The digest being signed is the double-SHA256 of the Withdrawal transaction hash,
392
394
393
395
The client must respond to the `GET_PREIMAGE`, `GET_MERKLE_LEAF_PROOF` and `GET_MERKLE_LEAF_INDEX` queries for the Merkle tree of the list of chunks in the Withdrawal data.
394
396
397
+
### SIGN_ERC4361_MESSAGE
398
+
399
+
Signs an Ethereum Sign-In message (ERC-4361) in Bitcoin format.
400
+
401
+
The device shows on its secure screen the following information:
402
+
- Domain
403
+
- Address
404
+
- URI
405
+
- Version
406
+
- Nonce
407
+
- Issued At
408
+
- Expiration Time
409
+
410
+
The user should verify this information carefully before approving the signature.
411
+
412
+
#### Encoding
413
+
414
+
**Command**
415
+
416
+
|*CLA*|*INS*|
417
+
|-------|-------|
418
+
| E1 | 12 |
419
+
420
+
**Input data**
421
+
422
+
| Length | Name | Description |
423
+
|---------|-------------------|-------------|
424
+
|`1`|`n`| Number of derivation steps (maximum 8) |
425
+
|`4`|`bip32_path[0]`| First derivation step (big endian) |
426
+
|`4`|`bip32_path[1]`| Second derivation step (big endian) |
|`<var>`|`msg_length`| The byte length of the message to sign (Bitcoin-style varint) |
430
+
|`32`|`msg_merkle_root`| The Merkle root of the message, split in 64-byte chunks |
431
+
432
+
The message to be signed is split into `ceil(msg_length/64)` chunks of 64 bytes (except the last chunk that could be smaller); `msg_merkle_root` is the root of the Merkle tree of the corresponding list of chunks.
433
+
434
+
**Output data**
435
+
436
+
| Length | Description |
437
+
|--------|-------------|
438
+
|`65`| The returned signature, encoded in the standard Bitcoin message signing format |
439
+
440
+
The signature is returned as a 65-byte binary string (1 byte equal to 32 or 33, followed by `r` and `s`, each of them represented as a 32-byte big-endian integer).
441
+
442
+
#### Description
443
+
444
+
The digest being signed is the double-SHA256 of the ERC-4361 message, after prefixing the message with:
445
+
446
+
- the magic string `"\x18Bitcoin Signed Message:\n"` (equal to `18426974636f696e205369676e6564204d6573736167653a0a` in hexadecimal)
447
+
- the length of the message, encoded as a Bitcoin-style variable length integer.
448
+
449
+
Note: The message is restricted to maximum 128 character lines.
450
+
451
+
#### Client commands
452
+
453
+
The client must respond to the `GET_PREIMAGE`, `GET_MERKLE_LEAF_PROOF` and `GET_MERKLE_LEAF_INDEX` queries for the Merkle tree of the list of chunks in the message.
454
+
395
455
## Client commands reference
396
456
397
457
This section documents the commands that the Hardware Wallet can request to the client when returning with a `SW_INTERRUPTED_EXECUTION` status word.
@@ -490,4 +550,4 @@ All the current commands use a commit-and-reveal approach: the APDU that starts
490
550
- If a Merkle proof is asked via `GET_MERKLE_LEAF_PROOF`, the proof is verified.
491
551
- If the index of a leaf is asked `GET_MERKLE_LEAF_INDEX`, the proof for that element is requested via `GET_MERKLE_LEAF_PROOF` and the proof verified, *even if the leaf value is known*.
492
552
493
-
Care needs to be taken in designing protocols, as the client might lie by omission (for example, fail to reveal that a leaf of a Merkle tree is present during a call to `GET_MERKLE_LEAF_INDEX`).
553
+
Care needs to be taken in designing protocols, as the client might lie by omission (for example, fail to reveal that a leaf of a Merkle tree is present during a call to `GET_MERKLE_LEAF_INDEX`).
0 commit comments