On Mon, 2019-04-15 at 23:19 +0200, Éger Ferenc wrote:
Hello Everyone,
Some remarks to the discussions:
....
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
All true, but don't you think you need to draw a line somewhere ?
It seems this group is being overly paranoid (no offense intended).
For example, everything before handing the design over to foundry is the customers responsibility. Just as it is with any commercial foundry today. If I fail to ensure and understand that my code is free of any malware, than it is my problem and the foundry can not be held responsible.
I think you need to decide what you are trying to accomplish, and clearly document it and allow a customer to understand the potential risks. Than you will need to work with each customer on a case by case basis to ensure that malware can not be introduced in to the flow (e.g. use end to end encryption in all communications).
And at the foundry, you need to vet your employees and contractors and implement redundant reviews of the process, to avoid any modification and malware insertions.
Al this talk about implementing security is void, if the human factor is not addressed.
Again, the models of commercial foundries today can be a good starting point.
Regards, rudi =============================================================== Rudolf Usselmann, ASICS World Services, LTD, www.asics.ws Your IP Partner: SAS 12G, SATA-3, USB-3, SD/MMC/SDIO, FEC, etc.
The agony of poor quality remains long after the joy of low cost has been forgotten
This email message may contain confidential and privileged information. Any unauthorized use is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.