Meh, dynamically typed systems are within an order of magnitude of statically typed systems, even on benchmarks that greatly benefit from the static type information.
"This backdoor has a key, which we were able to extract. If you use this key you can disable the chip or reprogram it at will, even if locked by the user with their own key."
From this, I'd say that anyone who used the backdoor would basically be able to take over the chip completely. Which is somewhat scary, considering the author says it's used in weapons systems—hopefully the author's informed an intelligence agency with the specifics.
They have procured programmable logic chips (FPGA) with the feature that the configuration data that defines the function on powerup can be encrypted/signed.
The configuration is commonly stored in a small serial eeprom (tiny 8-pin chip) and automatically read when the FPGA powers up. The content of this chip is often called "bitstream", this configuration eeprom/flash is sometimes also internal to the FPGA.
The key this configuration is encrypted with is supposed to be stored securely inside the FPGA, but they managed to extract it using undocumented commands on the "debug port" (JTAG) that the vendor explicitly claimed did not exist.
Note: This is an interface that normally is not easily accessible from the outside, but sometimes connected to a microcontroller to update the FPGA configuration.
Theoretically someone who gets access ("normal" computer backdoor over the network) to such a device might be able to re-program the chip thereby causing malfunction or add a flaw deliberately. The second scenario would be to decrypt the configuration information, "decompile" it and learn about secret algorithms or functions.
This particular chip is prevalent in many systems from weapons, nuclear power plants to public transport. In other words, this backdoor access could be turned into an advanced Stuxnet weapon to attack potentially millions of systems.
From the description I'm guessing an interface device that does something in the order of I2C/CAN/M on one end and external comms to the outside world on the other (why else would require "sophisticated encryption standard").
I'm going to put my speculation hat on here. Others here have mentioned that the chip in question is an Actel FPGA.
First, we must understand what these are used in: embedded systems. Typically, at the heart of most embedded systems you have two possibilities: a microcontroller or microprocessor, or an FPGA. The microcomputers run some kind of firmware (instruction set fed to a processor architecture) which is completely different then an FPGA which are actually re-configurable transistor arrays to implement fixed digital logic. This transistor configuration is typically loaded from EEPROM on power up - so it is stored/uploaded by a user somewhere after they've done some work in their CAD tool.
In either case, whether it be firmware written for a microprocessor based system, or the "firmware" for an FPGA (I forget what that logic routing configuration format is called - technically not firmware since it's not instructions) it is likely that whoever wrote it would want to protect it from being read or protect their device from having another firmware loaded on. There are many schemes to do so, it is possible that this is what has been compromised.
Taken from text:
"This particular chip is prevalent in many systems from weapons, nuclear power plants to public transport. In other words, this backdoor access could be turned into an advanced Stuxnet weapon to attack potentially millions of systems."
This is bad. Physical objects are a way to permanently an irrevocably establish a position. It is not possible to delete or change a textbook on the fly. This will open up textbooks to instant manipulation for political goals.
I always felt that companies were in a very unfortunate position. Almost everybody I now who was smart went to graduate school. How does one higher in that kind of environment? It always seemed companies received mediocrity; at best.
I worked on programming cutting robots and I can that they were extremely computationally intensive. They needed to constantly perform SVD to find stable solutions. There is a lot of innovation in this field (applied robotics).
