Comments on: Glitch attacks revealed http://rdist.root.org/2007/05/07/glitch-attacks-revealed/ Embedded security, crypto, software protection Mon, 08 Mar 2010 21:19:29 +0000 http://wordpress.com/ hourly 1 By: Jordan http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1590 Jordan Wed, 23 May 2007 03:20:41 +0000 http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1590 Nate, yeah, the process is apparently public workshop to get ideas, NIST goes off and makes changes, it's shopped around internally for a while (I imagine this is where they get NSA and CSE (Canada's NSA) to give feedback as well), then everybody else gets 90 days. I like your comment about this keeping the vendors from fiddling too much. It seems like FIPS is working pretty well as opposed to say, some of the criticism various internet standards bodies have been getting lately, and that process is probably part of the reason why. ;-) Also, to your comment about the different glitch resistance levels, I got the impression that only the higher levels will take those attacks into account, though I could be wrong. Also, speaking of higher levels, the requirement for a formal model has been moved to a new level 5. Apparently that was a huge sticking point for a lot of the level4 modules, so creating a new level 5 that's similar to the previous level 4 allows for a bit more differentiation. Nate, yeah, the process is apparently public workshop to get ideas, NIST goes off and makes changes, it’s shopped around internally for a while (I imagine this is where they get NSA and CSE (Canada’s NSA) to give feedback as well), then everybody else gets 90 days. I like your comment about this keeping the vendors from fiddling too much. It seems like FIPS is working pretty well as opposed to say, some of the criticism various internet standards bodies have been getting lately, and that process is probably part of the reason why. ;-)

Also, to your comment about the different glitch resistance levels, I got the impression that only the higher levels will take those attacks into account, though I could be wrong. Also, speaking of higher levels, the requirement for a formal model has been moved to a new level 5. Apparently that was a huge sticking point for a lot of the level4 modules, so creating a new level 5 that’s similar to the previous level 4 allows for a bit more differentiation.

]]> By: Nate Lawson http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1323 Nate Lawson Thu, 10 May 2007 03:21:11 +0000 http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1323 Shawn, yes, I helped prepare for that presentation. As far as I know, after that workshop, NIST is preparing 140-3 on their own without further consultation with industry. This may be a good thing in preventing too much vendor influence. It will be interesting to see what they come up with because it's hard to establish metrics for these things. What's level 1 glitch resistance vs. level 2? You're right that testing will be more dependent than ever on the individual tester's expertise/creativity. It's also sad that vendors are incentivized to pick the worst lab (least creative in attacks) because it gives them more likelihood of a higher rating. That's something that's been difficult with FIPS 140 since the beginning. Shawn, yes, I helped prepare for that presentation. As far as I know, after that workshop, NIST is preparing 140-3 on their own without further consultation with industry. This may be a good thing in preventing too much vendor influence.

It will be interesting to see what they come up with because it’s hard to establish metrics for these things. What’s level 1 glitch resistance vs. level 2? You’re right that testing will be more dependent than ever on the individual tester’s expertise/creativity. It’s also sad that vendors are incentivized to pick the worst lab (least creative in attacks) because it gives them more likelihood of a higher rating. That’s something that’s been difficult with FIPS 140 since the beginning.

]]> By: Shawn F http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1280 Shawn F Tue, 08 May 2007 06:24:34 +0000 http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1280 NIST had a physical security workshop, which cryptography research presented at, to discuss these issues. I think one of the problems is that, and I am being a bit presumptuous here, the FIPS labs don’t have near the expertise needed to successfully mount side channel attacks. These sorts of attacks require very specialized knowledge and for some (e.g. laser fault injection) expensive equipment. I imagine that if they do address this at all, it will be more at the design review phase rather than any testing. NIST had a physical security workshop, which cryptography research presented at, to discuss these issues. I think one of the problems is that, and I am being a bit presumptuous here, the FIPS labs don’t have near the expertise needed to successfully mount side channel attacks. These sorts of attacks require very specialized knowledge and for some (e.g. laser fault injection) expensive equipment. I imagine that if they do address this at all, it will be more at the design review phase rather than any testing.

]]> By: Nate Lawson http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1274 Nate Lawson Tue, 08 May 2007 01:39:12 +0000 http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1274 Jordan, that's exciting news. I heard rumors that some of these areas might have recommendations or requirements in 140-3 but didn't know where that was in the standards process. Currently, 140-2 merely requires that if devices have countermeasures, they must be listed on the certificate. That results in a pretty vague description of the protection, and there's no way to compare devices. It will be interesting to see how this turns out since it's tough to give metrics for resistance to glitch attacks or side channel leakage. Jordan, that’s exciting news. I heard rumors that some of these areas might have recommendations or requirements in 140-3 but didn’t know where that was in the standards process. Currently, 140-2 merely requires that if devices have countermeasures, they must be listed on the certificate. That results in a pretty vague description of the protection, and there’s no way to compare devices. It will be interesting to see how this turns out since it’s tough to give metrics for resistance to glitch attacks or side channel leakage.

]]> By: Jordan Wiens http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1269 Jordan Wiens Mon, 07 May 2007 17:23:16 +0000 http://rdist.root.org/2007/05/07/glitch-attacks-revealed/#comment-1269 On this topic, I just interviewed the Director of the Cryptographic Module Validation Program at NIST last week and he mentioned this is one of the areas that FIPS 140-3 addresses. Specifically, there's a new "non-invasive protection mechanism" section that will cover such topics as power-analysis, EMP tolerance, optical something or other (ahh, my hand-written notes), and fault-induction. The first draft is done, but is making it's way around the Department of Commerce/NIST internally first before it'll be available for the 90 day public review/comment period. On this topic, I just interviewed the Director of the Cryptographic Module Validation Program at NIST last week and he mentioned this is one of the areas that FIPS 140-3 addresses. Specifically, there’s a new “non-invasive protection mechanism” section that will cover such topics as power-analysis, EMP tolerance, optical something or other (ahh, my hand-written notes), and fault-induction.

The first draft is done, but is making it’s way around the Department of Commerce/NIST internally first before it’ll be available for the 90 day public review/comment period.

]]>