Originally posted by DrYak
View Post
Announcement
Collapse
No announcement yet.
Developer Warns Of "Uncorrectable Freedom & Security Issues" For x86
Collapse
X
-
-
Originally posted by DrYak View Post
Saddly: yes, it can. It's based on spying any signal that can be intercepted coming out of the targetted box. That includes sounds (like the noise produced by capacitors on the mother board). And there are recent presentation at chaos computing conference and the like that shows research being able to exfiltrate encryption key by recording sound... with a simple smartphone.
(And thats when the target box is uncooperative. Of course, the target box could be intentionally emitting noises though the sound card that are beyond the human hearing range, but could carry data over an ear gag, like some kind of ultra-sound analog modem).
(Now suddenly all these "audiophile 192kHz" sound chips start to make sense)
The same "jamming" effect as that can be used against sound monitoring in the human hearing range, such as trying to work out typing by sounds of different keys. Music or better yet white noise is a common defense against audio surveillance. I've done lots of audio editing so I know how hard recovering weak sound over a lot of noise can be. Against ultrasound music would be useless, but again, trying to run a secure system in an insecure space is a losing game. Security starts with retaining custody and control of the entire space the machine is in, limiting any attacker to a single overwhelming attack to capture the machine without having had any prior access. Access over time=ROOT.
This sort of thing is why I carry a flash drive with a live system on it in case I have to fire up the netbook in "iffy" spaces. Then I can post reports or copy one cameraq card to another without endangering encrypted files on the hard drive or passphrases to web sites I do not log into. Simplest attack in a hostile space is a "security" camera aimed at the keyboard, though I actually tested that against dummy encryption passphrases and found the camera needed to be almost directly over the keyboard to avoid being blocked by my back, the screen, or one arm. I tested various positions of a good camera on a tripod, then examined the video.
Comment
-
Originally posted by DrYak View Post
Saddly: yes, it can. It's based on spying any signal that can be intercepted coming out of the targetted box. That includes sounds (like the noise produced by capacitors on the mother board). And there are recent presentation at chaos computing conference and the like that shows research being able to exfiltrate encryption key by recording sound... with a simple smartphone.
(And thats when the target box is uncooperative. Of course, the target box could be intentionally emitting noises though the sound card that are beyond the human hearing range, but could carry data over an ear gag, like some kind of ultra-sound analog modem).
(Now suddenly all these "audiophile 192kHz" sound chips start to make sense)
I actually tested using cameras as keyloggers against a dummy encryption passphrase but found it had to be almost directly overhead to avoid having over half the keyboard blocked by my back, the screen, or my hands and arms. Still, if you get in the habit of routinely sitting in the same place in a location your enemies have access to this kind of attack should be presumed to occur.
The RF attack is known as a "tempest" attack, and the monitor/monitor cable is usually the worst offender, a good reason for not echoing passphrases to the screen along with the camera issue. I do keep my desktop cases fully closed with no plastic windows and fine metal mesh at air vents plus cables with RF chokes to reduce the range of this attack and thus the radius I have to be able to control. The sound attack is interesting but has much less range than a Tempest attack.
Comment
-
Originally posted by drSeehas View PostSo you don't really have an alternative to a Kabini based laptop. Q.E.D.
So from any practical point of view, Kabini laptops are equally fucked up, when it comes to freedom, privacy and security issues. Tell us honestly, you do not give a fuck about concerns raised by this guy? You're probably booting some win10 on top of proprietary BIOS/UEFI shit and thinking it is the only way to go. OTOH I'm boting all-open software stacks on open boards. And I like how it performs. It is really nice idea to get rid of uncorrectable/treacherous/backdoored bullshit, or at least keep it down to a harmless minimum. It is not about Kabini laptops. Prove me wrong and show us solution for bullshit-free boot sequence, lack of proprietary code in critical key locations (like EC) and so on.
If we are up for something sensible, Chromebooks have long record of more or less reasonable security model.
- Key firmware parts are protected by being readonly. No malicious software can re-program readonly part by software means.
- This readonly part checks for signature of next parts. Since it can't be overwriten by purely software means, malicious software can't harm it. OTOH determined user can reprogram it, getting own firmware instead. Hardware-enforced write protection of ROM IC is what keeps it intact instead of vendor's fused keys one can't replace at all, no matter what.
- User can opt-out of sigs checking by readonly part, by means of configuration. It takes explicit indication of this wish though.
- Everything is opensource. Boot sequence parts, EC firmware and so on. It is possible to check if there is somthing nasty, ec.
That's how one gets it right (or at least getting close to it). But it not the only way to go for sure. Just example of better implementations. Speaking for myself I've got some systems I consider "all open", ranging from CAD files to utter lack of any blobs in boot sequence alltogether.Last edited by SystemCrasher; 09 April 2016, 09:24 PM.
Comment
-
On further thought, I wonder how much additional threat this brings to boards that do not support Coreboot much less Libreboot anyway? None of mine ever did. The main new threat I see with the Intel version (possbly AMD too?) is forced updates, which on desktops could be blocked by using an older machine as a firewall to block the source of the updates. Perhaps the lack of forced updates was why the NSA had to physically intercept all those computers ordered by the Chinese military for custom firmware installation?
OK, these new blobs or malicious versions of them can potentially read disk keys encryption keys from RAM, doing the same job as a keylogger in the BIOS or UEFI. New approach, old threat. Same counters apply: get the CPU and board randomly with cash, block the source IP address of pushed "updates," get any actually needed updates from a random IP address not traceable to you, preferably downloading while using a different machine. For boards lacking Libreboot support, that's almost all you can do.
One special point about Libreboot: it's the only way something like truecrypt or decrypting the disk in GRUB, with the firmware handling the keyboard could ever be safe. I would never try that on a non-Libreboot board as it removes over half the difficulty of writing malicious, encrypted disk passphrase logging firmware. Due not not having to keep the firmware running alongside the kernel, there could be a lot of malicious boards out there that can only capture Bitlocker and Truecrypt passphrases, and more yet that only hook into Windows to install other malware like so many Lenovo laptops did.
We do know the (NSA connected) Equation Group's malicious firmware targettting disk drives made itself almost impossible to remove, then turned around and hooked into windows for the payload, meaning the known versions could be useless against Linux, BSD, etc Equation Group may be a good indicator of how the NSA is thinking.
For now I will rely on my stockpile and keep these new control processors out of my computers, but in the future we will know more about them, have more counters and cracks, and at some point it may be those boards people stockpile against a yet newer threat like boards with a preinstalled and cryptographically signed operating sytem containing backdoors.
As far as being able to bypass this outright, one thought did come to mind-where is the offending processor, and is it linked internally or through the board to the reset pin. Also, can the reset pin short out the signal from it by being forced high or low? If the control chip in on the board in the chipset, cutting the trace from it to the reset pin in the socket (or leaving it out when the board is made for an OEM Libreboot setup) would be the counter. If the reset pin can simply float if it is OK to disable warm reset, the pin could be cut off an AMD CPU or Intel board. In the AMD case the pin could just be enamelled like enamelled wire to insulate it. If the pin has to be high or low for operation, for Intel a fine wire soldered to the pad and insulated where it passes other pins could be used, for AMD the socket hole drilled out and the wire brought out past the other pins and in either case then jumpered to ground or via a resistor to B+. Only if the control chip is on the CPU die with a fully internal link to reset without regard for reset pin state, or if the CPU actively queries the control chip is this impossible.
Comment
-
We do know the (NSA connected) Equation Group's malicious firmware targettting disk drives made itself almost impossible to removeLast edited by SystemCrasher; 10 April 2016, 08:17 PM.
Comment
-
Originally posted by Luke View PostThe RF attack is known as a "tempest" attack, and the monitor/monitor cable is usually the worst offender, a good reason for not echoing passphrases to the screen along with the camera issue. {...} The sound attack is interesting but has much less range than a Tempest attack.
Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
Acoustic Cryptanalysis
Original paper (linked and cited in a fore mentioned posts) mentions it works even with a simple smartphone when placed next to the target.
A smartphone simply lying on a desk is as inconscpicuous as it gets (unless you have the luck to have your own private office with your own desk table. Then you're going to wonder who's the idiot who left his phone one your place)
Comment
-
Originally posted by DrYak View Post
refs:
Breaking 4096-bit RSA with an Acoustic Cryptanalysis attack
Acoustic Cryptanalysis
Original paper (linked and cited in a fore mentioned posts) mentions it works even with a simple smartphone when placed next to the target.
A smartphone simply lying on a desk is as inconscpicuous as it gets (unless you have the luck to have your own private office with your own desk table. Then you're going to wonder who's the idiot who left his phone one your place)
Also, I see that this attack depended on decryption of a known plaintext, rather than unlocking an encrypted disk or opening a PGP encrypted email (assymetrical key opens symmetrical message key) email. The message key for a single PGP/GPG email is not a known plaintext, though the public key could be used to replace it with one. This would be an attack on encrypted email, not my hard drive. It would require predicting in advance who would sit next to me at a meeting, attacking their phone, and hoping we don't collect all the phones first-and that I actually open that email at the meeting. Counter is as simple as never using PGP or GPG in the presence of anyone else's phone, I don't own a smartphone due to CALEA so that line of attack is closed.
Comment
Comment