[NIIBE Yutaka] STM32F103 flash ROM read-out service
tomli at tomli.me
tomli at tomli.me
Fri Jun 8 05:35:32 CEST 2018
> My point is that it's not only obscurity, but it's too far to be
> scientific. I wonder the reason why people can rely on that, seriously.
The reason is simple, there is no other options.
To an extent, the internal details of all hardware is inaccessible.
You may program a RISC-V CPU on a FPGA, but the operation of the
FPGA is ultimately inaccessible. But RMS believed this is the result
of the nature of hardware - software is more like a set of abstract
instructions, or ideas, but hardware, as it is today, mere physical
objects. While it is a good thing to apply the princple of free
software to hardware design, just like you did in FST-01, for chips
and many types of other hardware, most of the time it's not possible,
and sometimes not even needed to. Perhaps in the future the chips can
be made just like how small prototypes is made by 3D printer. "In the
meantime, there is no need to reject hardware with nonfree designs on
principle." Therefore, many problems of crypto chips also exist on
nearly all types of chips.
On the one hand, you have standard embedded controllers with inaccessible
internal details, on the other hand, you have specialized crypto chips
with inaccessible internal details. Provided tools and documentations for
development is freely available, of course, you can assume the crypto
chips, actually, may not be more secure than the standard embedded
controllers as advertised. In the same time, it is also unreasonable to
think a standard embedded controller is superior to the crypto chip.
Probabilistic speaking, the crypto chip should have included more counter-
measures, and it should be at least a little more expensive to crack.
Think about it, if nothing made a crypto chip inherently more "sinnful"
than any other chips, why are we keep questioning it? Just like what we
are doing now? I think the reason is that the crypto chips are "advertised"
and "guaranteed" to be secure, and that where all the troubles begin. If
these chips are never claimed to be secure, I guess we won't have problem
Bascially, I don't think the crypto chips are evil by themselves, I
completely agree independent verification of its security claim is an
issue. Meanwhile, the best thing we can do is avoid chips with private
specs and tools, and stick to common commodity chips as much as possible.
Thanks to IoT, we now have chips like ATECC508A that are expected be to
use as a common component in IoT device, just like a MCU, and I expect
more and more similar products enter the market. Then at least we'll
get some standard crypto chips of choices that are made by lots of
manufacturers. We should also expore the option that doesn't require
us to trust the crypto chip completely.
These, at least, can make us feel a little more confident...
> > Now I have plans to experiment with the ATECC508A chip by Atmel
> Good. If it's going well (or not), I would recommend to make a chip
> with similar functionality or more (as NdK suggested another curve).
The algorithms or curves the chip uses doesn't even matter in this
case I believe, all it is needed to do is sealing a secret key inside,
no matter it's an AES key, a NIST P-curve private key, or even a 3DES
key, since the chip is only used for the outer-layer of encryption of
But as pointed out beforehand, the latency of this scheme may be
unacceptable, and one may have to offload the crypto computation to the
chip, and this is unacceptable to me. I'll find out whether it is the
case or not soon.
> I have a TPM chip from Infineon, but the spec how to use it
> (independently, out of scope of TCG) is not available to public, as far
> as I know. In some cases, for my experience, it requires NDA documents,
> non-free tools and drivers/libraries. At leaset, Infineon suggested so.
> But I'm an old engineer, the situation may be changed now.
> Could you please let me know if any specification is available? Then,
> making something like Yubikey or Nitrokey Pro, using a TPM chip will be
I made a mistake. Apparently TCG was all it's needed to use the chip,
but it is not? Can't one just use a subset of the crypto in TCG spec
to implement a "secret-sealing" scheme? Or the TCG spec is just for the
TPM module on PCs, the chip itself is still locked behind proprietary
Beijing GNU/Linux User Group
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 851 bytes
Desc: Digital signature
More information about the Gnuk-users