What is the origin of side-channel attacks? Is it related to the algorithm or to the implementation? In other words, is the software responsible for the attack or the hardware?
Is there a cryptographic algorithm that is resistant to side-channel attacks on system A, but is not on System B?
Can we call algorithms side-channel resistant?
Side Channel attacks leverage information gained from observing or interacting with a system in a way other than anticipated by its creators. Often this is done to infer information about encryption keys or other secret information.
Some of the most common side channel attack vectors are:
Examples for the mentioned include:
While Wikipedia states that:
... a side-channel attack is any attack based on information gained from the physical implementation of a cryptosystem ...
I would argue (along with Bernstein and others) that side channel weaknesses may also emerge from design. In the AES example this is due to the fact that it is pretty much infeasible to write constant-time performing code for general computing while maintaining efficiency.
So to come back to your question; while you exploit a side channel attack in an implemented system, the root cause for its existence cannot generally be attributed to implementation only. You will have to look at a specific system and its implementations, and you may find that the answer to the question depends largely on where you place the boundary between design and implementation.
(If the design of AES had guaranteed static computing times, the timing attack would not have been feasible on any correct implementation as an example...)
You may, however, have differing implementations of AES which are or are not vulnerable to a timing attack, to answer your question about systems A & B (System A may enforce static computing times while B does not).
With a well-defined attacker model I would say that you could define a side channel resistant algorithm. Please clarify that question tough - not sure I understood you fully..
Edit: Some more fun and interesting reading in this brief and easily readable article. :)
The term "side-channel" may refer to two different things: one is hinted by the other answers (accidental details of implementation which leak out via non-deliberate data stream). The term may also refer to a potentially-deliberate inclusion of cryptographic secrets within what should be random parts of a data stream. For example, a program which is supposed to pad a small secret (e.g. an AES key) with random data and RSA encrypt it might if maliciously designed, change the implementation slightly:
Loop:
Pad secret with random data
Encrypt it
Interpret bits 151..181 of the resulting crypto stream as a number I
Examine bit (I mod RSA_keylength) of the RSA secret key
If the aforementioned bit doesn't match bit 504 of the crypto stream, goto Loop
If this evil implementation is used to exchange very many secrets, an attacker will be able to find out most of the bits of the RSA secret key entirely through easy passive observation. Someone who didn't know about the hidden side channel, however, would notice nothing unusual about the messages. Indeed, even someone who did know about the side channel would be unable to tell whether any particular message included it. Only by examining many messages would the side channel be detectable even for someone who knew what to look for.
Side channel attack is definitely due to the implementation (clarification, I do not mean that the implementation is wrong, see below).
They originate from the fact that a mathematical computation needs a computer to process things. So to speak, the side channel information of an encryption process is the impact of the physical activities that are deployed to compute it. They are a consequence of the physical world.
To be resistant to side-channel attacks you have to :
And this can be do both by hardware and software. Eventually, all relates to the physical particularity of the system used.
Example: measuring the power consumption during key generation.
The excess power needed to process a 1 (instead of a 0) is a side-effect of the tools used to do the calculations. Like if I'd use an EEG to see if you're thinking of a 1 or a 0. They are problem that aren't coming from the algorithm design, but by the reality.
Side channel attacks are those based on exploiting certain aspects of the implementation and not due to mathematical weaknesses in the cryptographic algorithms.
Some are exposed due to hardware implementation choices. For example, a CPU may draw more power at a certain point in execution in the case where bit 1 of the key is true, and less power when bit 1 of the key is false.
Others may be exposed due to timing choices that occur in the software implementation of the cryptographic algorithm. There was a successful attack on the Bouncy Castle implementation of TLS because a MAC algorithm's implementation took a faster path through the code in the case when a certain bit was set to a certain value. (I think this was the root cause of CVE-2013-1624.)
In many cases, especially those due to timing, one common way to address a side channel attack is by changing the software implementation. By ensuring all branches take a constant amount of time regardless of the value of the bits, such information leakage can be prevented. In a high-level language implementation, compiler optimizations can be an unwitting cause of leakage, which is yet another reason that a "roll-your-own" approach to cryptography can be a problem.
Like i pointed out, side channel/side bands are side effects that arise from the main carrier band/implementation. The term originates from radio transmissions & communications, and so without trying to attack the problem head on by dealing with the main implementation, you analyse side channels instead to gain insight into the problem.
It's kind of like how you can track power consumption to determine whether the extra round of decryption means your brute force password tries are working.
