Re: Who cares about side-channel attacks?
> Examples of side channel analysis on real systems I however have never > seen in the field. Any rumors would be highly appreciated. > At Crypto'08 a team from Bochum demonstrated their side-channel attack on KeeLoq. There were some theoretical attacks before but the SCA really broke it. KeeLoq is being used by some car manufacturers and by most garage door manufacturers. Regards Tanja - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
Wouter Slegers <[EMAIL PROTECTED]> writes: >Timing analysis is quite possible to pull of in straightforward >implementations as demonstrated over the Internet on OpenSSL prior to their >implementation of blinding ( >http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf). But frankly, I have >never heard of such an attack actually being used in the field. Real side >channel analysis (DPA, EMA etc) seems mostly limited to academics and labs, >not the field. One of the XBox attacks, allowing rollback to a vulnerable kernel, was a timing attack. I'd heard it was also tried in some form (unsuccessfully) against the Wii as part of the breadth-first attack approach. >I'm afraid that the best at this moment is mostly rumors. There is some >knowledge about attacks in the field but it is spread out a lot and the ones >that aggregate this information are not sharing this (it also gives the >attackers a view on what works and what not). You can see this with the games-console hacking, the attackers try and release the least amount of information possible so they've got something in reserve when the countermeasures appear. In some cases they use attack method A to find a weakness and then exploit it using unrelated method B, allowing reuse of method A once B is patched by the vendor. >As I read his story, he eavesdropped the bus between the bridge chip and the >CPU to recover the real bootloader code with the real RC4 key, Sorry, I was referring to two different attacks in the same sentence, and on re-reading managed to make the result quite unclear :-). The timing attack didn't directly recover the authentication key directly but avoided the need to know it, thus allowing unauthorised vulnerable kernels to be loaded. >not the incorrect one in the ROM (very nasty trick, kudo's for the Microsoft >development team there ;-) ). Often the simplest tricks are the most effective, e.g. stick a PGP header on the data to be protected and the attackers spend forever trying to decrypt it when in fact the processing function is (in pseudocode): seek( file, 16 );// Skip red-herring junk at start processData( file ); (the problem with this one was that they memcpy()'d the fixed header on and the lengths were wrong, but apart from that it would probably have distracted attackers for some time). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
L.S., Peter convinced my to publicly comment on this. Thierry Moreau <[EMAIL PROTECTED]> wrote: > >>But they've all been unlocked using easier attacks, surely? That was also my first response. In evaluation labs specialized in checking devices (mostly smartcards and other financial devices) the whole spread of attacks are tested against. Side-channel analysis is arguably the most sexy of them all, but I have yet to see any hint let alone proof that it is used in the field. Perturbation attacks (messing with the execution of the code) by means of glitches in the supply voltage is still the undisputed number 1 in field attacks on individual smartcards. Protocol/API-level attacks are the biggest one on system level in my opinion. Card sharing is currently a good example. Timing analysis is quite possible to pull of in straightforward implementations as demonstrated over the Internet on OpenSSL prior to their implementation of blinding (http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf). But frankly, I have never heard of such an attack actually being used in the field. Real side channel analysis (DPA, EMA etc) seems mostly limited to academics and labs, not the field. >From that regard, side channel analysis is currently the more expensive attack (the academic papers are good, but do not underestimate the difficulty in implementing it in non-ideal noisy environments), which suggest that protecting for it is not such a high priority at the moment (it is not the weakest link). > >The published ones seem to be the (relatively) easy ones, but the > >ones that have been tried (and either not published or just had the > >easy outcome published) have been pretty amazing. Which suggests that keeping side channel analysis as part of the possible attacks is a good idea. The broad scope of attacks seems to be done in the field, which means that it is interesting for the defenders to invest effort in that also. In a way, the enthousiast attackers on the internet form a sort of loosly parallel attack, not so much obviously focussing on one weak spot but using a broad spectrum approach. > >This is another one of these things where real figures are going to > >be near-impossible to come by, even harder than my hypothetical > >public vendor survey of who uses SCA protection. I'm afraid that the best at this moment is mostly rumors. There is some knowledge about attacks in the field but it is spread out a lot and the ones that aggregate this information are not sharing this (it also gives the attackers a view on what works and what not). I've seen quite a few publicly available examples of voltage manipulation on old style smartcards, (not so-)secure embedded CPUs. Old style physical reverse engineering is getting within the range of students now (recent reverse engineering of crypto-1 is a good example). Examples of side channel analysis on real systems I however have never seen in the field. Any rumors would be highly appreciated. > >attacks for example, there's everything from security 101 lack of > >checking/validation and 1980s MSDOS-era A20# issues through to Bunnie > >Huang's FPGA-based homebrew logic analyser and use of timing attacks > >to recover device keys (oh, and there's an example of a real-world > >side-channel attack for you), ?? As I read his story, he eavesdropped the bus between the bridge chip and the CPU to recover the real bootloader code with the real RC4 key, not the incorrect one in the ROM (very nasty trick, kudo's for the Microsoft development team there ;-) ). Ref http://www.xenatera.com/bunnie/proj/anatak/AIM-2002-008.pdf Nevertheless, this is a good example of economically unreasonable attacks: Bunnie spent something like 4 months of his master thesis' time on hacking the Xbox and then gave that knowledge away for free on the internet. 4 months of "honest work" would have bought him that Xbox and all consoles he could have wanted for quite some time... [snip good list of things to consider] > This gives an idea of analyses that drives security-related spendings > (in my limited experience). Clients (intend to) pay for protections that > will prevent financial losses and major public relations impacts (and > then cut operating budgets soon after the project gets its > authorization!). The consultant study must clearly link attackers' > motivations to impacts and to countermeasures. I agree. From commercial point of view, the developer's point of view of side channel analysis protection (and most other protections I think) is I think: Costs: - Additional resources in the device (memory, CPU time). Unless the device is severely resource bound (like a very tight power budget, really limited memory sizes like in a smartcard), this is not really a cost. - Significant and specialized additional development resources to implement the countermeasures well. To do the whole protection, not just the blinding, well is a real engineering effort. It also requires a specific
Re: Who cares about side-channel attacks?
On Thu, 2008-10-30 at 16:32 +1300, Peter Gutmann wrote: > Look at the XBox > attacks for example, there's everything from security 101 lack of > checking/validation and 1980s MSDOS-era A20# issues through to Bunnie Huang's > FPGA-based homebrew logic analyser and use of timing attacks to recover device > keys (oh, and there's an example of a real-world side-channel attack for you), > there's no rhyme or reason to them, it's just "hammer away at everything with > anything you've got and exploit the first bit that fails". But isn't that the attacker's job? We will never arrive at anything secure - or even *learn* anything about how to build real security - if attackers leave any part of it untested or consistently fail to try particular approaches. As far as I can see the "acid tests" of the real world, hammering away with anything they've got, are exactly the kind of environment that security pros have to design for in the long run. We should be trying to identify products and implementations that hold up under this kind of assault, and then publishing books about the design processes and best practices that produced them. Knowing full well that Kerchoff's Principle is alive and well, and that the people doing the attacks will be first in line to buy the books. The point is that if the material in the books is any good, then having the books shouldn't help them. Cipher suites and protocols and proofs and advanced mathematics are well and good, but we have to recognize that they are only a small part of actually building a secure implementation. Holding up under diverse assault *is* the desired property that we are all supposed to be working toward, and this kind of diverse assault is exactly the sort of test we need to validate security design processes. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
On Wed, 29 Oct 2008 23:41:40 -0500 Thierry Moreau <[EMAIL PROTECTED]> wrote: > Does SCA protection enter the picture? Marginally at best. > You're forgetting the first questions you need to ask: who are your enemies, what are you trying to protect, and what can you enemy spend? And regardless of the answer to the last part, it's safe to assume that your enemy would prefer to spend as little as possible. Note that "spend" includes not just dollars, euros, zorkmids, or linden dollars, but also reputation if discovered, attack techniques you may or may not want to reveal, etc. So -- why do a side-channel attack involving, say, a million SSL messages (see http://www.cert.org/advisories/CA-1998-07.html), when that's the sort of thing that will show up in a log file, when you can send a simple RPC query (http://www.microsoft.com/technet/security/Bulletin/ms08-067.mspx) to learn a private key? But -- if you're a transit getting ready to deploy fare cards that depend on a chip being secure, you'd better be very careful about side channels, because those attacks can be tried offline. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
Peter Gutmann wrote: Ben Laurie <[EMAIL PROTECTED]> writes: Peter Gutmann wrote: Given the string of attacks on crypto in embedded devices (XBox, iPhone, iOpener, Wii, some not-yet-published ones on HDCP devices :-), etc) this is by far the most at-risk category because there's a huge incentive to attack them, the result affects tens/hundreds of millions of devices, and the attacks are immediately and widely actively exploited (modchips/device unlocking/etc, an important difference between this and academic proof-of-concept attacks), so this is the one where I'd expect the vendors to care most. But they've all been unlocked using easier attacks, surely? The published ones seem to be the (relatively) easy ones, but the ones that have been tried (and either not published or just had the easy outcome published) have been pretty amazing. This is another one of these things where real figures are going to be near-impossible to come by, even harder than my hypothetical public vendor survey of who uses SCA protection. You'd have to read about 20 blogs and a hundred mailing lists, many private, just to keep up, but from various informal contacts with people working in this area it seems you're not looking at anything like the conventional "identify the weakest point, then attack there" approach. Instead what's being done is more like the Iraqi weapons program prior to 1991 where they were using every imaginable type of approach, including ones like calutrons that had been abandoned decades earlier by everyone else, for a first-past-the-post finish, they'd try anything and everything and whatever got them there first would be declared the winner. It's the same with these attacks, whenever I've asked "have you tried X" the answer is invariably "yes, we have". This style of attack is quite different from the usual academic model, it neatly illustrates Bruce Schneier's comment that a defender has to defend every single point along the line while an attacker only has to find a single weakness. In this case it seems to be literally true, and the weakness won't necessarily be the actual weakest point but merely the point where an attacker with sufficient skill and access to the right tools got in. Look at the XBox attacks for example, there's everything from security 101 lack of checking/validation and 1980s MSDOS-era A20# issues through to Bunnie Huang's FPGA-based homebrew logic analyser and use of timing attacks to recover device keys (oh, and there's an example of a real-world side-channel attack for you), there's no rhyme or reason to them, it's just "hammer away at everything with anything you've got and exploit the first bit that fails". Now you seem to answer the question yourself: SCA protections apply to a single class of attacks, while there are many. Going back to "who cares", having done certification consulting assignments for some devices with crypto, when there was no checklist-based standard to apply, "good practice" security criteria (to be briefly documented in the report) would include the following questions: (A) Is the secret key inside a device unit applicable to this single unit, or is it a system-wide, or domain-wide key? That's a key management scheme question. (B) Is the attack destructive? Which device unit features (especially "be in working order", but also "be absent of actual tampering evidence" or even "remain under the control of the legitimate user without interruptions longer than X" ) need to be impaired for a given class of attack to succeed? This question pertains to the secret key as in (A) and also to any public-key-to-be-integrity-protected which would prevent malicious code download. That's a product design question. (C) What are the incentives, if any, for the legitimate user to remain well-behaved in the human aspects of device protection? (E.g. a merchant has some incentive to maintain a payment authorization device in good working order.) This leads to the question of insider threats, so satisfactory answers in this area are seldom present. This is an application design question. This gives an idea of analyses that drives security-related spendings (in my limited experience). Clients (intend to) pay for protections that will prevent financial losses and major public relations impacts (and then cut operating budgets soon after the project gets its authorization!). The consultant study must clearly link attackers' motivations to impacts and to countermeasures. Refinements to the above analysis methodology call for the same creative mind that you assume from the part of the attackers. E.g. the usefulness of a device unit clone for the attacker should be considered for questions (B) and (C). Does SCA protection enter the picture? Marginally at best. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web s
Re: Who cares about side-channel attacks?
Ben Laurie <[EMAIL PROTECTED]> writes: >Peter Gutmann wrote: >> Given the string of >> attacks on crypto in embedded devices (XBox, iPhone, iOpener, Wii, some >> not-yet-published ones on HDCP devices :-), etc) this is by far the most >> at-risk category because there's a huge incentive to attack them, the result >> affects tens/hundreds of millions of devices, and the attacks are immediately >> and widely actively exploited (modchips/device unlocking/etc, an important >> difference between this and academic proof-of-concept attacks), so this is >> the >> one where I'd expect the vendors to care most. > >But they've all been unlocked using easier attacks, surely? The published ones seem to be the (relatively) easy ones, but the ones that have been tried (and either not published or just had the easy outcome published) have been pretty amazing. This is another one of these things where real figures are going to be near-impossible to come by, even harder than my hypothetical public vendor survey of who uses SCA protection. You'd have to read about 20 blogs and a hundred mailing lists, many private, just to keep up, but from various informal contacts with people working in this area it seems you're not looking at anything like the conventional "identify the weakest point, then attack there" approach. Instead what's being done is more like the Iraqi weapons program prior to 1991 where they were using every imaginable type of approach, including ones like calutrons that had been abandoned decades earlier by everyone else, for a first-past-the-post finish, they'd try anything and everything and whatever got them there first would be declared the winner. It's the same with these attacks, whenever I've asked "have you tried X" the answer is invariably "yes, we have". This style of attack is quite different from the usual academic model, it neatly illustrates Bruce Schneier's comment that a defender has to defend every single point along the line while an attacker only has to find a single weakness. In this case it seems to be literally true, and the weakness won't necessarily be the actual weakest point but merely the point where an attacker with sufficient skill and access to the right tools got in. Look at the XBox attacks for example, there's everything from security 101 lack of checking/validation and 1980s MSDOS-era A20# issues through to Bunnie Huang's FPGA-based homebrew logic analyser and use of timing attacks to recover device keys (oh, and there's an example of a real-world side-channel attack for you), there's no rhyme or reason to them, it's just "hammer away at everything with anything you've got and exploit the first bit that fails". Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
Peter Gutmann wrote: > In fact none of the people/organisations I queried about this fitted into any > of the proposed categories, it was all embedded devices, typically SCADA > systems, home automation, consumer electronics, that sort of thing, so it was > really a single category which was "Embedded systems". Given the string of > attacks on crypto in embedded devices (XBox, iPhone, iOpener, Wii, some > not-yet-published ones on HDCP devices :-), etc) this is by far the most > at-risk category because there's a huge incentive to attack them, the result > affects tens/hundreds of millions of devices, and the attacks are immediately > and widely actively exploited (modchips/device unlocking/etc, an important > difference between this and academic proof-of-concept attacks), so this is > the > one where I'd expect the vendors to care most. But they've all been unlocked using easier attacks, surely? -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
Thierry Moreau <[EMAIL PROTECTED]> writes: >I find the question should be refined. It could if there was a large enough repondent base to draw samples from :-). This is one of those surveys that can never be done because no vendor will publicly talk to you about security measures in their embedded systems. In fact none of the people/organisations I queried about this fitted into any of the proposed categories, it was all embedded devices, typically SCADA systems, home automation, consumer electronics, that sort of thing, so it was really a single category which was "Embedded systems". Given the string of attacks on crypto in embedded devices (XBox, iPhone, iOpener, Wii, some not-yet-published ones on HDCP devices :-), etc) this is by far the most at-risk category because there's a huge incentive to attack them, the result affects tens/hundreds of millions of devices, and the attacks are immediately and widely actively exploited (modchips/device unlocking/etc, an important difference between this and academic proof-of-concept attacks), so this is the one where I'd expect the vendors to care most. >Also, for organizations mandated to comply with IT security >certification/guidelines/best-practice, a risk analysis is performed to >keep the auditor at bay, in which SCA protection has very little chance >of even merely being mentioned. How can the SCA protection mechanism fit >the risk analysis discipline? I.e., is it possible to even define SCA >protection in a way that might trigger interest from security >consultants or their clients? Actually that's a special case, or more generally having certification/ auditing requirements (which a private-email responder also mentioned) is a special case in that the risk analysis is now "if I don't do this I don't get sign-off" rather than "it makes good security sense to do this so we'll do it". In the immortal words of the Bastard Operator from Hell, when you have the audit/certification gun pointed at someone's head you can pretty much "[get them to] to run naked across campus with a power-cord rammed up [their] backside" and they'd do it not because they thought it was a terribly good idea but because they had a gun pointed at their head. An associated problem with this is that if vendors are motivated solely by checkbox requirements then they'll often ship the product in a non-approved mode (coughFIPS140cough) to reduce manufacturing or support costs/increase performance/increase ease of use/whatever. It's a nasty catch-22, hold a gun to someone's head and they'll only do what you tell them for as long as the gun is applied. Getting back to the SCADA/home automation/consumer electronics embedded market, the only certification that applies is the likes of FCC Class B, ROHS, CE, and UL. This is why I was interested in finding cases (or counterexamples) of informed-consent use of SCA countermeasures, because in the general embedded-systems case vendor cost/benefit analysis is the only deciding factor on whether it gets used or not, and vendors seem to be deciding (from my own experience and some private-email replies) that it's not worth it. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Who cares about side-channel attacks?
On Mon, Oct 06, 2008 at 05:51:50PM +1300, Peter Gutmann wrote: > For the past several years I've been making a point of asking users of crypto > on embedded systems (which would be particularly good targets for side-channel > attacks, particularly ones that provide content-protection capabilities) > whether they'd consider enabling side-channel attack (SCA - no, not that SCA) > protection in their use of crypto. So far I've never found anyone who's made [...] > In other words the user has to make a conscious decision that SCA protection > is important enough that performance/power consumption can be sacrificed for > it. Can anyone provide any data on users making this tradeoff? And since > negative results are also results, a response of "I've never found anyone who > cares either" is also useful. Since the information may be commercially I have little experience on the embedded crypto side but I do maintain a crypto library that has some non-zero number of users on general desktop and server machines. Basic protections ala your point 2 are provided and enabled by default (blinding, and checking private key operations for consistency with the public, to prevent the really easy attacks). There used to be a toggle to disable blinding, which as far as I know was never used - or at least nobody complained when I removed the toggle. To my memory nobody has ever asked about what SCA measures are or are not enabled, or how to toggle them, though I do have a FAQ entry about it, so perhaps people who really wanted serious side-channel resistence just read that FAQ and moved on to another implementation without ever bothering to contact me - certainly there are some self-selection problems with my sampling. When FlexSecure wrote Botan's ECC implementation for BSI, they implemented a number of anti-timing attack countermeasures - but they were being paid to care about that, so this is probably not a valid datapoint. -Jack - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Who cares about side-channel attacks?
For the past several years I've been making a point of asking users of crypto on embedded systems (which would be particularly good targets for side-channel attacks, particularly ones that provide content-protection capabilities) whether they'd consider enabling side-channel attack (SCA - no, not that SCA) protection in their use of crypto. So far I've never found anyone who's made an informed decision to trade off performance for SCA protection. By "informed decision" I mean the following: - SCA protection isn't enabled by default, i.e. they don't just get it whether they want it or not. - The SCA protection is more than just a token throw-some-blinding-at-the-RSA, it extends to things like pubic/private key validation on load (for example via MACs) to detect key-manipulation attacks, checksumming of key data after each crypto op to detect memory-disturb attacks, and so on. - There is a tangible cost/tradeoff in enabling SCA protection, i.e. it's not just chicken-soup protection, "turn it on, it's a 2GHz multicore CPU it can't hurt". In other words the user has to make a conscious decision that SCA protection is important enough that performance/power consumption can be sacrificed for it. Can anyone provide any data on users making this tradeoff? And since negative results are also results, a response of "I've never found anyone who cares either" is also useful. Since the information may be commercially sensitive, respond in private email if you'd rather not discuss it in public and I'll summarise if there's any interest. (Pre-emptive response to the inevitable "OpenSSL/NSS/xyz smart card/... have had RSA blinding enabled by default since ...": Yes, I know, and now go back and re-read points 1 and 2 above). Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
