4 ms·

> tour de force Hardly. This is not a secure device. It is more of a "no hidden code" device (like a ME or CPU microcode), that you the owner don't know about.

> tour de force Hardly. This is not a secure device. It is more of a "no hidden code" device (like a ME or CPU microcode), that you the owner don't know about. Like the portable version of a Raptor Talus II.

ncmncm 4y ago
How is it not secure? In particular, how is it less secure than some other device you can specifically identify?
- throwaway654329 4y ago
  For one: it is almost entirely based on a non-free tool chain. They rely on a non-free Xilinx tool chain for the spartan 7 (XC7S50) FPGA which is the heart of the device. They do use an ice-40 (which has a free tool chain as well as a non-free tool chain) for the EC. Why didn’t they use another well supported FPGA with a free tool chain? Isn’t there an FPGA that has a free tool chain and matches or beats the performance of the spartan 7? It would certainly beat the security story of the spartan 7. Does the required non-free tool chain required to build the FPGA related code for the spartan 7 even run on non x86 CPUs these days? And how do we know that Xilinx doesn’t backdoor things when their tool chain is used? We don’t, and it’s weird to suggest that this is auditable or secure when compared with the rest of the system. Trusting trust is an old talk and the lessons still apply to FPGA toolchains, doesn’t it? I have two of these devices sitting on my desk and I am extremely frustrated that they chose a Xilinx Spartan 7 with a non-free tool chain. There is some progress to make a free tool chain for the Spartan 7, but they’re currently not using that work according to their git repo. Why not? I would guess because its a free software concern that isn’t very interesting and it’s just a lot of work. The Silicon Labs WF200 is also something that is questionable but it appears to be much more isolated than the spartan 7 FPGA. A novel approach might have been an SDR and another FPGA which could do Wi-Fi or another radio protocol. That is however obviously a lot of work, and I fully understand why this chip is isolated rather than fully redone from scratch. Still for such a device, I hope they eventually do tackle this problem too. If anyone can do it, it’s Sean and bunnie.
  - transpute 4y ago
    I wonder if supply chain constraints prevented them from using an Artix-7 FPGA, for which a libre (reverse engineered) tool chain is available. Bunnie used an Artix-7 (XC7A35T) for the NeTV2 project, https://www.crowdsupply.com/alphamax/netv2 https://www.crowdsupply.com/alphamax/netv2 & https://www.bunniestudios.com/blog/?p=5018 https://www.bunniestudios.com/blog/?p=5018 > LiteX produces a design that uses about 20% of an XC7A50 FPGA with a runtime of about 10 minutes, whereas Vivado produces a design that consumes 85% of the same FPGA with a runtime of about 30-45 minutes. An early Precursor blog, https://www.crowdsupply.com/sutajio-kosagi/precursor/updates/evaluating-our-hardware-security https://www.crowdsupply.com/sutajio-kosagi/precursor/updates... > Precursor uses the Xilinx 7-series of FPGAs for its trusted root. This series of FPGAs is perhaps one of the most extensively studied from a security perspective; dozens of papers have been published about its architecture and vulnerabilities. As a result, its key stores have been reverse engineered and analyzed down to the transistor level ... its fuse boxes and encryption engine have been analyzed down to the gate level and there have been no findings so far reporting special access modes for law enforcement, undocumented shadow key stores, or other bugs that could lead to fully remote exploits or back doors.
    - throwaway654329 4y ago
      It’s a good question - the analysis seems to ignore the need for non-free software to properly build the FPGA bitstream files from source. We have no way to know the Xilinx tools are safe. None of those papers address the tool chain question AFAIK. Additionally, it is difficult to know if a user has downloaded the real Xilinx software tool chain; the git repo ( https://github.com/betrusted-io/betrusted-soc https://github.com/betrusted-io/betrusted-soc ) from has no verification step for step 7. There is a public key and a hash, they could include this in the repo and at least it would make a targeted attack a little more difficult. Additionally they could use a git sub module for step 6 and have a better risc-v supply chain security story. It seems trivial to fix that detail, so I am sure it will be fixed if they’re alerted. These setup steps are trivial security issues, simple to fix, and possibly only theoretically an issue for a targeted attack. What isn’t theoretical is that the we cannot trust the non-free Xilinx tool chain as we can’t see the sources, so we don’t know that they’re not currently doing something bad (bugs or backdoors) or won’t later be doing something we don’t want. Frustrating! Related: https://news.ycombinator.com/item?id=32187651 https://news.ycombinator.com/item?id=32187651
throwaway654329 4y ago
I’m not convinced there aren’t binary blobs in the precursor at key locations which can sabotage both being free and open, as well as having a potential security impact. To be fair: non-free hardware and/or non-free software are not really claimed. The claim is somehow inspectability which is poorly defined. Who is inspecting it? I trust bunnie and Sean, but they can’t do everything. They need support and help to succeed. For example: The Wi-Fi chip is isolated because it is very much non-free. I don’t see much of a security claim here and there is a limited transparency claim. The claim is that it is isolated and if it is misbehaving, it won’t be able to harm the overall system other than perhaps denying service. I am curious if it has randomized MAC addresses and I am equally curious if radio fingerprinting is considered as part of the threat model for identification reasons. I would also like to know if DPA is considered in the threat model of the chip being malicious - @bunnie? The Spartan 7 is well analyzed and as a result the claim is that it is practically secure. This is reasonable BUT while necessary, it is not sufficient analysis. The analysts entirely sidesteps project BULLRUN style sabotage. For such a project to resist state level attackers, I would wager one attack on this FPGA is pressuring Xilinx, and another would be by performing a software supply chain, Trusting your compiler is a problem we face, and imagine if Xous was only buildable with a non-free compiler? I don’t think anyone would accept this and yet with FPGAs, that’s the current state of things. With all due respect ( and bunnie/Sean deserve a lot of respect!): it is irresponsible to encourage the use of and to claim this is secure unless the authors have audited the non free software in some meaningful way, and they additionally also know bay the thing they audited is the same as what users use. We know what Xilinx claims. We also know what large-scale adversaries are up to. We should assume at least one bad actor from the top four intel agencies are working to sabotage them. There are other adversaries to consider and there are a LOT of them, well funded, and highly motivated. It just makes sense and we KNOW this is ongoing at nearly every level. Making it free software won’t stop such sabotage but it will make it much more likely to find such sabotage. What’s the plan to discover such sabotage with the current tool chain? Currently I see none, and this is unreasonable given the claims of security. They should really flesh this out, and spark the discussion. With all of that said, it’s so close to perfect. The project needs support and my criticisms here are not intended to say anything other than how tough the problems are for such a device. Buy one or two! Help free the FPGA tool chain. Help develop useful post-quantum cryptography implementations (eg CSIDH) to build on the great Curve25519 work that has already been done. This project is important and if it was twice the price to get a fully free FPGA, it would be worth it. I would also like a tiny camera module to scan and exchange air gapped data with QR codes, or a small modem like communication protocol with the audio port. Could easily do IR for example. So many great opportunities here, and just a few gaps to close, even if they are big ones. It’s still better with these problems than nearly all other options, hands down.

ncmncm 4y ago

How is it not secure? In particular, how is it less secure than some other device you can specifically identify?

throwaway654329 4y ago
For one: it is almost entirely based on a non-free tool chain. They rely on a non-free Xilinx tool chain for the spartan 7 (XC7S50) FPGA which is the heart of the device. They do use an ice-40 (which has a free tool chain as well as a non-free tool chain) for the EC. Why didn’t they use another well supported FPGA with a free tool chain? Isn’t there an FPGA that has a free tool chain and matches or beats the performance of the spartan 7? It would certainly beat the security story of the spartan 7. Does the required non-free tool chain required to build the FPGA related code for the spartan 7 even run on non x86 CPUs these days? And how do we know that Xilinx doesn’t backdoor things when their tool chain is used? We don’t, and it’s weird to suggest that this is auditable or secure when compared with the rest of the system. Trusting trust is an old talk and the lessons still apply to FPGA toolchains, doesn’t it? I have two of these devices sitting on my desk and I am extremely frustrated that they chose a Xilinx Spartan 7 with a non-free tool chain. There is some progress to make a free tool chain for the Spartan 7, but they’re currently not using that work according to their git repo. Why not? I would guess because its a free software concern that isn’t very interesting and it’s just a lot of work. The Silicon Labs WF200 is also something that is questionable but it appears to be much more isolated than the spartan 7 FPGA. A novel approach might have been an SDR and another FPGA which could do Wi-Fi or another radio protocol. That is however obviously a lot of work, and I fully understand why this chip is isolated rather than fully redone from scratch. Still for such a device, I hope they eventually do tackle this problem too. If anyone can do it, it’s Sean and bunnie.
- transpute 4y ago
  I wonder if supply chain constraints prevented them from using an Artix-7 FPGA, for which a libre (reverse engineered) tool chain is available. Bunnie used an Artix-7 (XC7A35T) for the NeTV2 project, https://www.crowdsupply.com/alphamax/netv2 https://www.crowdsupply.com/alphamax/netv2 & https://www.bunniestudios.com/blog/?p=5018 https://www.bunniestudios.com/blog/?p=5018 > LiteX produces a design that uses about 20% of an XC7A50 FPGA with a runtime of about 10 minutes, whereas Vivado produces a design that consumes 85% of the same FPGA with a runtime of about 30-45 minutes. An early Precursor blog, https://www.crowdsupply.com/sutajio-kosagi/precursor/updates/evaluating-our-hardware-security https://www.crowdsupply.com/sutajio-kosagi/precursor/updates... > Precursor uses the Xilinx 7-series of FPGAs for its trusted root. This series of FPGAs is perhaps one of the most extensively studied from a security perspective; dozens of papers have been published about its architecture and vulnerabilities. As a result, its key stores have been reverse engineered and analyzed down to the transistor level ... its fuse boxes and encryption engine have been analyzed down to the gate level and there have been no findings so far reporting special access modes for law enforcement, undocumented shadow key stores, or other bugs that could lead to fully remote exploits or back doors.
  - throwaway654329 4y ago
    It’s a good question - the analysis seems to ignore the need for non-free software to properly build the FPGA bitstream files from source. We have no way to know the Xilinx tools are safe. None of those papers address the tool chain question AFAIK. Additionally, it is difficult to know if a user has downloaded the real Xilinx software tool chain; the git repo ( https://github.com/betrusted-io/betrusted-soc https://github.com/betrusted-io/betrusted-soc ) from has no verification step for step 7. There is a public key and a hash, they could include this in the repo and at least it would make a targeted attack a little more difficult. Additionally they could use a git sub module for step 6 and have a better risc-v supply chain security story. It seems trivial to fix that detail, so I am sure it will be fixed if they’re alerted. These setup steps are trivial security issues, simple to fix, and possibly only theoretically an issue for a targeted attack. What isn’t theoretical is that the we cannot trust the non-free Xilinx tool chain as we can’t see the sources, so we don’t know that they’re not currently doing something bad (bugs or backdoors) or won’t later be doing something we don’t want. Frustrating! Related: https://news.ycombinator.com/item?id=32187651 https://news.ycombinator.com/item?id=32187651

throwaway654329 4y ago

I’m not convinced there aren’t binary blobs in the precursor at key locations which can sabotage both being free and open, as well as having a potential security impact. To be fair: non-free hardware and/or non-free software are not really claimed. The claim is somehow inspectability which is poorly defined. Who is inspecting it? I trust bunnie and Sean, but they can’t do everything. They need support and help to succeed. For example: The Wi-Fi chip is isolated because it is very much non-free. I don’t see much of a security claim here and there is a limited transparency claim. The claim is that it is isolated and if it is misbehaving, it won’t be able to harm the overall system other than perhaps denying service. I am curious if it has randomized MAC addresses and I am equally curious if radio fingerprinting is considered as part of the threat model for identification reasons. I would also like to know if DPA is considered in the threat model of the chip being malicious - @bunnie? The Spartan 7 is well analyzed and as a result the claim is that it is practically secure. This is reasonable BUT while necessary, it is not sufficient analysis. The analysts entirely sidesteps project BULLRUN style sabotage. For such a project to resist state level attackers, I would wager one attack on this FPGA is pressuring Xilinx, and another would be by performing a software supply chain, Trusting your compiler is a problem we face, and imagine if Xous was only buildable with a non-free compiler? I don’t think anyone would accept this and yet with FPGAs, that’s the current state of things. With all due respect ( and bunnie/Sean deserve a lot of respect!): it is irresponsible to encourage the use of and to claim this is secure unless the authors have audited the non free software in some meaningful way, and they additionally also know bay the thing they audited is the same as what users use. We know what Xilinx claims. We also know what large-scale adversaries are up to. We should assume at least one bad actor from the top four intel agencies are working to sabotage them. There are other adversaries to consider and there are a LOT of them, well funded, and highly motivated. It just makes sense and we KNOW this is ongoing at nearly every level. Making it free software won’t stop such sabotage but it will make it much more likely to find such sabotage. What’s the plan to discover such sabotage with the current tool chain? Currently I see none, and this is unreasonable given the claims of security. They should really flesh this out, and spark the discussion. With all of that said, it’s so close to perfect. The project needs support and my criticisms here are not intended to say anything other than how tough the problems are for such a device. Buy one or two! Help free the FPGA tool chain. Help develop useful post-quantum cryptography implementations (eg CSIDH) to build on the great Curve25519 work that has already been done. This project is important and if it was twice the price to get a fully free FPGA, it would be worth it. I would also like a tiny camera module to scan and exchange air gapped data with QR codes, or a small modem like communication protocol with the audio port. Could easily do IR for example. So many great opportunities here, and just a few gaps to close, even if they are big ones. It’s still better with these problems than nearly all other options, hands down.