<div dir="ltr">Oops, the symmetric key is encrypted with public, decrypted with private. It's not secure the other way. But anyway, this provides a way for the public-key encryption to all live in the cryptographic token device, and the userspace stuff actually does symmetrical encryption with an ephemeral key.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 10:19 PM, Bruce Perens <span dir="ltr"><<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">> <span style="font-size:12.8px">openssl runs in userland too and needs the key live.  I must pass openssl the key + passphrase in userland as it is.</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">You'd think that OpenSSL would need the private key for the entire session, but it does not!</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The start of the OpenSSL transaction uses the private key to encrypt an ephemeral symmetrical encryption key. I think this uses the IDEA algorithm for symmetrical encryption. The ephemeral key is passed to the other side which decrypts it with the public key. The entire rest of the OpenSSL communication goes on using the ephemeral key and symmetrical encryption, and the private key is not used again!</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This is for two reasons: 1: public-key encryption is too slow. 2: SSL was actually designed to use hardware cryptographic token devices to protect the key.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This really works, I've used it for years. I own private keys which I can't read, and they work!</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 9:52 PM, Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On June 10, 2016 12:16:05 PM GMT+08:00, Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> wrote:<br>
>Andy, the private key really should live in separate hardware from your<br>
>process address space or anything that the OS can read.<br>
><br>
>The proper practice is to use an encryption token which never discloses<br>
>the<br>
>private key, but performs the encryption in tamper-resistant hardware<br>
>and<br>
>only passes the result to your program.<br>
<br>
</span>It sounds good, but there seems to be some basic problem that I am running a userland app, openssl runs in userland too and needs the key live.  I must pass openssl the key + passphrase in userland as it is.<br>
<br>
As root I can go look at his memory pages, or I can debug his process.<br>
<br>
Or if my app can get things manipulated by this 'tamper resistant hardware', I can inject my request in the userland app, or by duplicating what the app does on usb or whatever, and get things signed by it as if I was the app.<br>
<br>
There are systems like trustzone with partitioning even in the mmu to try to keep things secure, but openssl on a generic linux box doesn't have anything like that (and there's still the problem of deciding if a request from the untrusted part is legit or the request IS the attack).<br>
<br>
Linux kernel also has something about protected memory kernelside, but I think it's just on kernelside.<br>
<br>
So I dunno what lws can do about his request... is there something concrete we can do?<br>
<span><font color="#888888"><br>
-Andy<br>
</font></span><div><div><br>
>On Thu, Jun 9, 2016 at 9:12 PM, Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>> wrote:<br>
>><br>
>> Can you explain what a "not open memory area" looks like?<br>
>><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>