Hello Everyone,

Some remarks to the discussions:

Regarding the implicit assumption of the relation between publicity and trustworthiness: the remark is true. We did not proclaim anything to be trusted, we only make the circumstances suitable for that. The remaining is not (and shall not be) in our discretion.

The highest-level goal of the security concept is to assure that the IC the customer receives indeed performs the function described by the high-level HDL code. This can be sub-divided into three major challenges:
- The layout corresponds to the HDL. This is the area where reproducible build, back-annotation and other mainly SW-defined measures apply.
- The chip at the end of our line corresponds to the submitted layout. This mainly depends on the location, organization and operation of the fab, and is beyond the scope in this phase of the project (this is the point where "open-doors" audit policy and a network of "geographically/geopolitically near" fabs applies, for example).
- The chip the user receives is the same one that came off our line. This was the topic of the Mumble session.

Regarding the side channel for HW backdoors: they are not always needed, as the goal of the backdoor may not be direct remote access only. In addition, a HW trojan may not exfiltrate anything, just "paves the way" for inserting the actual backdoor. Some use cases:
- A modified RNG (one of the referred papers describes such scenario) that has its output space reduced to a few (e.g. 1024) distinct keys of e.g. 256 bits of length: still long enough to defeat statistical proofs, but still a few enough to make random numbers (private keys generated on the host, keys for encrypted comms like HTTPS, storage encryption keys for cloud backups or HDD of laptops, etc.) guessable in real-time, thus making impersonation of the target, MITM, traffic collection, backup collection or HDD encryption bypass possible.
- A modified cryptographic hash function accelerator, that looks for a magic number in the input data, and once found, outputs an arbitrary number (e.g. specified after the magic number) as the hash. Use case: impersonating update server by DNS poisoning or boomerang routing and presenting a fake certificate containing the magic number and the hash from a legit certificate, then installing malware by defeating the archive signature verification in the same way.
- Tampered MMU logic, that looks for some handshake sequence (e.g. writing 0xdefaced into the accumulator 100 times in a row), and then silences segfaults until the next context switching
- Tampered privilege control logic, that looks for some handshake sequence (e.g. writing 0xdefaced into the accumulator 100 times in a row), and then ignores privilege violations of the given process.

Regards,
Ferenc