FPGA Hardware backdoors risk and counter-measures, regarding « TOR/VPN fingerprinting family anonymity breach fix » with a custom FPGA based « Single Socket » Ethernet Controller.

Jul 9 11:37

FPGA Hardware backdoors risk and counter-measures, regarding « TOR/VPN fingerprinting family anonymity breach fix » with a custom FPGA based « Single Socket » Ethernet Controller. Dear Crypto-Anarchist comrades, I had promised to write down a crypto-analysis of the solution I am proposing for the BitMessage Secure Station to fix TOR/VPN « fingerprinting family » identification technics used by spying agencies to track and desanonymize all TOR/VPN sessions. ----- FPGA Hardware backdoors risk and counter-measures, regarding « TOR/VPN fingerprinting family anonymity breach fix » with a custom FPGA based « Single Socket » Ethernet Controller. ► Fingerprints and fingerprinting identification technics : As a reminder, this identification technic family, that cannot be patched by software (Because most fingerprints are coming directly from hardware and integrated circuits unerasable serial numbers, characteristics or functionalities), consists in tagging the whole TCP/IP traffic of a user, going through TOR or VPN’s tunnels, with any kind of « fingerprints » allowing the identification of a user, into hidden channels (or not) inserted into the TCP/IP traffic generated by the applications & OS running on the user’s computer. There are two kinds of « fingerprinting based identification technics » : ◼︎ The passive ones (No specific piece of malware needed to be installed on the target’s computer) : This family includes all the known passive fingerprinting identification technics performed through web browsers. ◼︎ The active ones : They rely on a software implant, that can be installed persistently on the target’s computer, or be pre-installed in BIOS / OS or other computer subsystems at will (HDD, SSD, PCIe cards). Passive and active fingerprinting identification technics are well known, here is a paper written by fascist FEDS themselves describing them : http://cs.emis.de/LNI/Proceedings/Proceedings228/375.pdf ► The « Single TCP/IP socket » custom ethernet controller trick to disable the fingerprinting based identification technics : STMAN found this trick after studying for at least 5 years all the fingerprinting based identification technics, particularly regarding the well known TOR Browser that managed alone to destroy the whole (H)ac(k)tivists scenes worldwide, including groups like Anonymous, and pushed the whole international Free Press under the absolute control of fascist feds. Understanding how this trick stops the exploitation of all the fingerprinting based identification technics is rather simple : Building a dedicated FPGA based Ethernet Controller that « by design » can handle only one TCP/IP socket, to a fixed IP/PORT destination that are entered manually into a register into the FPGA, through a dedicated keyboard directly connected to the FPGA (To ensure no change can be made through software hacking technics of the IP/PORT of destination set into this custom made Ethernet Controller) prevents a infected computer running TOR from exploring the user’s LAN to hack other devices on the LAN in order to exfiltrate « fingerprints » that would allow the user identification : It prevents scanning the user’s LAN because only the TOR daemon will be able to establish a TCP/IP socket to a chosen TOR entry node or TOR bridge, whose IP/PORT are set « in hardware » in the « Single TCP/IP Socket Ethernet Controller ». Any other program, process, or whatever malware running on the TOR dedicated computer will have all their socket connection attempts to any other IP/PORT peer to fail, and there is no software hack possible, even from the NSA or whatever, to « alter » the behavior of the « Single TCP/IP Socket Ethernet Controller » as long as it is fully hardcoded into the FPGA. The user has only to apply strictly a simple security procedure consisting in keeping all the « fingerprints » coming from thededicated computer running TOR through this special custom made Ethernet Controller unknown to FEDS. As you can understand, we don’t indeed fix the hardware fingerprints, which would require to build from scratch a computer exclusively made out of Free Integrated Circuits that by design would contain no fingerprints. Indeed, the best we can do and we actually do with this trick is : ◼︎ Keep all the hardware fingerprints (Integrated Circuits Serial Numbers, USB and other subsystems like HDD fingerprints & serial numbers, VGA/HDMI/DVI monitors serial numbers, DDRAM modules serial numbers) of the computer that is going to be used with TOR or VPN strictly untied to the user’s identity. This is indeed done through a security procedure consisting mainly in buying a dedicated computer in cash, and dedicate it exclusively for TOR anonymous usage, EXCLUSIVELY - NO EXCEPTIONS - or the whole theory is destroyed and fucked up. ◼︎ Connect this dedicated TOR computer (Low cost Raspberry Pi, without Wifi/bluetooth, is a perfect candidate) to the user’s LAN through the custom FPGA made « Single TCP/IP Socket » Ethernet Controller, that will prevent an attacker from hacking other devices on the user’s LAN in search of fingerprints on other devices that are known to spying agencies that keep collecting every fingerprint they can to associate them to identities thanks to huge database (NSA mastering this shit). In other words, what we do is to prevent exploiting successfully the fingerprints of the dedicated TOR computer on the user’s LAN. ► FPGA Backdoors All what was said earlier would work perfectly if only we could be sure that the FPGA we are using are not backdoored. There has been several security researcher in some universities that discovered backdoors into some FPGA. This situation is not a surprise as long as agencies like NSA have backdoored almost all the integrated circuits available on the market. But FPGA are a special kind of integrated circuits, they consist mainly in a matrix of several dozen of thousands of CLB (Configurable Logic Blocks) and backdooring each CLB has indeed no interest. The only kind of backdoor that could logically be implemented into an FPGA, and that were discovered, are indeed the possibility to use the JTAG circuitry of the FPGA remotely through side/hidden channels. Such remotely controlled JTAG circuitry allows the owner of the backdoor to alter the configuration of all the CLB of the FPGA. Then we must also take care of how we going to initialize (configure) the FPGA. When powered up, FPGA have no configuration, and just after the power-up or a reset, the FPGA start its initialization sequence that consists in loading a Bitfile (A bitstream of data representing the configuration of all the CLB of the FPGA to obtain the desired cabled logical functions) from an external memory. FPGA usually have different ways to load the Bitfile from an external memory. Some booting mode of the FPGA load the data from a parallel bus, 8 bits or 16 Bits or 32 bits wide, from an external parallel bus memory, like an EPROM, while other modes allow the loading of the Bitfile from a microprocessor data bus, and others propose to use serial buses (I2C, SPI) to load the data from serial Flash memories. All those boot mode have their pros and cons. Using serial bus driven memories saves complexity and have a low pin count, but are relatively slow (It can take up to one second to have the whole Bitfile loaded into the FPGA), while parallel buses offer a very high loading speed, but use a larger pin count. As for FPGA, memories can be backdoored too, allowing the modification of their content by an attacker. And we are going to be obliged to take the backdoor risk into memories storing the Bitfile into account too. Another variable to take in account is the size of the Bitfile : Here is the Bitfile size for the Xilinx Spartan 6 FPGA family, from the smallest FPGA of this family (6SLX4 having 4000 CLB’s) to the biggest (6SLX150T having arround 150000 CLB’s) : ( Taken from Spartan-6 FPGA Configuration User Guide : www.xilinx.com Ref: 75 UG380 (v2.7) October 29, 2014 ) Spartan-6 FPGA Bitstream Length Device Bitstream Length (in bits) 6SLX4 2,731,488 6SLX9 2,742,528 6SLX16 3,731,264 6SLX25 6,440,432 6SLX25T 6,440,432 6SLX45 11,939,296 6SLX45T 11,939,296 6SLX75 19,719,712 6SLX75T 19,719,712 6SLX100 26,691,232 6SLX100T 26,691,232 6SLX150 33,909,664 6SLX150T 33,909,664 In the BitMessage Secure Station, we are going to use two Spartan 6 LX 9 , that correspond almost to the smallest FPGA of the family. Such small FPGA should be enough to implement the « Single TCP/IP Socket Ethernet Controller » and the RNG generator + the SPI port firewall and protocol checker/proxy between the two Raspberry Pi of the BitMessage Secure Station. And this is a good news that our design can fit into small FPGA’s because as you can see, the Bitfile size stays relatively small. The Bitfile size has a direct impact on the kind of external memory that can be used to store it : Large Bitfile would not fit in the biggest EPROMs available on the market, and would force us to use a flash memory, while with smaller Bitfile size, we can still use EPROMs. And this is a very good news, because most Flash memories are backdoored, and their content can be modified, leading to a persistent compromission of the configuration of the FPGA, while EPROMs are not backdoored, and their content cannot be modified remotely : The EPROM needs first to be erased under ultra-violet light for 15 minutes before being completely « emptied » , and then programmed with a programmer. In other words, using Flash memories is the least secure way to work with FPGA, but it allow easier updates of the Bitfile, while EPROM are completely safe, but upgrading their content must be done with a programmer, and the EPROM must be erased with ultra-violet light. EPROMs, because of their « window » of transparent quartz allowing to see the silicium dice and used to erase the EPROM with ultra-violet light, also allows users to inspect the dice with a microscope, allowing you to ensure there are no backdoors, are indeed the only digital electronic component that can be considered as « Free » today. Using EPROM in designs take advantage of the fact that it is not corrupt. In other words, as our priority is security, we will use two of the largest EPROM available on the market to store the two Bitfiles of the two FPGA contained in the BitMessage Secure Station. This way we can ensure no hack of the memory can be done remotely through a backdoor. Now that we have, by design, choosen EPROMs as memory storage for the two Bitfiles to solve the backdoor problem of the memory storing the Bitfiles, let’s get back to analyzing the FPGA backdoors issues in theory, and then propose several tricks that should block their usage. As explained earlier, thanks to FPGA particular internal architecture, only a certain kind of backdoors can be implemented in them, consisting in a kind of secret JTAG circuitry remotely controlled through hidden/side channels, that allow the backdoor user to alter live the configuration of an FPGA, or in case we are using external Flash memories to store the Bitfile, such circuitry can be employed to modify the content of the Flash memory itself, allowing what we would call a « persistent » modification of the behavior of the FPGA configuration. ► Strategies for fighting potential FPGA Backdoors : There are different strategies to apply to fight FPGA backdoors based on previous assumptions regarding the nature of the backdoors that have been found into FPGA by security researchers : ◼︎ Backdoor usage Detection & Prevention « by design » : The ability to detect that the FPGA configuration has been altered (Backdoor usage detection), so that it can be reloaded by resetting the FPGA that will restart its initialization cycle and reload the Bitfile from the external persistent memory attached to it (And here you understand why choosing an EPROM as an external memory for FPGA Bitfile configuration storage is the most « secure by design approach » ) • As said earlier, the first thing to do, when possible, is to use the safest kind of memory to store the Bitfile configuration of the FPGA so that the FPGA « normal » configuration can be restored very simply by resetting it. The choice made in our design to use EPROMs to store the Bitfile is the best we can do, and perfectly solves these issues. • Another trick consist in resetting the FPGA on regular interval : This is a very powerful and efficient strategy to fight FPGA backdoors indirectly. Playing with « time » is very interesting : As you know, Side/Hidden channels are usually categorized by their throughput in Bits/second. The higher the throughput of a Side/Hidden channel is, the easier it is possible to detect and identify it precisely, while the slower the throughput is, the harder or impossible it is to detect it. Taking this information in consideration, with the huge size of a Bitfile, it means that the time necessary to use the backdoor and alter the FPGA configuration using the backdoor depends directly on the actual throughput of the Side/hidden channel of the backdoor. Let’s imagine NSA would need 30 minutes to fully modify the FPGA configuration the way they want, it because very funny if we decide to reset the FPGA every 5 minutes. This way, the attacker never have the time to finish its attack. • Another trick that works with time is the randomization of the Bitfile configuration file itself each time the FPGA boots, in the same way ASLR is working at software level to protect from R.O.P (Return oriented programming) : Doing so, it is considerably slowing down an attack using the backdoor, as long as he has first do get a full copy of the Bitfile, downloading it through the Side/hidden channel, before being able to know where and what to alter in its configuration to change the behavior of the FPGA the way he wants. This means recompiling the VHDL source code of FPGA with a different seed for each user, and better, for each reboot of the FPGA. The latest being the most powerful way of doing it, but it rises the complexity of the design a lot as long as the board has to be able to self-recompile the whole VHDL source code, which is hard work to embedded in a board like the one of the BitMessage Secure Station. This means that we should choose the first option : Asking every user of the BitMessage Secure Station to recompile the VHDL code of the FPGA with a custom seed, and program himself his own EPROMs. It is not mandatory to apply this trick, but you will all understand that it makes « automation » of the attack of the BitMessage Secure Station FPGA configuration by an agency like NSA a time consuming operation, and makes the « Reset at regular interval » of the FPGA stronger. • A variant of previous trick would consist in having several EPROMs to store different Bitfile compilations with different random seeds, let’s say for instance having 4 different sets of Bitfiles stored in 4 different EPROM with an external logic to the FPGA that randomly select one of the 4 sets (Meaning selecting one of the 4 EPROMs) of Bitfiles to boot the FPGA. Doing so make it more difficult for an attacker to use the backdoor as long as he has first to have a full copy of each Bitfile, and at each reset of the FPGA, he would have first to determine which set is being used in order to alter the configuration the way he wants. If the reset on a regular interval that is shorter than the time needed to transfer informations to the attack in order for him to know which set is used, the system stays protected from the attack as long as the attacker would never know what set is used, and with 4 sets, he would have to choose one randomly too, and it gives him a probability of 1 over 4 chances to guessed the right set used. • Another trick is to use two FPGA instead of one, having the two FPGA initialized with the VHDL source code compiled with two different seeds (Resulting in a different Bitfile for each FPGA), and adding external logic to compare in real time all the output pins of the two FPGA, working in parallel, like the computers we find in planes : This is one of the most powerful approach to detect FPGA configuration alteration as long as NSA is still not God and hasn’t the ability, with the same Side/hidden channel used by its backdoor, to modify the two FPGA configuration at the same time : As each FPGA have a different Bitfile seed, the NSA would first be obliged to apply modifications for the first one, and then for the second one (And it is even possible that their backdoors don’t allow them to distinguish the two FPGA meaning the would not be able to use it because they would apply the same modification to both of them all the time, while each of them would require a specific modification adapted to each Bitfile seed), and in that case, it means the would mandatorily be a short period of time where the two mirrored FPGA don’t compute and output the same results on all of their output pins, and our external logical doing comparisons of all the output pins « pin-to-pin » on the two mirrored FPGA would detect for a brief time that there are some differences, and instantly trigger a reset of both FPGA, aborting the on going attack and usage of the backdoor. The cost of this very powerful strategy is to double each FPGA, and double the external persistent memories connected to the FPGA that store their corresponding Bitfiles. • Same trick as the precedent, but using FPGA from different vendors. IT is hard to say if it is safer or not than the previous trick, it only depends on the capabilities of the backdoor. Intuitively, it is more secure, but it also means much more complexification of the design as long as the designed have to master two different FPGA from two different vendors, having two different SDK to compile the VHDL code and so on. ◼︎ Side/Hidden channel Filtering / Blockade « by design » : The use of several tricks that should make the usage of the side/hidden channels of the FPGA backdoor circuitry hard or impossible to use for the attacker. …. to be continued, more to come very soon ….

[chan] wikileaks

Subject Last Count
Tranny Genocide Nov 18 03:20 1
VPN, privacy & Firefox (+ other Gecko browsers)* rev. 0.3.13 Nov 13 10:46 1
VPN, privacy & Firefox (+ other Gecko browsers)* rev. 0.3.12 Nov 13 10:15 1
Your privacy - VPN & Firefox (+ other Gecko browsers)* rev. 0.3.11 Nov 12 19:33 1
Why are the shills gone? Nov 5 14:17 14
HASH QUESTION Oct 30 23:39 1