Make sure the serial number is unique on GD32

[szszszsz]

User reported, that some of his devices have the same serial number. This could come from GD32 MCU's not behaving according to the STM32 specification, having the same value in the serial number RO register.

• [ ] To investigate, if the serial number does not change at all or changes in different location.
• [x] Hash the whole register, or randomize if it is constant across GD32 MCUs.
• [x] This should affect all GD32 devices in the field (non-conservative), regardless of their current SN.
• [x] This should not affect all STM32 devices in the field.
• [ ] Inform users about need for stub keys removal and required keys import.

Firmware: latest Hardware: GD32-based, probably latest GnuPG: 2.2.27

$ gpg --card-status
Reader ...........: Nitrokey Nitrokey Start (FSIJ-1.2.15-34353135) 00 00
Application ID ...: D276000124010200FFFE343531350000
Application type .: OpenPGP
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: 34353135
(...)

[szszszsz]

With the patch below the full 12 bytes of the MCU ID is now taken into account, instead of only the last 4 bytes. Note: HW5 only. Does not introduce any changes for HW 1-4.

• https://github.com/Nitrokey/nitrokey-start-firmware/commit/1d8d9708e8330deeb76ca410a39ea256129dc1d9

To retest and reopen in case the XOR method would not suffice.

[szszszsz]

Test release available at:

• https://github.com/Nitrokey/nitrokey-start-firmware/releases/tag/RTM.12.1-rc.1

[szszszsz]

New test release available at:

• https://github.com/Nitrokey/nitrokey-start-firmware/releases/tag/RTM.12.1-RC2

Here a sha256 hash sum is calculated instead of a xor, making change more leveled over all available bytes, instead of a single one.

Test scenario:

• note the SN, current firmware version and hardware version
• update the firmware to 12.1-RC2 with nitropy
• save log from the nitropy update
• note the SN change (or none - the change happens only on the HW5)