add support for openssl chil engine

Reported by Eddie Garcia on 2011-01-27
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eCryptfs
Wishlist
Unassigned

Bug Description

We are an ecryptfs user and would like to use the ncipher hardware security module with ecryptfs. We would like to achieve this with the openssl key module, we have a working version of our key module with chil and openssl. We would like to see the openssl key module extended to generically support any openssl engine.

Eddie Garcia (edygarcia) wrote :

Attached is the patch file that will activate the openssl chil engine (see http://www.openssl.org/docs/crypto/engine.html ), what is missing is a switch to pass in the engine id to overide or leave the default openssl engine on.

Dustin Kirkland  (kirkland) wrote :

Thanks for the bug report and the working code.

I'm marking this bug Triaged and Wishlist, as we work our way through this and into the upstream tree.

As you mentioned in Comment #1, it would be better to pass in the engine ID to the main openssl module, and dynamically handle the initialization etc.

Let's talk about that with Tyler in IRC, and we'll get a workable version of this merged ASAP.

Thanks!

Changed in ecryptfs:
status: New → Triaged
importance: Undecided → Wishlist
Tyler Hicks (tyhicks) wrote :

Thanks Eddie - I agree that it would be nice to allow the user to specify which engine to use, but after reading the engine(3ssl) man page, I'm wondering if there's an easier way. The patch that Eddie attached follows what is laid out in "Using a specific ENGINE implementation".

Eddie, have you tried the approach in "Automatically using builtin ENGINE implementations"?

We're already calling ENGINE_load_builtin_engines(). If you call ENGINE_register_all_complete() right after, do you automatically pick up the chil engine?

Hi Tyler,

I have tested the "Automatically using built in ENGINE implementations"
and what happens is that since both the default openssl and chil engines
are loaded and both support the RSA algorithms the crypto calls will
always use the default engine. I did not try to remove the default
openssl engine libraries as that would break other applications using
default openssl engine like Apache mod_ssl.

I could not find an easier way and believe me I tried to find it. For
the ecryptfs key mod openssl to specify which engine to use, the "Using
specific ENGINE implementation" approach is the only one that worked.
The piece that is missing is how to pass in the engine id to the init
method and remove the hardcoded one.

I would be happy to do a quick validation and test any suggestions, I
have the chil module to test.

-Eddie

On 1/27/11 9:55 PM, Tyler Hicks wrote:
> Thanks Eddie - I agree that it would be nice to allow the user to
> specify which engine to use, but after reading the engine(3ssl) man
> page, I'm wondering if there's an easier way. The patch that Eddie
> attached follows what is laid out in "Using a specific ENGINE
> implementation".
>
> Eddie, have you tried the approach in "Automatically using builtin
> ENGINE implementations"?
>
> We're already calling ENGINE_load_builtin_engines(). If you call
> ENGINE_register_all_complete() right after, do you automatically pick up
> the chil engine?
>

--
Eddie Garcia
Director of Development
Gazzang, Inc.
512.574.7311

www.gazzang.com

Tyler Hicks (tyhicks) wrote :

On Fri Jan 28, 2011 at 04:32:40AM -0000, Eddie Garcia <email address hidden> wrote:
> I have tested the "Automatically using built in ENGINE implementations"
> and what happens is that since both the default openssl and chil engines
> are loaded and both support the RSA algorithms the crypto calls will
> always use the default engine.

I was worried about that. I didn't see a good explanation of how engine
priority was determined. I wonder if it could be done through the
openssl.cnf?

Either way, I'm definitely open to having a user selectable engine. It
would probably be best if the user is asked if they want to select an
engine. If so, cycle through the list of engines with
ENGINE_get_{first,next}(), using ENGINE_get_name() to build a list of
engine_ids to present to the user. Then, pass the user selected
engine_id on to the code that you already have.

Let me know if that sounds reasonable to you.

Eddie Garcia (edygarcia) wrote :

I did try different settings in openssl.cnf with no luck, additionally
it would also conflict with other apps using the default openssl engine.

Looping through first, next, getname would be good for users, and a way
to pass in the engine id would be needed as well for non interactive setup.

The different points where we would see the engine id selection would be:
     ecryptfs-manager
     mount ecryptfs
     ecryptfsd

All these invoke the key_mod init in my experience.

On 1/27/11 11:29 PM, Tyler Hicks wrote:
> On Fri Jan 28, 2011 at 04:32:40AM -0000, Eddie Garcia<email address hidden> wrote:
>> I have tested the "Automatically using built in ENGINE implementations"
>> and what happens is that since both the default openssl and chil engines
>> are loaded and both support the RSA algorithms the crypto calls will
>> always use the default engine.
> I was worried about that. I didn't see a good explanation of how engine
> priority was determined. I wonder if it could be done through the
> openssl.cnf?
>
> Either way, I'm definitely open to having a user selectable engine. It
> would probably be best if the user is asked if they want to select an
> engine. If so, cycle through the list of engines with
> ENGINE_get_{first,next}(), using ENGINE_get_name() to build a list of
> engine_ids to present to the user. Then, pass the user selected
> engine_id on to the code that you already have.
>
> Let me know if that sounds reasonable to you.
>

--
Eddie Garcia
Director of Development
Gazzang, Inc.
512.574.7311

www.gazzang.com

Tyler Hicks (tyhicks) wrote :

Hey Gazzangers (?), I take it that interest in this has waned and no one is working on an upstream-worthy patch. I'm marking this is won't fix but feel free to reopen it if development starts back up on this feature.

Changed in ecryptfs:
status: Triaged → Won't Fix
Sergio Peña (sergio-pena) wrote :

Hi Tyler.

We no longer make use of /dev/ecryptfs device nor the Openssl feature.

We will open this bug if we find a use in the future.
Thanks for the reminder.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers