This is a pipe dream, but having self-managed local foundries (à la hackerspace) would be awesome to ensure that RISC-V stays secured, decentralised and competitive.
I think you are confused. RISC-V is just an ISA, not a hardware design, so it can't have a backdoor or, on the other hand, be free of them.
With a closed ISA, the only manufacturers are closed-source and I can't verify the chip is secure under any circumstances.
With an open ISA, I may not be able to verify all designs are secure, but, I can verify that some are secure and choose one of those.
You are conflating the ISA with its hardware designs. I'm not an expert, but imagine an ISA being like a C library API, in that case the hardware would be the APIs implementation.
Although fabless design companies like Allwinner and fabrication companies like SMIC both exist in China, there is accessible pathways to China-free chips, especially if you're willing to pay the premium for TSMC's high end manufacturing.
You can't have a manufacturing-hostile environment here in this country and expect to be able to buy phones that are owned by you instead of President Xi and just on loan to you.
Remember the fight over clipper chips? We've rearranged the electronics industry so that everything has a clipper chip, it's just outsourced and you can't see the details.
(I say this like all of y'all reading this aren't younger than 35 and _remember_ the clipper chip).
It's an open source processor, right? (Not just the RISC-V instruction-set, but the specific chip.) Could the chip be compared against that design to check for backdoors?
The term open source was used in the article, but did they mean that in an accurate sense, or was it just empty marketing? Also, I can't find the source after a short search.
> Could the chip be compared against that design to check for backdoors?
Don't know, but I'm sure much expertise, man-hours and expensive equipment would be necessary. Maybe prohibitively so.
I think the closest you're going to get to "verifiably secure" is an FPGA based core.
The idea would be to somehow scan the design of the chip, presumably using an electron microscope as progre said, and compare it against the design's netlist. This isn't something I know much about, so perhaps it's not at all practical, but at least in principle this should be possible for chips with open designs.
> You could thwart all that with a microcode layer anyway.
I don't see that the particular techniques used in the design, such as microcode, would matter. The question is whether the published netlist matches the one on your chip.
> I think the closest you're going to get to "verifiably secure" is an FPGA based core.
I agree that's the most practical solution.
You're missing the fact that microcode lies between the hardware and the user-supplied machine code. Thus hardware+microcode is what has to be verified.
If it's open hardware, I presume they'll publish the microcode.
I do think that microcode opens up the possibility of subtle injections to follow code/hardware paths you might not easily predict.
A really good talk on reverse engineering an ISA implementation: https://youtu.be/KrksBdWcZgQ
As far as I can tell from the software world though, it's pretty rare for anyone to try this kind of thing. When their software is Free and Open Source, some companies put telemetry in there (e.g. Visual Studio Code), but it's very rare for there to be anything this malicious hidden away in publicly viewable code.
The Linux world has collectively agreed to trust SELinux, for instance, despite that it originates from the NSA.
So you need to scan the microcode; this demands care I think. Whatever you are reading could be reporting itself incorrectly, if you were to read it through software (that is itself influenced by the microcode). One solution would be to have a hardware module, a verified function that dumps the microcode and cannot be significantly influenced by the microcode itself.
Another issue could be program obfuscation, where you hide behavior inside your program. Since microcode is quite small, I guess the risk is also small.
As a curiosity, as far as I know Cryptographic theory at this point hasn't proved whether efficient white-box obfuscation is possible! (specially for the case of obfuscating cryptographic keys), but there are some proposed methods that generate very large obfuscated programs, and there are several manual techniques (by experienced programmers) that make it difficult to decode to figure out function (we don't know if this could be generalized and automated).
What there will be is a 0-stage boot ROM -it's not microcode, just RISC-V code -essentially the code that knows how to get from the first instruction after reset up to and including the loading of u-boot (or whatever) - if you're interested in how open a system is ask to see that code, and all the code that runs in m-mode (probably u-boot-spl and opensbi both of which are open source)
That chip is literally an explicit backdoor.
Authentication worked by the phone displaying a hash of the session key, and the two users were expected to read the key hash to each other and recognize each other's voices. If they were being MitM'd, they wouldn't have identical session keys. Alice and Bob's authentication procedure would then still work just fine, since they'd still have identical session keys.
If the government were wiretapping Alice, they'd of course detect the tampering because they'd be getting garbage data/failed checksums, but otherwise, the tampering would be undetectable, and Alice and Bob get hardware-accelerated 80-bit Skipjack encryption of their data stream, back when 56-bit DES was generally considered reasonably safe and 80-bit symmetric keys were considered sufficient for data classified SECRET and below.
(Or maybe the tampering could be detected when the wiretappers went to look up Alice's fixed DH public key and couldn't find it in their escrow database... I forget if the escrow worked by having a database or if the chip encrypted the DH secret key with a master key and transmitted it at the start of every session. In any case, the whole thing wasn't that well thought out. It's also possible the DH exchange was signed using a malleable signature scheme using the same prime as DH, allowing Alice to raise the DH public key to a known-only-to-Alice power and calculate the power needed to raise the signature in order to still get a valid signature on the modified DH public key. Clearly, I forget the exact details.)