Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
1–10 of 69 posts
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#2I remember reading about such attacks for the first time in Neal Stephenson's book Cryptonomicon under the term "Van Eck Phreaking". Looks like its gotten a lot easier in recent years!
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#3This was the AES implementation this was tested against:
The trace below shows our signal for one block of AES-256 encryption running on a SmartFusion2 target. We use OpenSSL's implementation of AES on the ARM Cortex-M3 core of the SmartFusion2. There are clear, distinct patterns for each stage of processing. We see I/O to and from the Cortex-M3, calculations for the key schedule, and the 14 encryption rounds.
So it was a software implementation.
I wonder if and how effective this attack would be against devices with hardware implementations of AES.
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#4This was the AES implementation this was tested against: The trace below shows our signal for one block of AES-256 encryption running on a SmartFusion2 target. We use OpenSSL's implementation of AES on the ARM Cortex-M3 core of the SmartFusion2. There are clear, distinct patterns for each stage of processing. We see I/O to and from the Cortex-M3, calculations for the key schedule, and the 14 encryption rounds. So it…
All it does is messuring power consumtion and uses knowledge about the implementation to calculate the key.
Unless steps have been taken to equal power consumption between different paths, theoretically there is nothing stopping this from working on a hw implementaion of AES.
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#5alright, portable faraday cages for everyone!
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#6Well, in many cases AES keys are used one time, and there's also forward secrecy that guards it from decryption even if the key leaked.
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#7This was the AES implementation this was tested against: The trace below shows our signal for one block of AES-256 encryption running on a SmartFusion2 target. We use OpenSSL's implementation of AES on the ARM Cortex-M3 core of the SmartFusion2. There are clear, distinct patterns for each stage of processing. We see I/O to and from the Cortex-M3, calculations for the key schedule, and the 14 encryption rounds. So it…
All it does is messuring power consumtion and uses knowledge about the implementation to calculate the key. Unless steps have been taken to equal power consumption between different paths, theoretically there is nothing stopping this from working on a hw implementaion of AES.
...how about a random-power-consumer? would it help?
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#8Earlier quoted context omitted.
All it does is messuring power consumtion and uses knowledge about the implementation to calculate the key. Unless steps have been taken to equal power consumption between different paths, theoretically there is nothing stopping this from working on a hw implementaion of AES.
...how about a random-power-consumer? would it help?
Generally mitigations like adding random things only delay attacks like this, they don't prevent them.
Like adding random timings won't prevent timing attacks, adding random sized strings won't prevent chosen plaintext or padding attacks, etc...
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#9This was the AES implementation this was tested against: The trace below shows our signal for one block of AES-256 encryption running on a SmartFusion2 target. We use OpenSSL's implementation of AES on the ARM Cortex-M3 core of the SmartFusion2. There are clear, distinct patterns for each stage of processing. We see I/O to and from the Cortex-M3, calculations for the key schedule, and the 14 encryption rounds. So it…
All it does is messuring power consumtion and uses knowledge about the implementation to calculate the key. Unless steps have been taken to equal power consumption between different paths, theoretically there is nothing stopping this from working on a hw implementaion of AES.
> theoretically
Hardware implementations are designed to make this hard. They also use a lot less power, so any measurements are more difficult / take longer.
Re: Tempest attacks against AES: Stealing keys using minimal equipment [pdf]
#10Earlier quoted context omitted.
All it does is messuring power consumtion and uses knowledge about the implementation to calculate the key. Unless steps have been taken to equal power consumption between different paths, theoretically there is nothing stopping this from working on a hw implementaion of AES.
...how about a random-power-consumer? would it help?
No, not at all. A raised SNR can be overcome in almost all circumstances by making more measurements, i.e. correlation, since noise is not correlated, it is removed. For the same reason random delays don't help against timing attacks.