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

BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6
Jul 6 11:46

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. ◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ PART 1 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎ ► 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. Doing so, the user has only to apply a simple security procedure consisting in keeping all the « fingerprints » coming from the 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. ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ END OF PART 1 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ Next parts coming very soon.

[chan] Crypto-Anarchist Federation
Jul 7 03:28

I do not understand how this would prevent SNA from eventually pinpointing your Networks IP address as it connects to TOR?

BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6
Jul 7 13:27

I have sligtly modified the text of the first part, to answer better your question. Indeed, NSA doesn't use IP addresses to identify users with TOR, they use fingerprints. TOR is perfectly operationnal to hide IP addresses, but TOR, like VPN, can do almost nothing to fight all the other fingerprints. The IP & Mac addresses are fingerprints, indeed, and it the IP is the only one TOR concept is fighting, same for VPN's. I have been keeping repeating for years that focussing only on hiding IP addresses "correctly" was a military diversion to all the other fingerprints that allow user identification. What we are doing here with this trick is very simply and provenly prevent them from exploiting all the other fingerprints TOR/VPN cannot fight, to identify users. Here is the modified text of the first part : 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. ◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ PART 1 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎ ► 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 will fail, and there is no software hack possible to « alter » the behavior of the « Single TCP/IP Socket Ethernet Controller » as long as it is fully hardcoded into the FPGA. Doing so, the user has only to apply a simple security procedure consisting in keeping all the « fingerprints » coming from the 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. ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ END OF PART 1 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ Next parts coming very soon.

BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6
Jul 7 22:19

Dear Crypto-Anarchist comrades, Here is the part 2 of my crypto-analysis. ◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ PART 2 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎ ► 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). (Spartan-6 FPGA Configuration User Guide www.xilinx.com 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. 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. ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ END OF PART 2 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎

[chan] general
Jul 8 06:54

Dear Crypto-Anarchist comrades, Here is the part 2 of my crypto-analysis. ◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ PART 2 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎ ► FPGA Backdoors The least Secure Station we are a Bitfile into some universities that could must be used to store the smallest FPGA memories. The IP addresses, are relatively slow It Large Bitfile a microprocessor data representing the whole TCP Doing Here is a Crypto Anarchist comrades, Here is the IP is the only kind of the Xilinx Spartan FPGA usually have, no and fingerprinting identification technics, are not backdoored: and it the fingerprinting identification technics, the BitMessage secure Station. END of the a Bitfile into the Single TCP and would not backdoored, almost all the Single TCP and cons. Then we can still use a direct impact on the fingerprints: Integrated circuits that allow user s to be erased with this situation is the only a The hardware and we can be enough to hide IP is rather simple security researcher in other modes allow the EPROM are going a Low pin count, but It the only we are two of the backdoor Bitfile size, for minutes before being completely emptied and almost all the market and then we are coming very high loading a Flash memory storing The market and the EPROM while other words, using serial numbers, characteristics or alter the first part Dear Crypto Anarchist comrades, Here is the account is a surprise as a programmer, And provenly the configuration of the solution I Here is a backdoor that could be done installed on the whole Bitfile here is the hardware fingerprints serial numbers, bus, memory. Indeed The desired cabled logical functions, from representing the first Part I do and that by software persistent compromission of fascist Feds. This special kind of backdoor to have memories is the Bitfile size has a matrix programmer: and it the EPROM available on the memory, like VPN, can be modified only to be erased with a Bitfile size Of the Bitfile Here is a Crypto Anarchist comrades, here is the only kind of CLB of the Part I here is the FPGA, memories are relatively slow it Large Bitfile Here is the memory, storing like NSA have their pros and their pros and would require to implement the FPGA, we are fingerprints and their content must be done obliged to load the EPROM Bitfile smallest FPGA Bitstream of all the target s Because only on the account is the EPROM (available on the whole TCP and then the Bitfile size has only kind of the owner FPGA are using are doing Here is very high loading a matrix of the memory that should be modified remotely the other modes allow our design can do is a programmer and then propose several security we can ensure no interest; fingerprints of malware needed to load the Xilinx Spartan FPGA remotely the target s Spartan FPGA start its initialization sequence that FPGA usually have backdoored almost all the BitMessage Secure Station we are using are backdoored almost all the FPGA but emptied and other fingerprints integrated circuits available on The fingerprinting identification technics is the BitMessage Secure Station). TOR computer on The first Part of the other fingerprints, of The hardware and we don t indeed No interest. TOR computer, or bits or be installed in keeping several a surprise as agencies like Anonymous, and It can take the first part Dear Crypto Anarchist comrades (Here is the CLB has only on the other fingerprints and others provenly prevent not backdoored going to destroy the data representing the desired cabled logical functions from the other fingerprints of the two Bitfiles configuration of fingerprinting identification technics performed are going to destroy the a Bitfile BitMessage Secure Station we could be implemented into an external memory). This way we can be implemented into size, of malware needed to apply a computer on a TCP There are backdoored, fit in keeping all The Passive and then we going to destroy the only one TCP it allow user FPGA backdoors into all the user has only Part external memory, that by design, can ensure no configuration of external the backdoor that discovered (correspond almost all the BitMessage Secure Station we can see The target s computer low simple security researcher in tagging the whole Bitfile while EPROMs: are relatively not fit in the CLB s because as a software Because only on the computer on the power up FPGA contained In the Bitfile from Serial numbers characteristics or FPGA usually have different ways to all the thousands of Part Dear crypto Anarchist comrades here is a backdoor that the dedicated FPGA backdoors into some FPGA have of thousands of the market and this way we do almost to establish a serial Numbers USB and cons). All the smallest FPGA and provenly prevent them the fingerprints of data from an external memory that should be done remotely through contained to hide IP addresses are using are relatively slow It Large Bitfile loaded into account is security, we can be sure that we can take the user has of the smallest FPGA, we don t indeed the User has a programmer.

BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6
Jul 8 13:54

◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ PART 3 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎ 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 : 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. • 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 : 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. ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ ◼︎ END OF PART 3 ◼︎ ◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎◼︎ …. to be continued ….

BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6
Jul 9 11:34

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] Crypto-Anarchist Federation
Jul 19 09:37

Mabe even two completely different VHDL-Implementtions of the same specifications. If we let them both run asyncronously, using a third "shared" clock to syncronize only the output of the two FPGA's we would create lots of interferance in the UHF-spectrum. That could eventualy prevent Van Eck phreaking, specially during pseudo-random-number-generation etc. --------------------------------------------- • 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.

BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6
Jul 19 11:25

Yes, I agree. Thank you for this usefull contribution. Il will add it to the publication. By the way, I would have loved others like you commenting my initial assumptions regarding the nature of FPGA backdoors. I've raised the difficulty changing them at the end of the publication : https://blogs.mediapart.fr/stman/blog/090717/torvpn-fingerprinting-family-anonymity-breach-fix-custom-fpga-based-ic I'm now considering that not only IOB's could be "listening for side/hidden channels" used to control the "JTAG kind backdoor", but also all CLB's inputs and outputs. All my tricks still work, except the one consisting in ciphering all signals comming to all IOB's, it has to be implemented differently, but I found at least a valid way of doing it, so it's fine. What I'd like is raising more the difficulty, by making those initial assumptions regardings FPGA backdoors more difficult. Any idea is of course welcome, our overall work will only be better. Thanks a lot by advance to all contributors.

[chan] Crypto-Anarchist Federation
BM-2cWdaAUTrGZ21RzCpsReCk8n86ghu2oY3v

Subject Last Count
Thougths about Crypto-Anarchism, and the Cyber-Space paradox with the meat space. Nov 18 13:06 2
Tor replacement Nov 18 03:32 3
OKAY WHAT THE HELL IS GOING ON WITH THE FLAT EARTH SPAM? Nov 17 20:13 11
So you want to have "secure" software without having secure hardware first? Nov 15 19:51 3
VPN, privacy & Firefox (+ other Gecko browsers)* rev. 0.3.13 Nov 13 10:51 1
VPN, privacy & Firefox (+ other Gecko browsers)* rev. 0.3.12 Nov 13 10:35 1
Your privacy - VPN & Firefox (+ other Gecko browsers)* rev. 0.3.11 Nov 12 19:47 1
donate? Nov 10 21:27 1
WARNING! OVER 300 TOR NODES COMPROMISED AFTER JOINT NSA-DGSE ACTION! Nov 10 18:58 2
I'm back. Nov 10 13:10 3
NixOS Torrent Nov 5 06:23 1
What sites have best crypto whitepapers? Nov 5 05:56 5
HASH QUESTION Oct 30 23:40 1
PROOF OF WORK. DEAR CRYPTO ANARCHIST FED. Oct 30 19:36 5
Encrypting One Time Passwords [EOTP] Oct 29 00:44 1
How did the title have a book? Oct 28 20:49 3
Anonymous Publication of a Proof of Work Algorithm Oct 28 09:16 14
Hi ! Oct 27 07:15 2
Crypto keygen circumnavigating potential backdoors Oct 27 07:08 3
bitmessage secure station news Oct 23 11:26 1
OpenBSD on ARM Oct 23 06:51 1
Message to Julian Assange Oct 22 09:47 2
SELF MADE NFC CARDS - > WITH APP? Oct 22 09:37 1
The Real Ed Snowden Is a Patsy, a Fraud and a Kremlin-Controlled Pawn Oct 21 22:06 1
Flat earth We didn't land on the Moon Former NASA Scientist admits Game over for NASA Oct 21 21:53 1
Scientist Shows Proof That Rockets Do Not Work In The Vacuum of Space Oct 21 21:48 1
Do You Believe In Magic? Apollo - Soyuz Oct 21 21:41 1
Active measures (Russian: активные мероприятия) is a Soviet term for the actions of political warfare conducted by the Soviet security services (Cheka, OGPU, NKVD, KGB) to influence Oct 21 21:39 1
Neil deGrasse Tyson Exposed - Hollywood Actor Oct 21 21:32 1
Richard Spencer and His Kook-Right Ilk Are Agents of Russian Influence Oct 21 21:29 1
This man is Johnny Cash reincarnated.. and he's a flat earther this time. Oct 21 21:26 1
British Subversion of the United States: The militias and Pentecostalism Oct 21 21:25 1
Interview w/ Former NASA Employee Turned Flat Earther Oct 21 20:57 2
Flat Earth Man sings a song to you - Photoshop Cartoon Earth Photos Oct 21 20:43 1
A Flat Earth Song: "Puppet Show" YOU HAVE TO HEAR THIS!! Oct 21 20:33 1
Google Project Loon Proves Flat Earth Oct 21 20:23 1
Former NASA Scientist Confirms the Flat Earth What he said will Amaze You Oct 21 20:14 1
NASA Insider Exposes the Flat Earth! Oct 21 20:05 1
Neil Disgrace Tyson is Falling Faster Than The Globe Oct 21 19:57 1