[Libre-silicon-devel] Device security - Help wanted

Rudolf Usselmann rudi at asics.ws
Tue Apr 16 06:51:10 CEST 2019


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. 



More information about the Libre-silicon-devel mailing list