Non-FIPS enabled HSM fails with 500 error on encrypt

Bug #1684997 reported by Arun Kant
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Barbican
Fix Released
High
Arun Kant

Bug Description

We have seen regression on PKCS11 plugin when deployment moved from mitaka release to newton release.

Following error is generated during encrypt operation with PKCS11 plugin backend. This functionality was working with mitaka code base and start happening with newton release onwards.

The error appears to be related to this change https://review.openstack.org/#/c/347434/ which was added to address bug : https://bugs.launchpad.net/barbican/+bug/1606591 . As per comments, IV generation was made *optional* but there is no supporting logic to enable/disable IV generation. Currently code has been modified expecting that HSM will always generate IV which was not the behavior in mitaka release and that's why existing deployment fails when try to upgrade to newer release.

As per following error stack trace, error is same as previous bug mentioned but now difference is that its happening with HSM which does not have FIPS enabled. We should support both configuration via some configuration flag.

(sqlalchemy.engine.base.Engine): 2017-04-20 16:52:06,351 INFO base _execute_context SELECT kek_data.id AS kek_data_id, kek_data.created_at AS kek_data_created_at, kek_data.updated_at AS kek_data_updated_at, kek_data.deleted_at AS kek_data_deleted_at, kek_data.deleted AS kek_data_deleted, kek_data.status AS kek_data_status, kek_data.plugin_name AS kek_data_plugin_name, kek_data.kek_label AS kek_data_kek_label, kek_data.project_id AS kek_data_project_id, kek_data.active AS kek_data_active, kek_data.bind_completed AS kek_data_bind_completed, kek_data.algorithm AS kek_data_algorithm, kek_data.bit_length AS kek_data_bit_length, kek_data.mode AS kek_data_mode, kek_data.plugin_meta AS kek_data_plugin_meta
FROM kek_data
WHERE kek_data.active = true AND kek_data.deleted = false AND kek_data.project_id = %s AND kek_data.plugin_name = %s
(sqlalchemy.engine.base.Engine): 2017-04-20 16:52:06,351 INFO base _execute_context ('e0371c1c-b571-428b-852e-0ec388a20dae', 'barbican.plugin.crypto.p11_crypto.P11CryptoPlugin')
(sqlalchemy.engine.base.Engine): 2017-04-20 16:52:06,356 INFO base _execute_context INSERT INTO kek_data (id, created_at, updated_at, deleted_at, deleted, status, plugin_name, kek_label, project_id, active, bind_completed, algorithm, bit_length, mode, plugin_meta) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
(sqlalchemy.engine.base.Engine): 2017-04-20 16:52:06,357 INFO base _execute_context ('2735b579-272d-498b-913b-6772e3b68830', datetime.datetime(2017, 4, 20, 16, 52, 6, 353947), datetime.datetime(2017, 4, 20, 16, 52, 6, 353947), None, 0, 'ACTIVE', 'barbican.plugin.crypto.p11_crypto.P11CryptoPlugin', 'project-7a818536ce464d7f966d4b3d1e31a54f-key-ce4f5e49-b1be-4ae8-825f-55b49ba632e1', 'e0371c1c-b571-428b-852e-0ec388a20dae', 1, 0, None, None, None, None)
(sqlalchemy.engine.base.Engine): 2017-04-20 16:52:13,807 INFO base _execute_context UPDATE kek_data SET updated_at=%s, bind_completed=%s, algorithm=%s, bit_length=%s, mode=%s, plugin_meta=%s WHERE kek_data.id = %s
(sqlalchemy.engine.base.Engine): 2017-04-20 16:52:13,807 INFO base _execute_context (datetime.datetime(2017, 4, 20, 16, 52, 13, 805428), 1, 'AES', 256, 'CBC', '{"mkek_label":"hlm_barbican_qa_pkcs_mkek_april20","hmac_label":"hlm_barbican_qa_pkcs_hmac_april20","wrapped_key":"6ebLRwhIJ4cIZHYTNvcFaqE3tfpYuyuZ7LSe0wOFrbN77AfPjEDUMxH2AWHVSYlU","hmac":"IXxWSjATx5gae2V+sVdfm4iNV3p4ik8ecVvnawVr+Eo=","iv":"Sox3M0hl0hjpZJPNhoMmEg=="}', '2735b579-272d-498b-913b-6772e3b68830')
(barbican.plugin.crypto.p11_crypto): 2017-04-20 16:52:14,792 WARNING p11_crypto _call_pkcs11 Reinitializing PKCS#11 library: HSM returned response code: 0x71L CKR_MECHANISM_PARAM_INVALID
(barbican.api.controllers): 2017-04-20 16:52:24,160 ERROR __init__ handler Secret creation failure seen - please contact site administrator.
Traceback (most recent call last):
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/api/controllers/__init__.py", line 103, in handler
    return fn(inst, *args, **kwargs)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/api/controllers/__init__.py", line 89, in enforcer
    return fn(inst, *args, **kwargs)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/api/controllers/__init__.py", line 155, in content_types_enforcer
    return fn(inst, *args, **kwargs)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/api/controllers/secrets.py", line 433, in on_post
    transport_key_id=data.get('transport_key_id'))
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/resources.py", line 109, in store_secret
    secret_model, project_model)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/resources.py", line 279, in _store_secret_using_plugin
    secret_metadata = store_plugin.store_secret(secret_dto, context)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/store_crypto.py", line 97, in store_secret
    encrypt_dto, kek_meta_dto, context.project_model.external_id
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/crypto/p11_crypto.py", line 115, in encrypt
    project_id)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/crypto/p11_crypto.py", line 150, in _call_pkcs11
    return func(*args, **kwargs)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/crypto/p11_crypto.py", line 157, in _encrypt
    kek, encrypt_dto.unencrypted, session
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/crypto/pkcs11.py", line 402, in encrypt
    self._check_error(rv)
  File "/opt/stack/service/barbican-api/venv/lib/python2.7/site-packages/barbican/plugin/crypto/pkcs11.py", line 576, in _check_error
    "HSM returned response code: {code}").format(code=hex_code))
P11CryptoPluginException: HSM returned response code: 0x71L CKR_MECHANISM_PARAM_INVALID
(sqlalchemy.engine.base.Engine): 2017-04-20 16:52:24,163 INFO base _rollback_impl ROLLBACK
(barbican.api.middleware.context): 2017-04-20 16:52:24,170 INFO context process_response Processed request: 500 Internal Server Error - POST https://192.168.245.5:9311/v1/secrets/
Show more

Changed in barbican:
status: New → In Progress
importance: Undecided → High
milestone: none → pike-2
assignee: nobody → Arun Kant (arunkant-uws)
Revision history for this message
Dave McCowan (dave-mccowan) wrote :

Does this need to be backported to Ocata and Newton?

Revision history for this message
Arun Kant (arukant) wrote :

I believe that will be right approach. We have introduced similar local patch internally to address in newton branch. Ideally better approach is to do backport as it broke PKCS11 plugin usage for HSM used in non-FIPS (FIPS not enabled) mode.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to barbican (master)

Reviewed: https://review.openstack.org/458925
Committed: https://git.openstack.org/cgit/openstack/barbican/commit/?id=a29e120965aa9fd148a9ffdafa99f74f4f33756b
Submitter: Jenkins
Branch: master

commit a29e120965aa9fd148a9ffdafa99f74f4f33756b
Author: Arun Kant <email address hidden>
Date: Fri Apr 21 10:46:58 2017 -0700

    Making iv generation configurable for pkcs11 plugin

    Added configuration flag to enable or disable iv generation as part of
    pkcs11 plugin logic.

    In setup where HSM do not have FIPS enabled, in that case pkcs11 plugin
    is expected to provide iv (initialization vector) for encrypt call. In
    setup where HSM with FIPS enabled, HSM is going to generate iv and do
    not need it from plugin side. So logic is updated to generate iv and
    read returned data accordignly.

    By default, flag is kept false to match existing behavior.

    Closes-Bug: #1684997

    Change-Id: Ic18d86861a3e51a4370f14c8f7eb39b3f30db2dc

Changed in barbican:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/barbican 5.0.0.0b2

This issue was fixed in the openstack/barbican 5.0.0.0b2 development milestone.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.