Skip to content

Commit 06c5280

Browse files
committed
Minor doc fixes.
1 parent 57796c2 commit 06c5280

File tree

2 files changed

+23
-20
lines changed

2 files changed

+23
-20
lines changed

docs/Signing.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -280,3 +280,7 @@ openssl pkeyutl -sign -keyform der -inkey my_key.der -in test-app/image_v1_diges
280280
tools/bin-assemble/bin-assemble factory.bin 0x0 wolfboot.bin \
281281
0xc0000 test-app/image_v1_signed.bin
282282
```
283+
284+
### Signing Firmware with Azure Key Vault
285+
286+
See [docs/azure_keyvault.md](/docs/azure_keyvault.md).

docs/azure_keyvault.md

Lines changed: 19 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
1-
## Signing firmware using Microsoft Azure Keyvault
1+
## Signing firmware using Microsoft Azure Key Vault
22

3-
Microsoft offer secure key management and provisioning tools, using keys stored
3+
Microsoft offers secure key management and provisioning tools, using keys stored
44
in HSMs. This mechanisms helps to centralize key management for several purposes,
55
including the support for signing payloads using the managed keys, which can be
66
used in combination with wolfBoot for provisioning public keys in a fleet of
@@ -13,18 +13,18 @@ wolfBoot can import public keys in the keystore using the `keygen` command line
1313
tool provided. `keygen` supports both raw ECC keys and ASN.1 format (.der).
1414

1515
Azure allows to download the public keys in ASN.1 format to provision the device.
16-
To retrieve each pukey to use for firmware authentication in wolfBoot, use:
16+
To retrieve each public key to use for firmware authentication in wolfBoot, use:
1717

18-
```
18+
```sh
1919
az keyvault key download --vault-name <vault-name> -n test-signing-key-1 -e DER -f public-key-1.der
2020
```
2121

2222
A keystore can now be created importing the public keys and with `keygen`'s `-i`
23-
(import) option. The option may be repeated multiple times to add more keys to
23+
(import) option. The option may be repeated multiple times to add more keys to
2424
the keystore.
2525

26-
```
27-
tools/keytools/keygen --ecc256 -i public-key-1.der [-i public-key-2.der ...]
26+
```sh
27+
./tools/keytools/keygen --ecc256 -i public-key-1.der [-i public-key-2.der ...]
2828
```
2929

3030
### Signing the firmware image for wolfBoot
@@ -40,15 +40,14 @@ Step 1 consists in calling the `./sign` tool with the extra `--sha-only` argumen
4040
to generate the digest to sign. The public key associated to the selected signing
4141
key in the vault needs to be provided:
4242

43-
```
44-
./sign --ecc256 --sha-only --sha256 test-app/image.bin public-keyi-1.der 1
43+
```sh
44+
./tools/keytools/sign --ecc256 --sha-only --sha256 test-app/image.bin public-key-1.der 1
4545
```
4646

4747
To fit in a https REST request, the digest obtained must be encoded using base64:
4848

49-
```
49+
```sh
5050
DIGEST=$(cat test-app/image_v1_digest.bin | base64url_encode)
51-
5251
```
5352

5453
The variable `DIGEST` now contains a printable encoding of the key, which can be
@@ -59,19 +58,19 @@ attached to the request.
5958

6059
To prepare the request, first get an access token from the vault and store it in a variable:
6160

62-
```
61+
```sh
6362
ACCESS_TOKEN=$(az account get-access-token --resource "https://vault.azure.net" --query "accessToken" -o tsv)
6463
```
6564

6665
Use the URL associated to the selected key vault:
6766

68-
```
67+
```sh
6968
KEY_IDENTIFIER="https://<vault-name>.vault.azure.net/keys/test-signing-key"
7069
```
7170

7271
Perform the request using cURL, and store the result in a variable:
7372

74-
```
73+
```sh
7574
SIGNING_RESULT=$(curl -X POST \
7675
-s "${KEY_IDENTIFIER}/sign?api-version=7.4" \
7776
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
@@ -84,27 +83,27 @@ echo $SIGNING_RESULT
8483
The field `.value` in the result contains the (base64 encoded) signature.
8584
To extract the signature from the response, you can use a JSON parser:
8685

87-
```
86+
```sh
8887
SIGNATURE=$(jq -jn "$SIGNING_RESULT|.value")
8988
```
9089

9190
The signature can now be decoded from base64 into a binary, so the
9291
`sign` tool can incorporate the signature into the manifest header.
9392

94-
```
93+
```sh
9594
echo $SIGNATURE| base64url_decode > test-app/image_v1_digest.sig
9695
```
9796

9897
#### Final step: create the signed firmware image
9998

100-
The 'third step' in the HSM three-steps procedure requires the `--manual-sign` option and the
99+
The 'third step' in the HSM three-steps procedure requires the `--manual-sign` option and the
101100
signature obtained through the Azure REST API.
102101

103102

104-
```
105-
./sign --ecc256 --sha256 --manual-sign test-app/image.bin test-signin-key_pub.der 1 test-app/image_v1_digest.sig
103+
```
104+
./tools/keytools/sign --ecc256 --sha256 --manual-sign test-app/image.bin test-signin-key_pub.der 1 test-app/image_v1_digest.sig
106105
```
107106

108107
The resulting binary file `image_v1_signed.bin` will now contain a signed firmware
109108
image that can be authenticated and staged by wolfBoot.
110-
109+

0 commit comments

Comments
 (0)