Reworking OpenSSL code from using files to reading keys from memory

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Reworking OpenSSL code from using files to reading keys from memory

Wojciech Kocjan
Hello,

I am working on reworking existing code that uses several OpenSSL APIs
from using files to store keys, certificates and CAs to passing this
directly from memory (so that it can be retrieved from memory, read
from encrypted storage among other things).

This is my first post here, so if this is not the correct group and/or
anything below seems obvious/completely incorrect, please feel free to
correct me.

Our code currently uses the following APIs:

- SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file

This part seems easier. From what I understand, I can use BIO_s_mem
and pass it key/certificate data from memory. I could then use PEM to
get EVP_PKEY or X509.

Then I could just invoke SSL_CTX_use_certificate() and
SSL_CTX_use_PrivateKey() directly.

In practice it may be a bit more complex, but at least I know the solution.

- SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis

This part is the harder one. I was not able to find any APIs to do this.

Another alternative I was wondering about is whether I can provide
another way for OpenSSL to access the keys - i.e. so that I can tell
that filename is something like mystorage://key1.pem and OpenSSL would
use my BIO (or create BIO_s_mem and preload it with data) instead of
BIO_s_file.

Thanks.

--
WK
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Reworking OpenSSL code from using files to reading keys from memory

Huaqing Wang
In similar way, you could generate your own BIO by BIO_new_mem_buf((void*) cacert, len).
Then call PEM_X509_INFO_read_bio,
then e.g. for x509, use X509_STORE_add_cert for each one in sk_x509_INFO_num().

Hope this helps
Huaqing

On Wed, Jan 11, 2012 at 2:47 PM, Wojciech Kocjan <[hidden email]> wrote:
Hello,

I am working on reworking existing code that uses several OpenSSL APIs
from using files to store keys, certificates and CAs to passing this
directly from memory (so that it can be retrieved from memory, read
from encrypted storage among other things).

This is my first post here, so if this is not the correct group and/or
anything below seems obvious/completely incorrect, please feel free to
correct me.

Our code currently uses the following APIs:

- SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file

This part seems easier. From what I understand, I can use BIO_s_mem
and pass it key/certificate data from memory. I could then use PEM to
get EVP_PKEY or X509.

Then I could just invoke SSL_CTX_use_certificate() and
SSL_CTX_use_PrivateKey() directly.

In practice it may be a bit more complex, but at least I know the solution.

- SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis

This part is the harder one. I was not able to find any APIs to do this.

Another alternative I was wondering about is whether I can provide
another way for OpenSSL to access the keys - i.e. so that I can tell
that filename is something like mystorage://key1.pem and OpenSSL would
use my BIO (or create BIO_s_mem and preload it with data) instead of
BIO_s_file.

Thanks.

--
WK
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]



--
Thank you.
Best Regards,
Michael(Huaqing) Wang

Reply | Threaded
Open this post in threaded view
|

RE: Reworking OpenSSL code from using files to reading keys from memory

Dave Thompson-5
In reply to this post by Wojciech Kocjan
> From: [hidden email] On Behalf Of Wojciech Kocjan
> Sent: Wednesday, 11 January, 2012 14:47

> I am working on reworking existing code that uses several OpenSSL APIs
> from using files to store keys, certificates and CAs to passing this
> directly from memory (so that it can be retrieved from memory, read
> from encrypted storage among other things).
>
> This is my first post here, so if this is not the correct group and/or
> anything below seems obvious/completely incorrect, please feel free to
> correct me.
>
> Our code currently uses the following APIs:
>
> - SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file
>
> This part seems easier. From what I understand, I can use BIO_s_mem
> and pass it key/certificate data from memory. I could then use PEM to
> get EVP_PKEY or X509.
>
For PEM files yes. For DER files (which OpenSSL also supports here)
use d2i_*_bio on BIO_s_mem or d2i_* directly on memory.

> Then I could just invoke SSL_CTX_use_certificate() and
> SSL_CTX_use_PrivateKey() directly.
>
> In practice it may be a bit more complex, but at least I know
> the solution.
>
> - SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis
>
> This part is the harder one. I was not able to find any APIs
> to do this.
>
_set_client_CA_list already takes STACK_OF(X509). Instead of
getting that stack from SSL_load_client_CA_file, construct it
yourself with sk_X509_new etc. Or use SSL_add_client_CA instead.

_load_verify_ is the hard one. The builtin X509_STORE/X509_LOOKUP
mechanism only does PEM files. It *is* pluggable -- you can
substitute your own LOOKUP's -- but it appears to me you have to
reimplement quite a bit, and I haven't made the attempt.

> Another alternative I was wondering about is whether I can provide
> another way for OpenSSL to access the keys - i.e. so that I can tell
> that filename is something like mystorage://key1.pem and OpenSSL would
> use my BIO (or create BIO_s_mem and preload it with data) instead of
> BIO_s_file.
>
AFAIK not at the OpenSSL level for _load_verify_.

If your OS has any kind of virtual files or filesystems, you could
use those. Most(?) nowadays have at least something for remote files,
like NFS or NetBIOS/SMB, that you can use/fake with enough effort.
AIUI at least Windows and Linux have ways to install your own driver,
which could do this sort of thing, but those aren't simple to write.
This is dependent on your OS of course, and often requires 'root'
or 'admin' which an SSL (and OpenSSL) app doesn't otherwise need.

Similarly, your C library's "fopen" *could* have a capability like
this. But I haven't seen it in any commonly used ones. I've heard
a rumor Plan9 does, but I doubt you (or your users) use Plan9.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Reworking OpenSSL code from using files to reading keys from memory

Michael S. Zick-4
On Thu January 12 2012, Dave Thompson wrote:

> > From: [hidden email] On Behalf Of Wojciech Kocjan
> > Sent: Wednesday, 11 January, 2012 14:47
>
> > I am working on reworking existing code that uses several OpenSSL APIs
> > from using files to store keys, certificates and CAs to passing this
> > directly from memory (so that it can be retrieved from memory, read
> > from encrypted storage among other things).
> >
> > This is my first post here, so if this is not the correct group and/or
> > anything below seems obvious/completely incorrect, please feel free to
> > correct me.
> >
> > Our code currently uses the following APIs:
> >
> > - SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file
> >
> > This part seems easier. From what I understand, I can use BIO_s_mem
> > and pass it key/certificate data from memory. I could then use PEM to
> > get EVP_PKEY or X509.
> >
> For PEM files yes. For DER files (which OpenSSL also supports here)
> use d2i_*_bio on BIO_s_mem or d2i_* directly on memory.
>
> > Then I could just invoke SSL_CTX_use_certificate() and
> > SSL_CTX_use_PrivateKey() directly.
> >
> > In practice it may be a bit more complex, but at least I know
> > the solution.
> >
> > - SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis
> >
> > This part is the harder one. I was not able to find any APIs
> > to do this.
> >
> _set_client_CA_list already takes STACK_OF(X509). Instead of
> getting that stack from SSL_load_client_CA_file, construct it
> yourself with sk_X509_new etc. Or use SSL_add_client_CA instead.
>
> _load_verify_ is the hard one. The builtin X509_STORE/X509_LOOKUP
> mechanism only does PEM files. It *is* pluggable -- you can
> substitute your own LOOKUP's -- but it appears to me you have to
> reimplement quite a bit, and I haven't made the attempt.
>
> > Another alternative I was wondering about is whether I can provide
> > another way for OpenSSL to access the keys - i.e. so that I can tell
> > that filename is something like mystorage://key1.pem and OpenSSL would
> > use my BIO (or create BIO_s_mem and preload it with data) instead of
> > BIO_s_file.
> >
> AFAIK not at the OpenSSL level for _load_verify_.
>
> If your OS has any kind of virtual files or filesystems, you could
> use those. Most(?) nowadays have at least something for remote files,
> like NFS or NetBIOS/SMB, that you can use/fake with enough effort.
> AIUI at least Windows and Linux have ways to install your own driver,
> which could do this sort of thing, but those aren't simple to write.
> This is dependent on your OS of course, and often requires 'root'
> or 'admin' which an SSL (and OpenSSL) app doesn't otherwise need.
>
> Similarly, your C library's "fopen" *could* have a capability like
> this. But I haven't seen it in any commonly used ones. I've heard
> a rumor Plan9 does, but I doubt you (or your users) use Plan9.
>

If using gnu/binutils ld to build your application for the custom
OS (or native ld on HP-UX or Solaris) you can use the linker's:
--wrap=symbol command option to provide your own "fopen" as required.

Ref:
http://okmij.org/ftp/syscall-interpose.html
http://linux.die.net/man/1/ld

Mike
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]