On Tue, 2017-01-31 at 14:28 -0500, Ken Goldman wrote: > On 1/30/2017 11:04 AM, James Bottomley wrote: > > > > This depends what your threat model is. For ssh keys, you worry > > that someone might be watching, so you use HMAC authority even for > > a local TPM. > > If someone can "watch" my local process, they can capture my password > anyway. Does using a password that the attacker knows to HMAC the > command help?
It's about attack surface. If you want my password and I use TPM_RS_PW then you either prise it out of my app or snoop the command path. If I always use HMAC, I know you can only prise it out of my app (reduction in attack surface) and I can plan defences accordingly (not saying I'll be successful, just saying I have a better idea where the attack is coming from). > > In the cloud, you don't quite know where the TPM is, so again you'd > > use HMAC sessions ... however, in both use cases the sessions > > should be very short lived. > > If your entire application is in the cloud, then I think the same > question as above applies. > > If you have your application on one platform (that you trust) and the > TPM is on another (that you don't trust), then I absolutely agree > that HMAC (and parameter encryption) are necessary. It's attack surface again ... although lengthening the transmission pathway, which happens in the cloud, correspondingly increases that sur face. Look at it this way: if your TPM were network remote, would you still think TPM_RS_PW to be appropriate? I suspect not because the network is seen as a very insecure pathway. We can argue about the relative security or insecurity of other pathways to the TPM, but it's unarguable that using HMAC and parameter encryption means we don't have to (and so is best practice). James
