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
UPDATED : Rewarded help needed for scanning old amazon (Or any other website) shipment barcodes (Reward 10€ in Bitcoin per scan). Sep 24 14:41 1
Just like Christmas - Old Windows source code + KAV8 source code Sep 24 13:46 1
NATO member Turkey boast that Russian S-400 SAMs can take out American B-52s, F-22s and Tomahawks Sep 24 08:07 2
PHONE HARDWARE PRIVACY Sep 23 19:34 15
twister micro blogging Sep 23 04:16 21
BitText LIST Sep 21 12:33 1
bit text Sep 21 12:31 1
tor bridges Sep 21 09:42 2
gram: CHANBOT Response Sep 20 21:25 6
Feature Mashup Sep 20 20:01 9
oops: CHANBOT Response Sep 20 19:19 3
#cypherpunk EFnet Sep 20 08:21 5
THIS ADDRESS IS NOW NUKED Sep 20 04:39 1
Rewarded help needed for scanning old amazon (Or any other website) shipment barcodes (Reward $10 in Bitcoin per scan). Sep 19 22:19 1
wikileaks Russia spy files Sep 19 21:17 1
TheAntiMedia.org -- new low censor website Sep 19 15:31 3
[chan] TheAntiMedia.org Sep 19 15:28 1
Your privacy - VPN & Firefox (+ other Gecko browsers)* rev. 0.3.7 Sep 19 13:40 4
Wifi related dangerous fascist things you should all know. Sep 19 00:47 7
BitMessage Secure Station's architecture security review : White Papers & Publications about Designing Secure Hardware and fighting Hardware Backdoors. Sep 19 00:47 4
list Sep 19 00:46 2
Great article about fighting Hardware Backdoors and how to design secure open-hardware open-core systems (BitMessage Secure Station) Sep 17 11:57 1
Spy-o-cratie Sep 16 23:48 1
Bottle at the sea request about Raspberry Pi potential undocumented RF side channel. Sep 16 23:45 1
Native Oberon Sep 16 18:23 2
Papers Sep 15 13:43 8
SHARK - Secure Hash Algorithm Regenerative Keys Sep 15 06:01 3
A History of U.S. Communications Security (David G. Boak, NSA, 1973) Sep 15 05:59 2
BitMessage Secure Station open-core open-hardware "developer" version news : Git repository creation. Sep 14 17:08 17
I wouldn't recommend researching who is behind gangstalking Sep 14 08:20 2
BitMessage Secure Station open-core open-hardware "developer" version news. Sep 14 00:00 1
BitMessage Secure Station "version developer" security update Sep 13 20:53 1
A self-study course in block-cipher cryptanalysis Sep 13 13:14 2
ISS Space Station - Augmented Virtual Reality Sep 13 12:56 2
Bullshit: From Cold Fusion to Quantum Computers Sep 13 11:15 1
BitMessage Secure Station (Developer Version) open-core open-hardware project PCB routing advancement : 75% Sep 13 10:51 1
Anticipating the future : A Quantum Resistant Ledger white paper. Sep 13 07:40 1
First pics of the PCB of BitMessage Secure Station version "developper" with PIC 24 Microcontroller (And also Microstick2 compatible - Double implantation). Sep 11 13:10 1
BitMessage Secure Station news. Sep 11 11:51 16
Project Oberon - Publications by Niklaus Wirth Sep 11 07:08 1
OTP is not secure Sep 10 09:49 24
Tor relays Sep 9 08:34 4
- FINDING THE ALGORITHM. Sep 9 07:31 1
3301: SWTOENGSSGNEOTWS Sep 9 05:58 6
CAN SOMEON REVERSEENGINEER? Sep 9 05:16 5
STEGANOGRAPHY PUZZLE, NEEDS TO BE SOLVED PLS!!!!!!! Sep 9 04:13 5
BMIXR DIAGRAM: BITMESSAGE MIX ROUTING Sep 7 14:51 12
Leaked document: EU Presidency calls for massive internet filtering Sep 7 11:54 1
Wow. $3500 secure cell phone platform. Sep 7 11:33 1
World's Most Secure OS now FOSS Sep 5 09:21 5
Is One-time Pad History? Sep 5 09:20 3
NSA is not what you are told Sep 4 19:40 1
NSA is able to decrypt SSL, 4G, VPN and SSH connections. Sep 4 12:08 1
NSA has infected 50,000 computers worldwide [state on 2013]. Sep 4 12:04 1
Flat earth We did'nt land on the Moon Former NASA Scientist admits Game over for NASA Sep 4 08:22 3
NASA comes clean declaring 'We Lied About Everything'. A MUST SEE'er Sep 4 06:16 1
Your privacy - VPN & FireFox (+ other Gecko browsers)* rev. 0.3.5 Sep 3 16:14 1
SHA-512 versus SHA3-512 Sep 3 02:23 41
BLACK HELICOPTERS PATROULING AROUND MAJOR CITIES Sep 1 21:40 8
MINDMAPPING - WITHOUT CLOUD Sep 1 10:00 27
bruh Aug 31 16:52 2
MINDMAPPING Aug 30 21:40 1
ANYONE FAMILIAR WITH HIDDEN SERVICES? Aug 29 19:41 1
Putin's Reign of Terror, Part Two Aug 29 05:26 2
Question: Generating One-Time-Pads Aug 28 20:23 1
FAKE NEWS? Aug 27 22:21 1