back to article AES-256 keys sniffed in seconds using €200 of kit a few inches away

Side-channel attacks that monitor a computer's electromagnetic output to snaffle passwords are nothing new. They usually require direct access to the target system and a lot of expensive machinery – but no longer. Researchers at Fox‑IT have managed to wirelessly extract secret AES-256 encryption keys from a distance of one …

Page:

  1. Anonymous Coward
    Anonymous Coward

    I'm not even surprised.

    As long as energy is dissipated from the system under examination while the key is in use, which by the Second Law of Thermodynamics will happen in some form, you can discover that key. True, it may be extremely difficult but given our rate of technological advancement, you are merely delaying the inevitable. Offense v. defense, always cheaper for the offense, if anyone is keeping score. I do, obviously given engineering and economics background.

    It may hit us fast, singularity occurring, or the slow process of social change, but it will happen that all information is free or, perhaps, at a modest charge.

    1. Anonymous Coward
      Anonymous Coward

      Re: I'm not even surprised.

      You shouldn't be surprised. It's nothing new. Circa 2001 for FIPS level 2 and above cryptographic modules require measures to eliminate unintentional radio emissions that can be used to compromise the system. Don't even think about taking the shielding off the really high end crypto gear. The anti tamper mechanism will fry the workings in a rather spectacular way. At the national security level some contain thermite and others go for protective detonation.

      1. MacroRodent

        Re: I'm not even surprised.

        The anti tamper mechanism will fry the workings in a rather spectacular way. At the national security level some contain thermite and others go for protective detonation.

        Seriously? That sounds like the something out of Mission Impossible.

        1. allthecoolshortnamesweretaken

          Re: I'm not even surprised.

          "Seriously? That sounds like the something out of Mission Impossible."

          Yes, I was wondering about that, too.

          However, I must confess that I really like the term "protective detonation".

    2. Anonymous Coward
      Anonymous Coward

      Re: I'm not even surprised.

      The latest (next release?) AMD chips/memory controllers will allow real time memory encryption. This may help future devices. As you would need to also gain that key (or reverse engineer some method of "guessing" it). This would, I assume, mean each bit will have different power draws each boot as it will be given a different method of encoding each time.

      1. Anonymous Coward
        Anonymous Coward

        Re: I'm not even surprised.

        Why 4 thumbs down for the memory encryption at runtime off a "trusted" enclave on AMD chips?

        Is it because this type of attack could also get that trusted key?

        Is it because this type of attack is agnostic to encrypted memory?

        Or is it because people are downvoting me for no reason?

        1. Anonymous Coward
          Anonymous Coward

          Re: I'm not even surprised.

          Intel's marketing team work Sundays?

        2. Sanctimonious Prick
          Happy

          Re: I'm not even surprised.

          @TechnicalBen

          Fourth rule of posting: don't complain about downvotes!

          1. Anonymous Coward
            Anonymous Coward

            Re: I'm not even surprised.

            True. But I'm honestly asking... is this something encrypted memory and/or encryption cycling (by the time they get one key, you've generated a new one) could help prevent?

            If a bit is "high" one moment, then "low" the other, how do you know if it was a 1 or a 0, when it is cycling through encoding methods... though at the byte level this may still be sniffable.

            I suppose I could sit down and do the maths, but it makes my head hurt...

          2. Kiwi
            Pint

            Re: I'm not even surprised.

            Fourth rule of posting: don't complain about downvotes!

            I though that was the 1st rule - "Don't talk about downvotes".

            But the fifth rule clear is "don't tell people about the 4th rule".

      2. CheesyTheClown

        Re: I'm not even surprised.

        Real-time memory encryption in server is a generally bad idea for a multitude of reasons.

        1) It's a false sense of security. People will believe it offers some level of protection... it doesn't.

        2) The memory controller would have to be issued keys from within each each session. These keys are theoretically shielded from the host system. If the guest operating system implements this technology... kudos for them. It means that direct attacks from VM to VM are taken care of.

        3) Drivers loaded on the guest VM will have access to the encrypted memory as they run in kernel mode on the guest VM. This means virtual network, disk and graphics adapters will be able to access memory as unencrypted or issue memory requests to MMU to get access to whatever they want. So, a compromised driver can be an issue. If you read the source code for e1000, VirtIO Ethernet, VMXNET3 drivers in the Linux Kernel, you'll see that they aren't exactly hardened drivers for security. They're good device drivers, but VMXNET3 for example looks very pretty in code format, but that's because it's not particularly bogged down with silly things like bounds checking code.

        4) "Bridges" used for performing remote execution on guest VMs will generally have to be available since this is how automation systems work. So, Powershell Remoting (WMI/OMI), QEMU Monitor Protocol, KVM Network Bridge, PowerCLI, etc... all offer methods of performing RPC calls on guest VMs from the host and in many circumstances, directly at the kernel level.

        5) Hardware hairpinning is an option as well. PCIe (unlike PCI and older devices) operate entirely on memory mapped I/O (MMIO) which means that all communications with the system and with system memory are performed by using memory reads and writes. In bare metal hypervisors with proper hardware such as Cisco VIC, nVidia GPUs ,etc... the hardware is programmable, partitionable, and can execute code. An example would be to log into the Cisco VIC adapter via out of band management and run show commands for troubleshooting. The iSCSI troubleshooting commands in particular are quite powerful and would easily allow issuing memory reads and writes on the fly from a command line interface. In order to honor them, the MMU in the CPU would have to decrypt the requested memory. Of course, the MMU and OS driver could mark pages appropriately to allow access-lists on individual protected pages. But that's mute when we see point 6)

        6) RDMA provides a means of extending system memory from server to server. This works by mapping regions of physical memory in each server to be accessed by hardware from other systems over devices like RDMA over Ethernet NICs or Infiniband HCAs. High performance systems like HPC systems, high performance file servers (like Windows with SMB Direct) and high performance Hypervisors like KVM and Hyper-V (ESXi is very notably not part of this as it sacrifices high performance for high compatibility) perform live migration over RDMA where possible. While it is theoretically possible to move the guest machines in encrypted states, it would be necessary to carry enough information from one server to the other during a migration to provide a decryption key in the new host to access the VM memory as it is moved. That means the private key would have to either be transferred in clear text or would have to be renegotiated through an hypervisor hosted API... providing a new key in clear text to the hypervisor...if only briefly.

        The intent of encrypted memory was really really awesome, but extremely poorly thought out. It could have some benefits in places like containers where individual containers could be shielded from the host OS and they don't migrate. But there would still be critical issues with regards to where the decryption keys reside. Also, as containers generally ARE NOT bare metal, so the keys would have to reside on the container host instead.

        Thanks for bringing this topic up though. Make sure you tell everyone who intends to depend on encrypted memory that it's at least 10 years and several Windows, Linux, Docker and hardware generations off from being meaningful. But make sure to tell them they should bitch to their vendors to make them support it ASAP. It will require an entire ecosystem (security in layers) approach to make this happen.

    3. Oh Homer
      Headmaster

      Definitely not new

      See also: Tomorrow's World circa 1985.

      1. Anonymous Coward
        Anonymous Coward

        There are ways around this

        These types of attacks have been known for years, as has the defense. At the cost of some energy efficiency, the hardware can calculate results for both a '0' and '1' in each bit of the key, and throw away the result it doesn't need.

    4. Anonymous Coward
      Anonymous Coward

      "The entire cost of the setup was less than €200"

      With or without VAT?

    5. Destroy All Monsters Silver badge
      Holmes

      Re: I'm not even surprised.

      Well, you can always redesign the chip to obfuscate its energy usage,

      Here for example, from 2003 (paywallyed): Masking the energy behavior of DES encryption [smart cards]:

      Smart cards are vulnerable to both invasive and non-invasive attacks. Specifically, non-invasive attacks using power and timing measurements to extract the cryptographic key has drawn a lot of negative publicity for smart card usage. The power measurement techniques rely on the data-dependent energy behavior of the underlying system. Further, power analysis can be used to identify the specific portions of the program being executed to induce timing glitches that may in turn help to bypass key checking. Thus, it is important to mask the energy consumption when executing the encryption algorithms. In this work, we augment the instruction set architecture of a simple five-stage pipelined smart card processor with secure instructions to mask the energy differences due to key-related data-dependent computations in DES encryption. The secure versions operate on the normal and complementary versions of the operands simultaneously to mask the energy variations due to value dependent operations. However, this incurs the penalty of increased overall energy consumption in the data-path components. Consequently, we employ secure versions of instructions only for critical operations; that is we use secure instructions selectively, as directed by an optimizing compiler. Using a cycle-accurate energy simulator, we demonstrate the effectiveness of this enhancement. Our approach achieves the energy masking of critical operations consuming 83% less energy as compared to existing approaches employing dual rail circuits.

  2. I just wish to be anonymous.

    If it's engineered, it can be reversed.

    1. DryBones
      Trollface

      If it can be reversed, it can be Rockforded!

    2. Old Used Programmer

      Through a Lens, darkly...

      Thank you E. E. "Doc" Smith. Where are the Arisians when we need them?

      1. Peter Gathercole Silver badge

        Re: Through a Lens, darkly...

        Not even a Lens protects you forever.

        IIRC, there were 'dark' lenses appearing by the time of "Children of the Lens", so even the Lens was reverse engineered.

        The Arisians always knew from their 'Vision of the Cosmic All' that they were not the ultimate lifeform. That is why they force-evolved and then passed the mantle on to the Kinnision clan.

  3. John Smith 19 Gold badge
    Unhappy

    In effect "traffic analysis" applied at the bus level.

    This may be either quite easy or quite difficult to counter.

    Basically you need to keep a constant(ish) power level in the system. If that's possible then it will be more difficult to pick the signal out of the noise. Keep the data paths filled with dummy data so there are no (or quite shallow) spikes in the noise.

    It's intriguing that they were able to chop the search space into byte size segments and thereby exclude a lot of it.

    Clever but depressing, give AES256 seemed pretty strong.

    1. elDog

      Re: In effect "traffic analysis" applied at the bus level.

      Couldn't this power-fluctuation (or emanation) detection be easily masked by injecting random noise into the environment?

      1. Andrew Commons

        Re: In effect "traffic analysis" applied at the bus level.

        @elDog

        That's how you usually defeat traffic analysis.

    2. Voland's right hand Silver badge

      Re: In effect "traffic analysis" applied at the bus level.

      Basically you need to keep a constant(ish) power level in the system

      Not even that - your power level should not correlate with the encryption task. That will actually be the case if the system is doing enough other things. Makes up for an interesting argument against dedicated hardware.

      1. TRT Silver badge

        Re: In effect "traffic analysis" applied at the bus level.

        What kind of noise do you get from multicore / multiprocessor systems?

        1. Anonymous Coward
          Anonymous Coward

          Re: In effect "traffic analysis" applied at the bus level.

          Exactly. If you read the paper it looks like the target sits there idle and then performs rounds of encryption tasks that are monitored. I can only imagine an interrupt driven/multi-tasking system would make this 1000x more difficult (but clearly not impossible). No clean start and end to the encryption process to cleanly pull out of the air.

    3. Anonymous Coward
      Anonymous Coward

      Re: In effect "traffic analysis" applied at the bus level.

      This may be either quite easy or quite difficult to counter.

      Basically you need to keep a constant(ish) power level in the system. If that's possible then it will be more difficult to pick the signal out of the noise. Keep the data paths filled with dummy data so there are no (or quite shallow) spikes in the noise.

      Poisoning the well is a good approach, but I suspect the encryption signal will have some clear characteristics so it will not be enough to just add some random noise. You need to generate a number of dummy keys at the same time so that that noise shares the same characteristics with what you want to camouflage.

    4. Anonymous Coward
      Anonymous Coward

      Re: In effect "traffic analysis" applied at the bus level.

      @John Smith 19

      With crypto worth having stealing the key is often trivial when compared with breaking the cipher.

      1. John Smith 19 Gold badge
        Unhappy

        "With crypto worth having stealing the key is often trivial"

        AES is not a "public key " encryption system.

        If you have the key, an encrypted message with that key and an implementation of the cipher you apply the first two to the last and read the message.

        The advantage of a private key system is that to give equivalent protection the keys in a public key system have to be longer, hence (in principal) a private key is easier to remember.

        OTOH key management if you have to distribute them to lots of people is a PITA.

    5. Vic

      Re: In effect "traffic analysis" applied at the bus level.

      Clever but depressing, give AES256 seemed pretty strong.

      This isn't a breach of AES256, it's a breach of one implementation...

      Vic.

      1. Gotno iShit Wantno iShit

        Re: In effect "traffic analysis" applied at the bus level.

        That's what I see too but your downvoter clearly sees different. In this attack the attacker is in control of the target hardware and the code running on it. I'm struggling to see the connection between this and the scenario in the picture on page 2 of the linked PDF.

  4. Phil Endecott

    "AMD" is a typo, right? Should be "ARM" coretex m3 I think.

    If it actually is an AMD (i.e. x86) chip that they've managed to observe in this way I am very impressed.

    1. Mike 125

      ARM

      ARM, yes indeed, so embedded.

      Most of the focus on securing high end embedded devices in e.g. smart cards, is now about disguising crypto activity. Such an application avoids using CPU crypto instructions (of which ARM has many). It will just wait on a reply from the dedicated crypto block, which is designed to emit a constant/ pseudo random noise and current consumption signature.

  5. MD Rackham

    The headline lies about the actual content of the story. The 50 second time is for kit 30 cm away. The one metre time was 5 minutes.

    Changing the headline to "You won't believe how long it took to crack an AES-256 password!" would be more ethical clickbait.

    1. Aqua Marina

      Try not to read this in a Liam Neeson voice.

      I don't know who you are. I don't know what you want. What I do have are a very particular set of skills, skills I have acquired over a very long career. Skills that make me a nightmare for people like you. If you post a link to a clickbait article, I will look for you, I will find you, and you won't believe what happens next!

      1. Message From A Self-Destructing Turnip

        Re: Try not to read this in a Liam Neeson voice.

        Well, somebody's fin rot is making them grumpy!

    2. Kiwi
      Headmaster

      The headline lies about the actual content of the story. The 50 second time is for kit 30 cm away. The one metre time was 5 minutes.

      Well... 30cm would be around 12" I guess, which is "just a few" depending on your frame of reference (a 5 mile wide asteroid missing by 12" would be "just a few" or "mere inches" in any ones language, however cutting a 6ft beam short by 12" would be a "hell of a lot").

      And 5 minutes is comprised of 300 seconds. </pedant>

      1. MD Rackham

        The headline has been altered from when it first went up.

        It was originally "a metre away" which is 3x the 30 cm the article discusses. The current headline of "a few inches" is better. Still misleading, but not something I would have commented on.

    3. phuzz Silver badge

      Fifty seconds or three hundred, compared to a brute force attack they're both basically instant.

    4. Commswonk

      @ M D Rackham: ...ethical clickbait.

      My oxymoron alarm has just gone off.

  6. Herby

    Meanwhile...

    Amazon reports that a multitude of software defined radios have been ordered by someone near Ft. Meade VA, along with antennas with sensitive amplifiers.

    1. allthecoolshortnamesweretaken

      Re: Meanwhile...

      False flag, probably - my sources tell me that the guys you're thinking of are mostly using a P.O. box in Weehawken, NJ for that sort of thing.

  7. Anonymous Coward
    Pint

    How well was the PC prepared?

    Sure I'm skeptical. Thing is: I once build my PC myself and bought myself a solid tower housing. It's all solid metal, kept on using this for years. Faraday cage anyone?

    A few months back I had to dispose of an old (non-working) 4U Dell PowerEdge. The metal casing alone weighed around 20kg. Again: Faraday cage anyone?

    1. Old Used Programmer

      Re: How well was the PC prepared?

      I hate to tell you, but the leakage will go through smaller holes are the frequency goes up. All case have holes in them. At the very least, for cooling fans. An all metal case should has less EM leakage, but there will still be some.

      1. Charles 9

        Re: How well was the PC prepared?

        Even a TEMPEST-rated case?

        1. TrumpSlurp the Troll

          Re: How well was the PC prepared? TEMPEST?

          IIRC they stopped building TEMPEST PCs when the general reduction in power usage and radiation from standard PCs met the TEMPEST requirements unmodified.

          Perhaps it is time to revisit this, or perhaps the detection distance means that if you can get that close you have already breached physical security to an extent that eavesdropping is the least of your worries.

          A solution that could be used in tables at coffee houses, perhaps, to steal customers keys then snoop. However what is the cost/benefit?

          1. John Brown (no body) Silver badge
            Black Helicopters

            Re: How well was the PC prepared? TEMPEST?

            A solution that could be used in tables at coffee houses, perhaps, to steal customers keys then snoop. However what is the cost/benefit?"

            Just keep an eye out for the man in the trench coat with a white carnation buttonhole using his laptop then you go up and take his order, being careful to make sure the process takes at least a few minutes.

          2. Stuart Halliday

            Re: How well was the PC prepared? TEMPEST?

            I think I'd notice a 10" loop aerial lying around...

          3. This post has been deleted by its author

        2. Kiwi

          Re: How well was the PC prepared?

          Even a TEMPEST-rated case?

          Where do you buy them? DDG, Google, Amazon - nada. the only reference is a /. post back in 1999!

      2. Mage Silver badge

        Re: How well was the PC prepared?

        Fine mesh over the holes works. The SDRs only work up to 1.7GHz away even that would allow larger holes than on a perforated Sky dish. (Small enough so it looks solid at 12.6GHz, but poor reflector at 20GHz). C band "Mesh"/Perforated dishes have bigger holes as maximum is less than 4.5GHz.

        A lot of gear is badly screened, shielded or filtered. The FCC and CE RFI tests are both too lax and also often not realistic test scenarios (RFI from electronic ballasts or SMPSU radiated by lighting wiring that tends to be a loop, "power line ethernet" that are really transmitters and pass by only testing one or having no data). Sometimes after the FCC / CE approvals are obtained they leave out the filter parts to save money as there is little to zero in market retail sales testing.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like