[NIIBE Yutaka] STM32F103 flash ROM read-out service

[Leo Gaspard]

On 06/06/2018 06:56 PM, NdK wrote:
> Il 06/06/2018 17:49, Tom Li via Gnuk-users ha scritto:
> 
>> BTW, BasicCard and JavaCard seemed even more obscure and I cannot find
>> any public service of cracking.
> Because those are (at least should be) based on secure chips.
> 
>> 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.
> The only secure (even against decapping attacks) device I know of is a
> very old parallel-port "key" a friend described me ~25y ago.
> It was made of 3 silicon layers: the outer ones only contained interface
> circuits and 'randomness' while the keys and the logic were in the
> central layer. Trying to remove the outer layers destroyed the random
> patterns that were used as 'internal master key', rendering the rest
> completely useless.

Some people do reverse-engineering based on photons emitted by
transistors switching. These would get through this shielding.

Unfortunately, I can't find again the link to the conference talk where
I heard people explaining they did that… sorry.

Another kind of attack would be EM pulses / lasers for error-ing a
crypto computation, that would get through this shielding too.

There are defenses against these attacks (well, for the
transistors-emitting-photons attack I'm not really sure), that are
deployed in secure elements. Attacks like this are tested by CC/EAL
evaluation laboratories.

All that to say: hardware security, to me, is a way to increase the cost
of the attacker to perform an attack. All devices are eventually
vulnerable, given the right price, the point is to make attack more
costly than the benefit from breaking the card and/or than finding a way
around the card. (I'm not going to extend this point to software
security, but I'd think it most likely holds there too)

Oh, and also to say: choosing between a non-secure-element open-source
token and a secure-element NDA-ed-and-thus-non-open-source token is not
an obvious choice.

HTH,
Leo