[NIIBE Yutaka] STM32F103 flash ROM read-out service

[tomli at tomli.me]

> While learning Chinese language, I found this service (in Chinese):
> 
>     http://www.pcbcopy.com/2016/ic_1128/1928.html
> 
> IIUC, It's a company in ShenZhen, which offers a service reading out
> from protected STM32F103, even if it uses anti-tamper feature with a
> battery.
> 
> I was aware of similar services for PIC18 or ATmega (in different
> country).  This is new for me, specifically for STM32F103.
> 
> I don't know the detail of this service, but it seems that it's not that
> expensive (from not-confirmed information by my friend).

-----

These services have came into existence as early as 2012. It is a main
way used to create cheap clones by rogue competitors of products on
the existing market. It's commonly believed STM32F1 is easy to crack,
both through physical IC decapping, or by mounting a fault injection
attack to disable the flash readout protection, or exploting the
bootloader, who knows...

You can search the keywords "STM32F1 破解" (STM32F1 Crack) in Chinese and
you'll find many advertisements and victims of copycat complaining in EE
forums. While GD32 seems to include more countermeasures in the chip,
relatively obscure and have a higher cost of attack, I can only find
one company or two cracking GD32, compared to lots of companies for
STM32. 

BTW, BasicCard and JavaCard seemed even more obscure and I cannot find
any public service of cracking.

See:
[1] http://blog.sina.com.cn/s/blog_770bd2000100zssn.html
[2] http://www.stmcu.org/module/forum/thread-608097-1-6.html
[3] http://www.pcbhf.com/xinpianjiemi/icxinghaopanding/320.html
[4] https://blog.csdn.net/sinat_36568888/article/details/52984056

-----

Common countermeasures in the industry vaires, including...

1. Use high voltage to destroy most I/O pins to render most inputs useless,
creating a smaller attack surface.
2. Hardcode chip UUID, using "security through obscurity" to refuse program
execution if a unknown ID has been detected.
3. Use proprietary secure chips that come with NDAs.

But it does not solve any real problem in the perspective of cryptography.
They are all "security through obscurity" at best, just driving out script
kiddies (or equipment kiddies?) at worst.

As I have said in the gnuk-users list, the only way to solve this problem
is using something like a secure chip, a TPM, or a cryptography coprocessor.
It is very important, but the free software community never trusted these
devices, because they can be used to carry out "trusted computing" vendor
lock-in, implement DRM, implant backdoors, etc.

My point is, if these hardware is instructed exclusively by Free Software,
the ultimate master of these devices are their users, and none of these will
be a problem. So, we need to find a security chip that comes with OPEN,
PUBLIC specs, so we can develop free software for it.

-----

In the beginning of this year, I have done some researches for this project,
I've found... Thanks to the emergence of the "Internet-of-Trash", security of
embedded devices have became a real demand, so many manufacturers now have
simple security chips that do not require any NDA nor subject to any cryptographic
regulations, yet, they are basic versions of secure chips that can seal keys.
They may not as temper-proof as a proprietary ST31 chip, but is a huge improvement
compared to generic microcontrollers.

Now I have plans to experiment with the ATECC508A chip by Atmel, if I have time.
It looks like a simple security chip with full specs, and suitable to be used with
Gnuk. The datasheet is interesting, see

[5] http://ww1.microchip.com/downloads/en/DeviceDoc/20005927A.pdf

Also, the TPM chips found on x86 systems are really underestimated by the
Free Software community, since it's a mass-produced commodity chip with full
spec available.

-----

To prevent the chip becoming a single point of failure, we can implement
"split-secret" or "double-encryption" scheme. This allows us to use the security
chip in a trustless manner - a offline attacker needs to break both STM32F1
and the security chip, before getting access to the key material. No matter
what have happened to the chip, the key is still as secure as the original
STM32F1 + KDF-DO.

For example, if a security chip allows us to encrypt and decrypt data with
its internal key, but only after a correct PIN code is provided, a simple
scheme can be:

   1. Enter PIN
   2. PIN = KDF(PIN)
   3. K1 = HMAC-256(PIN, sqrt_2)
   4. K2 = KMAC-256(PIN, sqrt_3)

So K1 and K2 is now two independent keys. It's just an example for
simplicity, a secure system should use standard, proven cryptography,
like the "Expand" stage of the "Extract-and-Expand" KDF specified in
RFC5869.

[6] https://tools.ietf.org/html/rfc5869

   5. (chip) Reset chip
   6. (chip) Set security chip PIN to K2
   7. (chip) Generate a new secret key on chip

When storing our secret,

   8. Encrypt key material with K1 on STM32, output known as C1
   9. Encrypt key material with K2 on chip, output known as C2
  10. Save C2 to STM32 ROM.

Reverse this process for decryption. Essentially, we encrypt our data
twice, first by ourselves on STM32, then by the chip with its internal
key. The two keys are both derived from the User PIN on-the-fly during
runtime, cryptographically independent of each other. As soon as power
is removed, the attacker is forced to break the security chip, the STM32
chip, and our original encryption, three times in a row.

-----

> Well, I encourage Gnuk users to new use KDF-DO feature with newer GnuPG.

Yes, KDF-DO should be an essential protection. A six-word diceware
passphrase is also recommended.

All to be said, we don't really know if the "STM32 Cracking" service really
works. Perhaps we can launch a funding campaign to accept donations, and
find one company to actually pay them to attack our existing Gnuk systems,
and see if they can recover the encrypted data from ROM.

Happy Hacking,

Tom Li
Beijing GNU/Linux User Group.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 851 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180606/f9a3bd62/attachment.sig>