[Libwebsockets] Private key in SSL

Bruce Perens bruce at perens.com
Fri Jun 10 07:34:34 CEST 2016

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

On Thu, Jun 9, 2016 at 10:19 PM, Bruce Perens <bruce at perens.com> wrote:

> > openssl runs in userland too and needs the key live.  I must pass
> openssl the key + passphrase in userland as it is.
> You'd think that OpenSSL would need the private key for the entire
> session, but it does not!
> 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!
> 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.
> This really works, I've used it for years. I own private keys which I
> can't read, and they work!
> On Thu, Jun 9, 2016 at 9:52 PM, Andy Green <andy at warmcat.com> wrote:
>> On June 10, 2016 12:16:05 PM GMT+08:00, Bruce Perens <bruce at perens.com>
>> wrote:
>> >Andy, the private key really should live in separate hardware from your
>> >process address space or anything that the OS can read.
>> >
>> >The proper practice is to use an encryption token which never discloses
>> >the
>> >private key, but performs the encryption in tamper-resistant hardware
>> >and
>> >only passes the result to your program.
>> 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.
>> As root I can go look at his memory pages, or I can debug his process.
>> 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.
>> 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).
>> Linux kernel also has something about protected memory kernelside, but I
>> think it's just on kernelside.
>> So I dunno what lws can do about his request... is there something
>> concrete we can do?
>> -Andy
>> >On Thu, Jun 9, 2016 at 9:12 PM, Andy Green <andy at warmcat.com> wrote:
>> >>
>> >> Can you explain what a "not open memory area" looks like?
>> >>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160609/f7eebbde/attachment-0001.html>

More information about the Libwebsockets mailing list