Hardware trojans...

Feb 25 17:37 [raw]

https://www.popsci.com/most-sophisticated-malware-ever-can-infect-hard-drive-firmware -> Use LUKS (With a Yubikey or equivalent) to cipher the hard disk and fuck those backdoors. https://www.eff.org/deeplinks/2015/03/hardwired-for-betrayal http://www.zdnet.com/article/android-trojan-infiltrates-mobile-firmware-trend-micro-apps/ https://www.welivesecurity.com/2017/10/19/malware-firmware-exploit-sense-security/ http://blog.virustotal.com/2016/01/putting-spotlight-on-firmware-malware_27.html https://www.computerworld.com/article/2955641/cybercrime-hacking/macs-can-be-remotely-infected-with-firmware-malware-that-remains-after-reformatting.html https://www.wired.com/2014/10/code-published-for-unfixable-usb-attack/

Feb 25 17:43 [raw]

> https://www.popsci.com/most-sophisticated-malware-ever-can-infect-hard-drive-firmware -> Use LUKS (With a Yubikey or equivalent) to cipher the hard disk and fuck those backdoors. You are wrong. You don't understand how these trojans work.

Feb 25 18:19 [raw]

I understand more than you think. Strong software Whole Disk Encryption is eliminating 99% of those backdoors usage. Adding an hardware AES256 SATA encryption modules, also randomizing SCSI blocks numbers to avoid any kind of port knocking style side channel and time based side channels to activate and remotely use such backdoors leads to a 100% protection against the usage of such backdoors by those who implanted them into the hard drive embedded software, mainly being the NSA nazi motherfuckers. If you can't get rid of a backdoor, making it unusable is another good strategy. Stman.

Feb 25 18:35 [raw]

the manufacturers and vendors are putting these vulnerabilities in on purpose.

Feb 25 18:43 [raw]

And you call yourself a "Crypto-Anarchist"? Dude, let me explain you how deeply wrong you are. If backdoor is placed in HDD hardware, he can boot before system and virtualize/intercept any memory or hardware activity. It can also catch all cryptographic keys just after they are initialized. He can send them through network using any of thousands network steganography methods or it can store them - for later use by other malicious code - in any available space in any selcted firmware or in HDD areas directly. So any "protection" on software level is useless, because hardware trojan is already loaded and active, before any of your laughable "protection" even starts. So shut up and learn, before you start giving poor or plainly toxic advice to people.

Feb 25 18:53 [raw]

Why We Have a Police State The police state exists because you hate God, have rejected his easy law, so God has taken the leash off the devil to let his children rule over you. https://www.youtube.com/watch?v=joQYc-UOtrQ This is a poem which I wrote which sums up the state in which we find ourselves because of our rejection of God and His law. For more information, check out: http://www.MinneapolisChurch.net We Have Rejected God - A Poem By: Pastor Chad Wagner We have rejected God's omnipotence; now we have a powerful Police State. We have rejected God as our king; now we have an emperor. We have rejected God's dominion and kingdom; now we have an empire. We have rejected God's omnipresence; now we have a surveillance state with cameras everywhere. We have rejected God's omniscience; now we have the NSA and government databases which know everything about us. We have rejected the Great Physician; now we have Obama Care. We have rejected God's provision; now we have a Welfare State. We have rejected Jesus Christ, the bread of heaven; now we have Monsanto and GMO food. We have rejected God's protection; now we have the Military Industrial Complex. We have rejected God's word and wisdom; now we have government education. We have rejected God's law; now we have more laws than we can count. We have rejected God's good news (the gospel); now we have CNN and Fox News. We have rejected Jesus who is the way, the truth, and the LIFE; now we murder the unborn. We have rejected God's truth; now we have Mainstream Media propaganda. We have rejected God's religion; now we worship the State and the religion of secular humanism. We have rejected God's institution of marriage; now we have a Sodom and Gomorrah society. We have rejected God's light which exposes darkness; now we have secret societies, secret FISA courts, and secret wars. We have rejected the unsearchable riches of Christ; now we have a 17 trillion dollar national debt, banks too big to fail, and bankers too big to jail. We have rejected God's golden rule; now we have global rule. We have rejected God's Book which tells us what we are; now we have Facebook which tells the government what we are. We have rejected God's institution of the family; now we have a Big Brother. We have rejected Christ who makes us free; now we have the TSA which restricts our travel and gropes our genitals. We have rejected the liberty which Christ gives; now we have indefinite detention under the NDAA. We have rejected God's requirement to give a portion of our income back to Him; now we have a government that takes more than God ever asked for. We have rejected God's eyes which run to and fro throughout the whole earth beholding the evil and the good; now we have drones going to and fro throughout the skies bombing the evil and the good. We have rejected the Prince of Peace; now we have perpetual war. We have rejected the house of God; now we have a house of cards. Wouldn't you say it's about time we stop rejecting God and start seeking Him again? Isa 55:6 Seek ye the LORD while he may be found, call ye upon him while he is near: Isa 55:7 Let the wicked forsake his way, and the unrighteous man his thoughts: and let him return unto the LORD, and he will have mercy upon him; and to our God, for he will abundantly pardon.

Feb 25 22:43 [raw]

Hard drive firmware malware is an interesting animal. The extents to how much life can suck when your hard disk is working actively against you are higher than you think. Agree, LUKS and Yubikey will reduce your conventional attack surfaces, but won't completely eliminate your risks. You see, it's not just that your attacker controls everything you read or write to the hard disk (this includes your boot process) and can always get their code on the CPU before yours. It also controls all the hard disk moving parts, which means the attacker may turn your hard disk into an data transmitting device (via acoustic modulation), possibly even an incendiary device (via coil overheating). So your attacker can see all your RAM (including your LUKS key) and can exfiltrate it via window pane vibrations before setting fire to your house at 4AM. And there are probably many other malicious uses, but I'll stop here because my computer is running unusually hot today.

Feb 26 01:39 [raw]

We are tired of your retarded crap.

Feb 26 02:25 [raw]

I'm sorry, what part of that crap was retarded in what way? I find it quite developmentally appropriate, within cohort percentile :) Or did you mean it as an insult?

Feb 26 11:24 [raw]

All what you said is true. I won't deny it. I particuluarily like what you said regarding the booting process... nobody ever talks about this. Of course they can steal LUKS keys in RAM. I am aware of this, and I am a victim of this daily, due to the fact that I am attack the nazi mafia empire of Jeff Bezos at the European Commission, involving corruption rings in more than 8 states. So as you can imagine, I am a VIP target for these bastards and they put "all what they have at hand" on me technologicaly, to spy on me or to manipulate me. Still, you will agree that, in emergency, using LUKS + Yubikey, you rise your cyber-security level to an interesting level most military don't even have. Now, regarding the specific backdoors on hard drives, I maintain that if we would build a true Hardware SATA cyphering module, ciphering data of SCSI Blocks with AES256, with a 256 bit key, entered in a dedicated keyboard connected directly to the ciphering SATA module, and having this module done through a full processor-less design trough finite state machine within an FPGA, and using all the tricks I have described for the BitMEssage Secure Station to cancel the effect of most known FPGA backdoors for families like Xilinx Spartan 6, and having also this ciphering SATA module randomizing SCSI Blocks numbers (To block side channels based on SCSI blocks numbers), and also smartly FIFO buffering the SATA SCSI stream to filter time-based side channels, then, we can consider that those backdoors specificaly installed in those harddrives, that have been found and analyzed 2 years ago by Crypto-Anarchist researcher at #32C3 , then ... I think we are blocking them at 99,9999999% , maybe 100%. Still such device don't exist yet. The best I found for hardware SATA Whole Disk Encryption modules don't have such advanced functionnalities, and are not design with FPGA using a processor-less approach to garantee a null software attack surface on the SATA cyphering module itself. We have to do it ourselves. Let's do it. But that's why most of us are on this channel, indeed. But again, your crypto-analysis is right, and I agree with 100% of what you said. Kind regards, Stman.

Feb 26 11:37 [raw]

I forgot to say that we would have also to implement a true SCSI command "proxy" in this device, to block specific SCSI command-based side channels, and even introduce "noise" with dummy commands or voluntarily duplicated SCSI commands to ensure blocking "SCSI command based side channels". The fight against those hard drive backdoors is indeed mainly, in the end, to reach the 100% blockade of such backdoors, a fight on side channels. Side channels / hidden channels are our ennemy. Stman.

Feb 26 14:06 [raw]

> Still, you will agree that, in emergency, using LUKS + Yubikey, you rise your cyber-security level to an interesting level most military don't even have. Definitely agree - it would protect against all but the most exotic attacks. I've always been in favour of building a layered defense from imperfect solutions rather than do nothing while waiting for the ideal solution to be invented. :) > Now, regarding the specific backdoors on hard drives, I maintain that if we would build a true Hardware SATA cyphering module, ciphering data of SCSI Blocks with AES256, with a 256 bit key, entered in a dedicated keyboard connected directly to the ciphering SATA module, (...) > The best I found for hardware SATA Whole Disk Encryption modules don't have such advanced functionnalities, and are not design with FPGA using a processor-less approach to garantee a null software attack surface on the SATA cyphering module itself. This is a bit outside my expertise, but it sounds like a significant effort - to be able to support full SATA datarates while ensuring that no bits get lost ... is this even possible on an FPGA? Looks more like a job for a Linux SATA SOC like the Marvel Kirkwood (see http://www.cyrius.com/debian/kirkwood/ ), this shouldn't create a new attack surface if all kernel/modules are opensource? Any idea what the commercial solutions like the Addonics Cipherchain use under the hood - is it an FPGA, an ASIC or a full SOC?

Feb 26 17:28 [raw]

yupsillium it is impossible to insult someone with a good sense of humor ;)

Feb 26 18:30 [raw]

Hey guys, I don't understand a lot of what you are talking abut here but i'm eager to learn so i'm reading. About hardware trojans I have a question. I recently bought a samsung ssd and encrypted it by enabling TCG-OPAL via sedutil-cli (full disk encryption). What do you think about this encryption? Also I tend not to trust samsung, so would it be possible for a backdoor to exist in the ssd firmware in order extract the keys from the dedicated chip? Also there is a fork of the sedutil in order to support Yubikey but if a backdoor could exist wouldn't make the Yubikey along with the password obsolete? Thanks!

Feb 27 01:51 [raw]

> would it be possible for a backdoor to exist in the ssd firmware in order extract the keys from the dedicated chip? This is the key question. Would it be POSSIBLE? Definitely yes. The SSD firmware is a secret, un-auditable can of worms. There is no published source code, no deterministic build system, no simple way for the owner to install patches, disable vulnerable code sections or even verify that the firmware does at all what it says it does. Your data is a sitting duck locked inside a black box for which you don't have the key, provided purely on a "trust us" basis. Since you stated that: > Also I tend not to trust samsung .. then this should answer your question. You are using a security system powered by blind trust, and you're all out of blind trust. This is perfectly fine. You should still OPAL your SSD, just don't treat it as a single line of defense. It probably won't stop a determined attacker, but it may slow them down for an extra couple of hours. When it comes to the crunch and every minute matters, it may even save your life :) TL;DR using OPAL on your SSD will not make you any less safe than not using it.

Feb 27 02:49 [raw]

Wow, and I thought I was a bit paranoid, when all I wanted was to secretly chat about desires for Asian cuisine without angering my redneck friends. To these guys eating Asian food is like buying a Honda -- lynch worthy. How about some egg-foo-yum and pork fried rice recipes?

Feb 27 04:04 [raw]

> Your data is a sitting duck locked inside a black box for which you don't have the key, provided purely on a "trust us" basis. You don't really know what the box looks like, where exactly it is, what else or indeed **who else** is inside the box, but you've been told (non-contractually by some guys you don't particularly trust) that if you dial this long number, your duck will answer and will talk to you, and no one else. And she usually does, so everything will probably be all right, I guess. Welcome to black box encryption :)

Feb 27 11:00 [raw]

Indeed there are two main objective when thinking about implementing WDE (Whole Disk Encryption) on harddrives, and two complementary way of doing it, both addressing two very different security attack scenarios, and also some common ones : First, let's detail the security features addressed : * The common goals : Fighting those Hardware harddisk embedded software backdoors NSA & friends or competitors have placed within the harddisk software, allowing them to modify files and data, or stealing them, bypassing your computer OS security mecanism. Protecting your data against physical robery of your computer, or if the attacker has physical access to it, having them cyphered. * The first method, using your OS with LUKS or equivalent : This kind of WDE is not indeed not generaly a true WDE because your computer still need some basic bootstrap software to boot to enable the software WDE to ask you the deciphering key. This bootstrap software must be stored on the harddrive itself, and is therefore not ciphered, meaning that there are still a few sectors that will not be ciphered on the harddisk. This is a security risk, as long as this bootstrap software can be altered by an attacker, resulting in easy keyescrow. Such keyescrow malware can also be stored in other parts of your computer, like the BIOS / EFI code itself. The other security risk is that the deciphering key is then stored in RAM and again, skilled hackers / agencies can have developped malwares to intercept them. The conclusion on this first approach is that it is just slowing down an attacker in vast proportions, let's say 99%. It makes further use of harddisk embedded software backdoors much more difficult because it is greatly reducing the possibility and the probability that such harddisk embedded software backdoor activation and control side-channel / hidden channel are not usable anylonger. * The second method, using an external SATA encryption module, placed between the SATA socket of your motherboard and the SATA harddrive itself : It brings a true WDE, ciphering all blocks (sectors) of your harddisk, therefore protecting the few sectors that have not been ciphered with the other OS software based WDE described previously. Meaning that your data are definitely 100% protected against attacker that can have a physical access to your computer. The AES256 key being usually entered through a dedicated keyboard or hardware key connected to the module, it is not present into your computer RAM, and preventing hackers to get it, unless they can hack and root the module's embedded software itself from the SATA bus from the motherboard, or even the harddrive. But this is complex, and as you could see, we can design "perfect SATA WDE ciphering modules" that can be garanteed to have a null software attack surface. In the case we would have a perfect SATA WDE encryption module, it therefore prevents 100% the usage of the embedded harddisk software backdoors, not only because all side channel would be jammed, but also because there is no access possible to the ciphering key opf the data. Still, if a malware keyescrow is running in hypervisor mode on your computer, even with or without using OS based WDE like LUKS additionnaly, the attacker can still alter files / data without the OS knowledge. But when using this SATA encryption module, you still have the garantee that the attacker can no longer exploit the hardisk embedde software backdoors to do so, as long as all its control side channel are normaly jammed and unsusable, and because the AES key is not stored in the computer RAM. Conclusion : Using both ciphering methods in conjunction is better. You reach let's say a 99,99% protection against modification or robbery of your data, but not a 100% protection. To reach the 100%, you would have to ensure that your computer was designed as an hardened end-point, and that no keyescrow malware can be running in hypervisor mode, even if all the files of the OS stored on the harddrives are clean. And due to current computer motherboard architectures, it is unfortunately impossible to garantee this for the moment. Using an external perfect SATA encryption module (Having a null software attack surface) gives you at least the 100% warranty that the harddrives embedded software backdoors cannot be used. Using an external SATA encryption module (That could eventually be hacked), that are available on the shelf for 200 or 300$, is still a very good option giving you really a high level protection. And I was thinking while writting this conclusion that a true perfect SATA encryption module should have both a null software and a null hardware attack surface, because there are still two different scenarios an attacker having physical access to your computer : Either the computer is powered on and running, with the perfect SATA encryption module running, with the deciphering key loaded into it, or the computer is powered off, and the key is therefore not loaded into the SATA encryption module. These are two very distinct attack scenarios. But as you can see, and as the other contributor was saying, "harddisk embedded software backdoors" are very interesting animals... Gaining a full protection is very hard stuff, particularily when the attack has physical access to the computer, but also because of the impossibility to garantee that your computer's motherboard is not secretely running keyescrow things and corrupted SATA driver without your OS knowledge, due to the fact that current computer motherboard architecture are weak, leading to overall weak end-points as Snowden said ! But still, combining both methods described in this article already gives you a very high level of protection, and only the elite hackers from NSA & friends or competitors would really have a chance of getting in. Stman.

Feb 27 13:03 [raw]

Hey, Thanks for your input guys. Here is the first time I hear about SATA encryption modules. This seem to be a really good idea, but hard to implement in a laptop, as this modules that I found are not small enough, but we should be able to design and implement one with proper funding and support as the tech is here. For very sensitive data we could create a truecrypt/luks volume inside a harddrive, encrypted with an external SATA encryption module. Same would work well also with an OPAL encrypted SSD, as even if an attacker could exploit the "black box encryption", the sensitive data would not be available for them to see. As I understand truecrypt/luks is still secure (though the keys are present in the RAM). So yeah, as you say, using both ciphering methods in conjunction is as safe as we can be. We need multiple lines of defence. Also, another issue I see this days, is that computer power is becoming really cheap so bruteforce attacks via cloud computing is really accessible (Amazon EC2 is just an example) but with a yubikey or a very long and random password, we are still secure. Best regards

Feb 27 13:23 [raw]

Yes, there is a problem for laptop, these modules are currently too big to fit into most laptops. But we can work on this... About Jeff Nezos "Amazon Cloud" FPGA based, I have a really bad cybersecurity news for him : ► FPGA Hardware backdoors news : If there is one paper that is worth reading, it's this one, it's only 6 pages long. « An inside job : Remote Power Analysis Attacks on any FPGA » A mind blowing new powerfull DPA/SCA equivalent method to produce a new generation of backdoors into FPGA’s & ASICs. https://t.co/yA7yPFMUGs Personnal comment about this article : We must check it is working. The mecanism seems rather simple and straightforward, so I guess it's absolutely not fake but a real threat. The first workaround I see if having Free VHDL compilation and place & route tool chains, that would ensure such evil design in not secretely inserted into the design at compilation time. The second is to innovate to FPGA architecture at FPGA silicium level so that such design would not work even if inserted by a compromized VHDL compilation tool chain : I have a few great ideas to produce Free FPGA that would prohibit such thing to work. To be continued... And don't forget to deeply fuck your local spying agency nazi cyber-domination powers. Stman.

Feb 28 01:47 [raw]

> backdoors NSA & friends or competitors have placed within the harddisk software What about backdoors bitmessage & friends have placed within the software? Bitmessage was just found with one of these back doors. While you tout NSA and manufacturers possibly inserting back doors you use bitmessage which provably had a back door. While NSA compromising security is a "possibility" we confirm that bitmessage compromising security is an actual event. Is the enemy NSA or bitmessage?

Feb 28 01:55 [raw]

> Is the enemy NSA or bitmessage? They both were, at some point in time, but now it's one down, one to go. The correct answer is NSA.

Feb 28 10:11 [raw]

Fuck all the bastards that cyber-spy on others. Who ever they are.

Feb 28 15:28 [raw]

NSA here. Mr. Peter Surda is not on our payroll. He doesn't need to be, as Bitmessage source code is full of easily exploitable vulnerabilities, so we even don't need to engage TAO to successfully infiltrate all Bitmessage users. From our point of view Bitmessage gives enough penetration opportunities, to support our task in many years to come.

Mar 1 05:01 [raw]

this whole thing including you is just a dog and pony show

Mar 10 13:37 [raw]

The Xilinx Spartan 6 Family can handle signals up to 2 or 3 Gbps. Spartan 7 family even higher. So there is absolutely no problem handling SATA signals with those low cost FPGA. They are designed typically for that kind of things. The only issue regarding "hardcoding" the SCSI protocol commands to make this "ciphering proxy" is that you have to read, understand and fully respect the whole SATA SCSI standards, to be able to implement and hardcode the equivalent of such "software stack" in the form of finite states machines. It takes the double time than classical processor+software implementation, but in the end, you obtain a very stable system, the fastest implementation possible as it is hardcoded, but the main reward is that there is no software attack surface. You can still keep a little microcontroller beside the FPGA to handle a screen with a simple user interface, that can parameter the module hardcoded in the FPGA, as long as there is no security indidence on the module itself, it is just used to parameter it through a few output data lines. By the way, this is the approach I will have for the "final version" of the BitMessage Secure Station.

Mar 17 05:16 [raw]

Has anon sunk to stolen valor? Seriously, YGBSM.

[chan] Crypto-Anarchist Federation

Subject Last Count
1 Sep 19 13:20 2
111 Sep 18 22:09 1
eita Sep 14 20:36 1
ankw Sep 14 20:36 1
ltd Sep 14 20:36 1
ycy Sep 14 20:36 1
bzgk Sep 14 20:25 1
imy Sep 14 20:25 1
pmrc Sep 14 20:14 1
vgz Sep 14 20:11 1
npjyr Sep 14 20:08 1
puij Sep 14 20:05 1
yml Sep 14 20:03 1
vcw Sep 14 20:02 1
kbkz Sep 14 19:58 1
byfx Sep 14 19:58 1
vdqqy Sep 14 19:57 1
ngcj Sep 14 19:56 1
ficeu Sep 14 19:54 1
gduv Sep 14 19:46 1
yczg Sep 14 19:46 1
jiy Sep 14 19:45 1
xun Sep 14 19:44 1
zft Sep 14 19:44 1
eto Sep 14 19:44 1
mqtjx Sep 14 19:44 1
uow Sep 14 19:43 1
odo Sep 14 19:43 1
bjzd Sep 14 19:41 1
pczer Sep 14 19:23 1
dob Sep 14 19:23 1
dni Sep 14 19:23 1
xldp Sep 14 19:23 1
ukzj Sep 14 19:20 1
yhx Sep 14 19:15 1
egjo Sep 14 19:12 1
zxg Sep 14 19:07 1
gihxd Sep 14 19:07 1
rqow Sep 14 19:07 1
sgaj Sep 14 19:07 1
mvttv Sep 14 19:06 1
lakyj Sep 14 19:04 1
jxns Sep 14 19:03 1
sbxp Sep 14 19:00 1
sgqic Sep 14 18:59 1
cxr Sep 14 18:58 1
cur Sep 14 18:56 1
malxq Sep 14 18:56 1
hhjf Sep 14 18:56 1
gyei Sep 14 18:50 1
dhfiw Sep 14 18:48 1
qkz Sep 14 18:32 1
zqzc Sep 14 18:31 1
aanp Sep 14 18:29 1
llezn Sep 14 18:25 1
ybqir Sep 14 18:10 1
orl Sep 14 18:10 1
tfbhw Sep 14 18:00 1
wha Sep 14 17:48 1
ovv Sep 14 17:48 1
rch Sep 14 17:44 1
rdxp Sep 14 17:44 1
zom Sep 14 17:40 1
vmdk Sep 14 17:37 1
pxvwp Sep 14 17:34 1
kkrdt Sep 14 17:31 1
ukbw Sep 14 17:30 1
gzsh Sep 14 17:29 1
yilmg Sep 14 17:19 1
rtpqj Sep 14 17:17 1
egxt Sep 14 17:12 1
shymw Sep 14 17:12 1
lgn Sep 14 17:08 1
cga Sep 14 17:08 1
rmlc Sep 14 17:08 1
jom Sep 14 17:08 1
rcc Sep 14 17:08 1
qht Sep 14 17:06 1
ukqep Sep 14 16:47 1
puxwg Sep 14 16:47 1
shin Sep 14 16:47 1
uftg Sep 14 16:47 1
gfp Sep 14 16:46 1
xjz Sep 14 16:39 1
afnp Sep 14 16:38 1
jokre Sep 14 16:36 1
acsyd Sep 14 16:30 1
zkqnl Sep 14 16:29 1
qpx Sep 14 16:29 1
zwlf Sep 14 16:29 1
eiu Sep 14 16:25 1
rgvs Sep 14 16:19 1
qkcs Sep 14 16:19 1
ewoe Sep 14 16:13 1
aylru Sep 14 16:11 1
ljacu Sep 14 16:06 1
dmub Sep 14 16:06 1
vithq Sep 14 16:06 1
zfcv Sep 14 16:01 1
glwvv Sep 14 16:00 1