CREATED BY MICHAEL STRONG ON 4/9/2019
click above to view developer comments to this article

NOX ADMIN - UPDATE SERVICE

ecdsa Package validation

NoxAdmin is the application process which runs independently of the wallet application, its purpose is to enforce restrictions and overall OS policies, store the device's unique private key in TEE (Trusted Execution Environment), open the wallet application upon device startup, and perform periodical updates of the wallet application as these updates become available. So far there have been 2 NoxAdmin versions, the last being DMA-2. The NoxAdmin firmware package is never updated automatically and the device won't ever prompt users for a NoxAdmin update, instead, there are special codes which change in each NoxAdmin version, where manual entry of the code is required if a newer version becomes available and if instructions (now unique) have been officially communicated to users. That being said, we don't foresee future need for any change to the current DMA-2 firmware.

As part of DMA-2 there have been significant changes to the update process, where (a) wallet update requests require authentication from the update endpoint, and (b) prior to standard certificate based policies enforced at OS level, NoxAdmin now performs ECDSA validation with SHA2 hash of all package bytes along with signature obtained from the update endpoint, and determines if the signature is valid for the single pre-set public key, which cannot be altered without replacing the entire NoxAdmin firmware with a newer version under the existing certificate policy, as described above. Neither the update service nor any other server process has the corresponding private key needed to create this signature; the package signing activity takes place outside of all service and network resources. The update will fail if the signature provided by the update endpoint is not valid for the expected public key.

All update events are reflected in the Transparent WS stream, identified with the "NoxUpdateECDSA" endpoint tag. Developers, after registering their public key, may emulate the device's update process and obtain the update package to examine outside of the device prior to install. Please review the following methods for authenticating update requests and initiating the package transfer.

|> UPDATE ENDPOINT
https://bitfi.com/NoxUpdateECDSA/NoxDevice.aspx
|> REQUEST CURRENT VERSION OF WALLET PACKAGE
Step 1. Authenticate by getting message to sign.
Request Parameter: HIDVersionRequest (value of device id)
Request Parameter: DIDRequest (value of device public key)
Response: Unique Base64 string for signing.

Step 2. Sign message received in Step 1 and submit signature.
Request Parameter: AuthVersionRequest (value of signature in lower-case hex)
Request Parameter: DIDRequest (value of device public key)
Response: Value of current version (ie, "109")
|> GET SIGNATURE OF CURRENT WALLET PACKAGE
Request Parameter: HIDSignatureRequest=true
Response: value of signature in hex

Example, at time of this article signature for v109 is:
3044022030faf33e3e7c92d4afcae5f22cec355bc2cff76051c320dd042474842db702
fb022030d9c40bc69efdd98f3a8a3444e1bf594efc217818913852e203335408abdae9
|> REQUEST FILE TRANSFER OF THE WALLET PACKAGE
Step 1. Authenticate by getting message to sign.
Request Parameter: HIDWalletRequest (value of device id)
Request Parameter: DIDRequest (value of device public key)
Response: Unique Base64 string for signing.

Step 2. Sign message received in Step 1 and submit signature.
Request Parameter: AuthWalletRequest (value of signature in lower-case hex)
Request Parameter: DIDRequest (value of device public key)
Response: File transfer (package bytes)

The device id is a Guid type value, like: a4972ba5-0283-5e3e-b1d7-e412a0e7bba7
The device public key for this service should be key value without hashing.