Re: AMDs new instructions for parallelism and support för side-channel attacks?
=?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= [EMAIL PROTECTED] writes: I just saw om EE Times that AMD will start to extend their x86 CPUs with instructions to support/help developers take advantage of the increasing (potential) parallelism in their processors. First out are two instructions that allows the developer to get info about instruction completion as well as cache misses. Considering the article by . about analysis of protection mechanism against cache based timing attacks for AES [1] one could assume that these instructions should be useful for writing side-channel resistant implementations I think it's exactly the opposite, we're already having enough problems with microarchitectural (MA) attacks without explicit diagnostic facilities built into the CPU. If you look at the AMD specs these extra ring3-accessible facilities are only going to make it worse. These attacks are essentially impossible to defend against merely by modifying the victim code, the only possible defences at the moment are: 1. Don't do that then (i.e. don't allow arbitrary untrusted code to run in parallel with your crypto ops). 2. With future hardware support, some mechanism for partitioning the CPU so that critical regions of code can run without leaving externally observable traces, ending with some sort of super-INVD/INVLPG instruction to clear all caches and buffers. So the code would be something like: enter_secure_region [[[crypto code]]] INV_everything exit_secure_region Of course something like this would have to be accessible from ring 3, which makes it a built-in DoS mechanism. So don't do that then seems to be the only fix for this (not including the usual blue-sky response of everyone having insert-crypto-gadget-du-jour built into their system). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AMDs new instructions for parallelism and?UTF-8?B?IHN1cHBvcnQgZsO2ciBzaWRlLWNoYW5uZWwgYXR0YWNrcz8=?=
=?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= [EMAIL PROTECTED] writes: I just saw om EE Times that AMD will start to extend their x86 CPUs with instructions to support/help developers take advantage of the increasing (potential) parallelism in their processors. First out are two instructions that allows the developer to get info about instruction completion as well as cache misses. Considering the article by . about analysis of protection mechanism against cache based timing attacks for AES [1] one could assume that these instructions should be useful for writing side-channel resistant implementations I think it's exactly the opposite, we're already having enough problems with microarchitectural (MA) attacks without explicit diagnostic facilities built into the CPU. If you look at the AMD specs these extra ring3-accessible facilities are only going to make it worse. These attacks are essentially impossible to defend against merely by modifying the victim code, the only possible defences at the moment are: 1. Don't do that then (i.e. don't allow arbitrary untrusted code to run in parallel with your crypto ops). 2. With future hardware support, some mechanism for partitioning the CPU so that critical regions of code can run without leaving externally observable traces, ending with some sort of super-INVD/INVLPG instruction to clear all caches and buffers. So the code would be something like: enter_secure_region [[[crypto code]]] INV_everything exit_secure_region Of course something like this would have to be accessible from ring 3, which makes it a built-in DoS mechanism. So don't do that then seems to be the only fix for this (not including the usual blue-sky response of everyone having insert-crypto-gadget-du-jour built into their system). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
Paul Hoffman [EMAIL PROTECTED] writes: At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote: |From a security point of view, this is really bad. From a usability point of |view, it's necessary. As you can see from my list of proposed solutions, I disagree. I see no reason not to to alert a user *who has removed a root* that you are about to put it back in. It depends on what you mean by user. You're assuming that direct action by the wetware behind the keyboard resulted in its removal. However given how obscure and well-hidden this capability is, it's more likely that a user agent acting with the user's rights caused the problem. So the message you end up communicating to the user is: Something you've never heard of before has changed a setting you've never heard of before that affects the operation of something you've never heard of before and probably wouldn't understand no matter how patiently we explain it. (those things are, in order some application or script, the cert trust setting, certificates, and PKI). I guess we'd need word from MS on whether this is by design or by accident, but I can well see that quietly unbreaking something that's broken for some reason would be seen as desirable behaviour. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
Paul Hoffman [EMAIL PROTECTED] writes: I posted a new security research article at http://www.proper.com/root-cert-problem/. It is not directly related to crypto (although not so much of the traffic on this list is...), it does relate to some PKI topics that are favorites of this list. The executive summary, so I've got something to reply to: In the default configuration for Windows XP with Service Pack 2 (SP2), if a user removes one of the trusted root certificates, and the certifier who issued that root certificate is trusted by Microsoft, Windows will silently add the root certificate back into the user's store and use the original trust settings. While I don't agree with this behaviour, I can see why Microsoft would do this, and I can't see them changing it at any time in the future. It's the same reason why they ignore key usage restrictions and allow (for example) an encryption-only key to be used for signatures, and a thousand other breaches of PKI etiquette: There'd be too many user complaints if they didn't. The people designing this stuff aren't the ones who have to man the tech helpdesk when users find that things break because of some action that they don't even understand (see e.g. the Xerox PARC study where a bunch of people with PhDs in computer science, after following paint-by-numbers instructions to install certs on their machines, had absolutely no idea what they'd just done to their computers). From a security point of view, this is really bad. From a usability point of view, it's necessary. The solution is to let the HCI people into the design process, something that's very rarely, if ever, done in the security field [0]. Peter. [0] Before people jump up and down about this: Yes, HCISec has become a very active and productive field in the last few years. Unfortunately far too little of the work that's being done is making it into products though. We have lots of data saying X is unusable in practice and The best way to handle this is Y, but developers keep on pushing X and avoiding (or don't even know about) Y. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
