Tomu, a tiny ARM microprocessor which fits in your USB port

What IP issues can you imagine happening considering ARM SoCs are the most widespread processors in existence with many, many different manufacturers?

Regarding side-channel attacks such as you mention, all processors are subject to this vulnerability to various degrees. Do not expect a project such as this to have any mitigation for that type of attack.

The only way to clear that bit is to erase the entire flash, with the notable exception of the user data section, so don't put the secret in there :).

Relevant recent discussion: https://news.ycombinator.com/item?id=17587673

>The SC4-HSM is designed to defend against a compromised client machine, i.e. an attacker who pwns your laptop or desktop machine. If you think about it, this is the only threat model that makes sense for dedicated secure hardware. If you can trust that your client machine is secure, you don't need an HSM.

From my prospective, that's the bare minimum threat model for an open secure hardware device. I also include unsupervised physical access to the device. My ideal HSM would also provide robust protections against a myriad of complex hardware-level attacks - JTAG debugging, power & RF analysis, glitching, de-encapsulation just to name a few.

Of course, a cheaper HSM which lacks advanced hardware level protections can still offer a lot of protection against common threat vectors, and physical access threats can be mitigated to some extent by keeping the device in a secure location or on your person.

[1] https://github.com/BarnabyShearer/u2f-zero

8051 uses several (typically 4 or 12, etc. [1]) clock cycles for one actual machine cycle. So an instruction that takes "2" cycles, can actually take 24 clock cycles.

Of course, some modern 8051 clones are more efficient. Some of them can execute one instruction per actual clock cycle.

Even then, one ARM instruction can often do work of 2-10 8051 instructions. 8051 is particularly bad at pointer arithmetic (except incrementing pointer by one) and, of course being an 8-bit CPU, 16/32 bit math.

[1]: ftp://ftp.ti.com/pub/data_acquisition/MSC_CD-ROM/8051_Tutorial/tuttimng.html

"Microcontrollers (and many other electrical systems) use crystals to syncrhronize operations. The 8051 uses the crystal for precisely that: to synchronize it’s operation. Effectively, the 8051 operates using what are called "machine cycles." A single machine cycle is the minimum amount of time in which a single 8051 instruction can be executed. although many instructions take multiple cycles.

A cycle is, in reality, 12 pulses of the crystal. That is to say, if an instruction takes one machine cycle to execute, it will take 12 pulses of the crystal to execute. Since we know the crystal is pulsing 11,059,000 times per second and that one machine cycle is 12 pulses, we can calculate how many instruction cycles the 8051 can execute per second:

11,059,000 / 12 = 921,583

This means that the 8051 can execute 921,583 single-cycle instructions per second. Since a large number of 8051 instructions are single-cycle instructions it is often considered that the 8051 can execute roughly 1 million instructions per second, although in reality it is less--and, depending on the instructions being used, an estimate of about 600,000 instructions per second is more realistic."

IIRC GnuK uses the chopstx library which has already been ported (see https://github.com/im-tomu/chopstx). Not sure what else would need to be done?

"trust us"

In other words, we've been in this world for a very long time - a lot of peripherals used to have fully fledged CPUs in them already in the 70's in some cases, and some of them were user-programmable. The reduction in this in the early PC era was an exception, not the norm.