<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 10:39 PM, Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The key and the passphrase do pass through lws + openssl, that would be enough if the attacker compromises the userland part and then forces the admin to restart it.<br></blockquote><div> </div><div>The key and passphrase remain within the token. So, we have to combine lws and openssl with OpenSC, which controls the token and provides a public-key engine to OpenSSL that causes the token to be used. We don't provide the key to lws, we just provide the <i>name</i> of the key and it asks, through openssl and OpenSC, for the token to use it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
    Or if my app can get things manipulated by this 'tamper resistant<br>
    hardware', I can inject my request in the userland app, or by<br>
    duplicating what the app does on usb or whatever, and get things<br>
    signed by it as if I was the app.<br></span></blockquote></blockquote><div> </div><div>Yes. It will use the key if an unauthorized person gets in a position to ask it to. But it will never reveal the key. So, the compromise is limited.</div></div></div></div>