Announcement

Collapse
No announcement yet.

Developer Warns Of "Uncorrectable Freedom & Security Issues" For x86

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    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)
    Thankfully audio transmission range is quite short, and when you are near enough, you are probably also near enough to record the sound of my keyboard or capture the electromagnetic emissions of my screen or even just record what my own body (voice, body language, …) is doing. And those actions do not even require hacking my system.

    Comment


    • #42
      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)
      Those kind of attacks are only effective at close range, and I won't boot an encrypted machine if I have reason to believe I have adversaries close enough to do that. A network attack is global but can be defended against more easily. The RF attack is known as a "tempest" attack, I do use the best shielding I can both to reduce the range of that and because one of my machines uses a frequency internally that overlaps with wifi frequences and can jam the wifi dongle on the back of the machine. Solid RF shielding of that fan grill was not only a security requirement, but a network reliability requirement. When an antena is only an inch away the RF can be very intense, this is why cell phones can cause brain cancer but cell phone towers cannot.

      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


      • #43
        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)
        All of those close-range attacks imply an attemt to run a secure system in an area controlled by an adversary, never a good idea. That's why I carry a bootable live OS flash drive along with the laptop, for thing like copying a camera card to another in an iffy area without exposing the normal boot passphrase for the encrypted disk.

        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


        • #44
          Originally posted by drSeehas View Post
          So you don't really have an alternative to a Kabini based laptop. Q.E.D.
          What exactly you're trying to prove, lol? Do I look like yet another x86 manufacturer or something? Why the hell you expect me to come with some "alternatives" to some "Kabini based laptops" in context of mentioned article? I do not get your ways of thinking. Are these laptops somehow special, or what? Even if they do not have "security processor", they are going to have proprietary boot firmware, proprietary EC, and so on. Realistically, one can't expect coreboot/libreboot on these devices since they lack documentation yet being heavily customized system implementation. Reverse engineering systems like this is a really hard task, at the end of day there're more rewarding targets for reverse engineering.

          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; 04-09-2016, 09:24 PM.

          Comment


          • #45
            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


            • #46
              We do know the (NSA connected) Equation Group's malicious firmware targettting disk drives made itself almost impossible to remove
              Btw, http://spritesmods.com/?art=hddhack&page=1 - "how to hack HDD firmware using JTAG and opensource software". Uhm, yeah, this guy has patched HDD firmware and has been able to do Equation-like trick . Another fancy thing to admit is OpenSSD (just google it).
              Last edited by SystemCrasher; 04-10-2016, 08:17 PM.

              Comment


              • #47
                Originally posted by Luke View Post
                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. {...} The sound attack is interesting but has much less range than a Tempest attack.
                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)

                Comment


                • #48
                  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)
                  A parabolic mike at 4 meters will be noticed in any of the kind of places I would use a laptop, and no way in hell I am letting an unknown electronic device inside 1 meter of one of my encrypted systems while in use. This is not something a truck on the street can do through a wall. Real world: most dangerous side-channel attack is people using wireless keyboards with encryption.

                  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

                  Working...
                  X