Hello, I tried to find out how about to use the hardware crypto engines under Solaris (Sun Fire T2000). It seems, that its not just a compilation issue:> For operations that are to be offloaded, it is necessary to restrict use to subset> of OpenSSL functions (the EVP_ functions) and explicitly indicate the use of the PKCS11 > engine; something like the following works for bulk ciphers (the process for RSA is similar):> > ENGINE *e; > ENGINE_load_builtin_engines(); > e = ENGINE_by_id("pkcs11"); > ENGINE_set_default_ciphers(e); > EVP_CIPHER_CTX_init (&ctx); > EVP_EncryptInit (&ctx, EVP_des_cbc (), key, iv); > EVP_EncryptUpdate (.....);Since I'm not familiar with SSL programming, I wonder if it's possible to modify the dovecot 1.2.x source code. Maybe someone has already tried this or can give me hint. Regards. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6337 bytes Desc: S/MIME Cryptographic Signature Url : http://dovecot.org/pipermail/dovecot/attachments/20110418/661f78d3/attachment.bin
Martin Preen put forth on 4/18/2011 5:30 AM:> Hello, > I tried to find out how about to use the hardware crypto engines under > Solaris (Sun Fire T2000). It seems, that its not just a compilation issue: > >> For operations that are to be offloaded, it is necessary to restrict >> use to subset >> of OpenSSL functions (the EVP_ functions) and explicitly indicate the > use of the PKCS11 >> engine; something like the following works for bulk ciphers (the > process for RSA is similar): >> >> ENGINE *e; >> ENGINE_load_builtin_engines(); >> e = ENGINE_by_id("pkcs11"); >> ENGINE_set_default_ciphers(e); >> EVP_CIPHER_CTX_init (&ctx); >> EVP_EncryptInit (&ctx, EVP_des_cbc (), key, iv); >> EVP_EncryptUpdate (.....); > > Since I'm not familiar with SSL programming, I wonder if it's possible to > modify the dovecot 1.2.x source code. Maybe someone has already tried this > or can give me hint.I would think that this would be handled transparently at the system library level. Doesn't SUN ship a set of replacement Solaris crypto libraries which make use the hardware engine in the CPU instead of the normal software routines? -- Stan
The attachment made the message too long for the forum. So I canceled the original. If you want the Sun article, you can google 05071387.pdf. The original went through to Martin. On 4/18/11 5:02 PM, Chris Hoogendyk wrote:> On 4/18/11 6:30 AM, Martin Preen wrote: >> Hello, >> I tried to find out how about to use the hardware crypto engines under >> Solaris (Sun Fire T2000). It seems, that its not just a compilation issue: >> >>> For operations that are to be offloaded, it is necessary to restrict use to subset >> > of OpenSSL functions (the EVP_ functions) and explicitly indicate the use of the PKCS11 >> > engine; something like the following works for bulk ciphers (the process for RSA is similar): >>> >>> ENGINE *e; >>> ENGINE_load_builtin_engines(); >>> e = ENGINE_by_id("pkcs11"); >>> ENGINE_set_default_ciphers(e); >>> EVP_CIPHER_CTX_init (&ctx); >>> EVP_EncryptInit (&ctx, EVP_des_cbc (), key, iv); >>> EVP_EncryptUpdate (.....); >> >> Since I'm not familiar with SSL programming, I wonder if it's possible to >> modify the dovecot 1.2.x source code. Maybe someone has already tried this >> or can give me hint. > > You don't want to do that. > > The objective is for the ssl engine to be low level and basically invisible to layers of > application above that use it. So, build openssl properly and it just works for everything else. > > I'm not at work today, so I don't have reference to my notes. Ah, just found an email I sent to my > colleagues -- copied it below.-- --------------- Chris Hoogendyk - O__ ---- Systems Administrator c/ /'_ --- Biology& Geology Departments (*) \(*) -- 140 Morrill Science Center ~~~~~~~~~~ - University of Massachusetts, Amherst <hoogendyk at bio.umass.edu> --------------- Erd?s 4 -------- Original Message -------- Subject: building apps with ssl Date: Thu, 18 Mar 2010 11:30:42 -0400 From: Chris Hoogendyk<hoogendyk at bio.umass.edu> cool. I've got things working now so that I can build applications with the openssl built by Sun to tap into the cryptographic accelerators on the T2. It turns out that the /opt/coolstack stuff related to openssl is actually symlinks to /usr/sfw. So, in the Makefile, if I set the openssl directory to /usr/sfw, rather than the default /usr/local/openssl, it finds the includes, the libraries, and the binaries that are needed. Then I specifically point the certs directory (in the Makefile) to /usr/local/openssl/certs for local control. Then, for the example of uw-imap, everything builds just fine. This should simply apply to anything we need to build with openssl on any of the T5220s. One side note is that this was a custom Makefile. Applications that use ./configure would presumably find the openssl through the paths provided in /usr/local/src/env. In the process of figuring that out, I also found that one of the most recent Solaris 10 kernel patches that we have on imladris specifically addresses awareness of the crypto accelerators and included patches to the openssl related items in /usr/sfw. So, I'm pretty confident that everything is alright. It's interesting too that in the paper presented at ACM by Sun last year they said that a couple of classes of attacks on crypto processes were negated by running it directly on the CPU. One of them had to do with timing. I should forward that paper to you as well. OK, just attached it. -- --------------- Chris Hoogendyk - O__ ---- Systems Administrator c/ /'_ --- Biology& Geology Departments (*) \(*) -- 140 Morrill Science Center ~~~~~~~~~~ - University of Massachusetts, Amherst <hoogendyk at bio.umass.edu> --------------- Erd?s 4
Hello,
after serveral tests (and reading a lot of howto's) I'm now fairly
convinced
that the Solaris HW-crypto engine is not automatically used. Even when dovecot
ist compiled with the OpenSSL version provided by Solaris.
Currently I have only a T1-CPU available for testing (Sun Fire T2000) and
after patching src/login-common/ssl-proxy-openssl.c (Dovecot 1.2.17) with
ENGINE *e;
ENGINE_load_builtin_engines();
ENGINE_init((e=ENGINE_by_id("pkcs11")));
ENGINE_set_default_RSA(e); ENGINE_set_default_DSA(e);
ENGINE_set_default_ciphers(e);
in ssl_proxy_init() and inserting ENGINE_cleanup(); in ssl_proxy_deinit()
the crypto device gets used. I'm sure that this is not the whole story since
this only seems to affect the IMAP login.
One has to use the specific SSL-engine and the ENGINE/EVP calls (as stated in
the various articles). Is there any chance that Dovecot gets updated/patched
for this ? E.g. Like the SSLCryptoDevice setting in Apache's mod_ssl.
Regards.
Martin
Chris Hoogendyk wrote:>
> On 4/18/11 6:30 AM, Martin Preen wrote:
>> Hello,
>> I tried to find out how about to use the hardware crypto engines under
>> Solaris (Sun Fire T2000). It seems, that its not just a compilation
>> issue:
>>
>>> For operations that are to be offloaded, it is necessary to
restrict
>>> use to subset
>> > of OpenSSL functions (the EVP_ functions) and explicitly indicate
>> the use of the PKCS11
>> > engine; something like the following works for bulk ciphers (the
>> process for RSA is similar):
>>>
>>> ENGINE *e;
>>> ENGINE_load_builtin_engines();
>>> e = ENGINE_by_id("pkcs11");
>>> ENGINE_set_default_ciphers(e);
>>> EVP_CIPHER_CTX_init (&ctx);
>>> EVP_EncryptInit (&ctx, EVP_des_cbc (), key, iv);
>>> EVP_EncryptUpdate (.....);
>>
>> Since I'm not familiar with SSL programming, I wonder if it's
possible to
>> modify the dovecot 1.2.x source code. Maybe someone has already tried
>> this
>> or can give me hint.
>
> You don't want to do that.
>
> The objective is for the ssl engine to be low level and basically
> invisible to layers of application above that use it. So, build openssl
> properly and it just works for everything else.
>
> I'm not at work today, so I don't have reference to my notes. Ah,
just
> found an email I sent to my colleagues -- copied it below.
---------------------------------------------------------------
Martin Preen, Universit?t Freiburg, Institut f?r Informatik
Georges-Koehler-Allee 52, Raum EG-006, 79110 Freiburg, Germany
phone: ++49 761 203-8250 preen at informatik.uni-freiburg.de
fax: ++49 761 203-8242 swt.informatik.uni-freiburg.de/~preen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6337 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20111121/66a69671/attachment-0004.bin>
On Mon, 2011-11-21 at 10:18 +0100, Martin Preen wrote:> Hello, > after serveral tests (and reading a lot of howto's) I'm now fairly convinced > that the Solaris HW-crypto engine is not automatically used. Even when dovecot > ist compiled with the OpenSSL version provided by Solaris. > > Currently I have only a T1-CPU available for testing (Sun Fire T2000) and > after patching src/login-common/ssl-proxy-openssl.c (Dovecot 1.2.17) with > > ENGINE *e; > ENGINE_load_builtin_engines(); ENGINE_init((e=ENGINE_by_id("pkcs11")));Does "openssl engine" return this "pkcs11" string?> ENGINE_set_default_RSA(e); ENGINE_set_default_DSA(e); > ENGINE_set_default_ciphers(e); > > in ssl_proxy_init() and inserting ENGINE_cleanup(); in ssl_proxy_deinit() > the crypto device gets used. I'm sure that this is not the whole story since > this only seems to affect the IMAP login.It should work for POP3 as well, all of the SSL code is shared.> One has to use the specific SSL-engine and the ENGINE/EVP calls (as stated in > the various articles). Is there any chance that Dovecot gets updated/patched > for this ? E.g. Like the SSLCryptoDevice setting in Apache's mod_ssl.I guess I could add ssl_crypto_device setting for this. But I'll need to figure out proper ifdefs to avoid compile failures with older OpenSSL versions.