Extracting the Private Key from a TREZOR
jochen-hoenicke.de
jochen-hoenicke.de
Jochen did a responsible disclosure and this has been fixed already in the firmware before the article hit. Also he is actively submitting patches to the firmware, which is awesome.
I will also note we have a bug bounty program - see http://satoshilabs.com/security/
Also, see us at 32c3, some of us are here :)
In general the strongest security is always physical security (attack dogs, machine guns, etc). The problem with that, of course, is that someone more vicious might come along. Also, physical security is somewhat vulnerable to physical degradation (earthquakes, fires, etc) Also, physical security is pretty awkward to implement and maintain, plus it really complicates access and transfer of secured materials.
http://www.rambus.com/security/dpa-countermeasures/
The solutions for many (most?) of these problems are patented.
Very aggravating that this is still true.
Keep in mind that side channels are very much a moving target - an implementation that isn't vulnerable to a known attack today could fall to an attack discovered tomorrow. Unless you take extradinary measures to prevent physical measurements of your implementation and detect and respond to physical tamper events, some kind of attack (practical or not) will probably turn up during the useful life of an implementation, in my experience.
With small and/or low-cost devices, such physical countermeasures are usually impractical, so you have to take extra care on the HW/SW algorithm implementation side to avoid vulnerabilities.
Using an internal power source, like a primary lithium cell, is one way to circumvent the power sidechannel. But power sidechannels can also easily become RF sidechannels, so it's still good to minimize them.