It would be good when Gnuk token supports some sort of "firmware upgrade" feature, which doesn't require any additional hardware such like JTAG/SWD debugger.
Then, users will be able to upgrade the Gnuk firmware.
To support firmware upgrade of Gnuk Token, I am considering adding the feature to Gnuk, instead of using existing DFU program or extending DFU program. This article explains about possible firmware upgrade feature of Gnuk.
Gnuk Token on a board with simple DFU considered bad
If the board has DFU (Device Firmware Upgrade) program like DfuSe, users would be able to use that.
Yes, this is true. It is convenient feature, for development stage.
But if DFU program on the board is not good enough to protect content on flash ROM, it means that it is possible for anyone to download content of internal flash ROM.
Thus, I have been recommending (and still recommend) killing DFU program for such boards with DFU, when using it as Gnuk Token for real use. Installing Gnuk program by JTAG/SWD debugger is needed.
Even if DFU program on the board respects flash ROM protection, Gnuk Token with DFU program is weaker. That's because: Gnuk Token with no DFU program is useless for other people than its owner of keys. Gnuk Token with DFU program is useful for anyone since they can override (update) firmware and can use it for their own purpose.
It is safe when keys and other data will be erased on firmware upgrade
It would useful if firmware upgrade could be done keeping keys and other data.
However, if firmware upgrade is possible by anyone, it means that it would be possible to install a program to read-out content of keys and other data.
Thus, for general purpose DFU, it is better to erase all content of flash ROM on upgrade for security. See DFU consideration.
DFU with access control
If we could extend DFU program to support authentication and/or access control, the problems above can be solved. The feature would be authentication by pass phrase, authentication by challenge/response (by public key or shared secret), or content verification (by public key or shared secret).
So, shall we extend DFU program?
No, it would be better for Gnuk to take another approach. That's because extending DFU, DFU program becomes complex and larger, and it duplicates many features between Gnuk, like USB communication, crypto things and key handling.
Gnuk approach for firmware upgrade
Gnuk's approach for firmware upgrade is to divide the task into two:
- Gnuk does USB communication, authentication and authorization (possibly complex things)
- Simple flash upgrade program (simple flash writing)
Firmware installation and relationship betwee Gnuk and flash upgrade program
It is an administrator of a token who has the control of firmware installation. After authentication, an administrator is possible to send firmware binary image to Gnuk Token and request installation.
FST-01 has external flash ROM (4MB) and we can take advantage of it. An administrator writes a binary image on the external flash ROM (through Gnuk process on the device), and request installation to internal flash ROM on MCU.
In the internal MCU, Gnuk program and small flash upgrade program on internal flash ROM are placed like:
+-----+ | | ... | | Gnuk program | | +-----+ | | OpenPGP card data +-----+ | | OpenPGP keys +-----+ ... +-----+ | | flash upgrade program +-----+
When Gnuk accepts 'request installation' command, it finishes the embedded operating system (i.e., stop all drivers including USB communication, stop system tick timer, etc.), and gives control to flash upgrade program.
Flash upgrade program runs free standing environment, with no interrupts enabled. Since it accepts no interrupts, the program is free to update "interrupt vector area" of flash ROM.
Flash upgrade program does some sanity check (such as checksum) against the image on external flash ROM, and if all is OK, it copies the content to internal flash ROM, then causes hardware RESET.
While flash upgrade program should be small and stable enough, it make sense for Gnuk side to support updating the flash upgrade program itself. After all, no program can be free from bugs.
Public key authentication for admin privilege
Currently, OpenPGP card specification only defines authentication by pass phrase for administrator access. It is possible to enhance it to allow (administrator's) authentication by public key technology. That is, admin is able to register her public key to Gnuk Token, to get privilege by challenge/response authentication.
The authentication process is like this: host side requests a challenge to the token by GET_CHALLENGE command. Host side signs the challenge by admin's private key and sends back it to the token by EXTERNAL_AUTHENTICATE command. Token examines response with registered public key, and if it's OK, the privilege as admin is granted.
Authorization for firmware upgrade
It would be useful when we can register multiple public keys to Gnuk Token for firmware upgrade and there is a flag to control authorization to keep keys and other data.
- An administrator registers her public key A with authorization flag "on".
- She registers public key B of vendor with authorization flag "off".
- She uses key A to upgrade firmware of the Gnuk Token by herself.
- Key B can be used as backup, but it is only possible for key B to upgrade firmware with erasing all data (keys and other data). This prevents Gnuk Token becomes garbage (when she lost key A), but keeps important data as secret.