AES-cipher offload to engine in openssl-fips

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

AES-cipher offload to engine in openssl-fips

suji

Hi,

I am unable to use AES-cipher offload to my engine even though it was registered with the proper flag (EVP_CIPH_FLAG_FIPS). I was able to use RSA, digests, and ECDSA to the engine with corresponding flags.

I am using openssl-fips-2.0.16 and openssl-1.0.2e. 

OPENSSL_FIPS is set.

I come across the code snippet in crypto/evp/evp_enc.c . In function EVP_CipherInit_ex. At start, pointer is updated with engine function and at Line number 173, In case of fips mode, function pointer gets updated to openssl function. Which means in fips mode ciphers never gets offloaded to engine?

All other functions (digest, RSA etc) , it first updates to fips function, and then engine function. Why only ciphers has this different behaviour?

Please reply.

Thanks,
Suji
Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

OpenSSL - User mailing list
  • Which means in fips mode ciphers never gets offloaded to engine?
  • All other functions (digest, RSA etc) , it first updates to fips function, and then engine function. Why only ciphers has this different behaviour?

 

That seems like a bug.  In FIPS mode you can only use the FIPS-validated code, which means that you *have* to use the OpenSSL implementation.

 

If you do not use the OpenSSL implementation, then you cannot claim to be FIPS validated, and you must get your validation for your implementation.

 

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

Walter Paley
In reply to this post by suji
To clarify here, using the OpenSSL FIPS implementation does not allow you to claim “FIPS Validated”, rather this would be “FIPS Compliant”. If you want to claim “FIPS Validated”, you must get your own validation for your implementation regardless of what you are using, OpenSSL FIPS module or otherwise.

- Walt


Walter Paley
[hidden email]
SafeLogic - FIPS 140-2 Simplified

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

suji
Thanks for the reply.

With non-fips openssl, it is possible to write my own fips-module. I
understood.

But, is it possible for me to write a fips-compliant/fips validated "dynamic
engine" with openssl-fips? Which allows me to offload "fips-compilant"
functions to my engine "dynamically"?



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

suji
The requirement here is, to offload my "engine supported fips-compliant
methods" to engine and other "fips-complaint" functions to openssl
dynamically. Here I need to use openssl-fips module I guess.  



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

OpenSSL - User mailing list
In reply to this post by suji
No.

The OpenSSL FIPS Module is not written that way. It should not be permitting any non-FIPS implementations (see Rich's email regarding a bug).

You could write your own engine, get that FIPS certified, and run it with plain, vanilla OpenSSL.

There's a design spec out for OpenSSL 3.0.0 that may allow you to have your own FIPS provider, which, I believe, would be the closest thing to what you want.

--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."


> On Feb 27, 2019, at 6:45 AM, suji <[hidden email]> wrote:
>
> Thanks for the reply.
>
> With non-fips openssl, it is possible to write my own fips-module. I
> understood.
>
> But, is it possible for me to write a fips-compliant/fips validated "dynamic
> engine" with openssl-fips? Which allows me to offload "fips-compilant"
> functions to my engine "dynamically"?
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

OpenSSL - User mailing list
In reply to this post by suji
If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation.
 

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

OpenSSL - User mailing list
On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
> If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation.
>  
>

I believe the context here is one I also mentioned in my comment on
the 3.0 draft spec:

- OpenSSL FIPS Module provides FIPS validated software implementations of
  all/most of the permitted algorithms.
- Engine provides FIPS validated (hardware?) implementations of one or
  more implementations, under a separate FIPS validation, perhaps done
  at the hardware level.
- FIPS-capable OpenSSL (outside the FIPS boundary) is somehow made to use
  both FIPS validated modules depending on various conditions (such as
  algorithm availability).  FIPS-capable OpenSSL can be changed without
  breaking the FIPS validation of the modules.
- Overall application claims FIPS compliance as all crypto is done by
  FIPS validated modules.

A hypothetical US gov example would be using a certificate on a FIPS
validated FIPS 201 PIV ID card.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

Richard Levitte - VMS Whacker-2
On Wed, 27 Feb 2019 21:55:29 +0100,
Jakob Bohm via openssl-users wrote:

>
> On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
> > If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation.
> >  
>
> I believe the context here is one I also mentioned in my comment on
> the 3.0 draft spec:
>
> - OpenSSL FIPS Module provides FIPS validated software implementations of
>   all/most of the permitted algorithms.
> - Engine provides FIPS validated (hardware?) implementations of one or
>   more implementations, under a separate FIPS validation, perhaps done
>   at the hardware level.
> - FIPS-capable OpenSSL (outside the FIPS boundary) is somehow made to use
>   both FIPS validated modules depending on various conditions (such as
>   algorithm availability).  FIPS-capable OpenSSL can be changed without
>   breaking the FIPS validation of the modules.
> - Overall application claims FIPS compliance as all crypto is done by
>   FIPS validated modules.

Side note: "FIPS-capable OpenSSL" isn't quite right.  Basically, if
libcrypto is capable of loading a dynamically loadable module, it's
"FIPS-capable", since it can load the FIPS provider module.

I see no reason why libcrypto should be able to load two
FIPS-validated modules (*) and use them both, all depending on what
algorithms and properties are desired (apart from the "fips"
property).  However, I've come to understand that those two modules
must not be made to cooperate, i.e. for a signing operation using
sha256WithRSAEncryption, it's not permitted for one module to do the
sha256 part and the other module to do the RSA calculations.

Cheers,
Richard

-----
(*) an engine module is also a module...  all that actually makes it
an OpenSSL engine is two entry points, "bind_engine" and "v_check".

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

OpenSSL - User mailing list
On 27/02/2019 22:18, Richard Levitte wrote:

> On Wed, 27 Feb 2019 21:55:29 +0100,
> Jakob Bohm via openssl-users wrote:
>> On 27/02/2019 20:59, Salz, Rich via openssl-users wrote:
>>> If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation.
>>>    
>> I believe the context here is one I also mentioned in my comment on
>> the 3.0 draft spec:
>>
>> - OpenSSL FIPS Module provides FIPS validated software implementations of
>>    all/most of the permitted algorithms.
>> - Engine provides FIPS validated (hardware?) implementations of one or
>>    more implementations, under a separate FIPS validation, perhaps done
>>    at the hardware level.
>> - FIPS-capable OpenSSL (outside the FIPS boundary) is somehow made to use
>>    both FIPS validated modules depending on various conditions (such as
>>    algorithm availability).  FIPS-capable OpenSSL can be changed without
>>    breaking the FIPS validation of the modules.
>> - Overall application claims FIPS compliance as all crypto is done by
>>    FIPS validated modules.
> Side note: "FIPS-capable OpenSSL" isn't quite right.  Basically, if
> libcrypto is capable of loading a dynamically loadable module, it's
> "FIPS-capable", since it can load the FIPS provider module.
I always understood "FIPS-capable OpenSSL" to refer specifically to an
OpenSSL compiled with the options to incorporate the FIPS canister
module, not just any OpenSSL build that might be used in FIPS compliant
applications (as that would be any OpenSSL at all).

>
> I see no reason why libcrypto should be able to load two
> FIPS-validated modules (*) and use them both, all depending on what
> algorithms and properties are desired (apart from the "fips"
> property).  However, I've come to understand that those two modules
> must not be made to cooperate, i.e. for a signing operation using
> sha256WithRSAEncryption, it's not permitted for one module to do the
> sha256 part and the other module to do the RSA calculations.
>
> Cheers,
> Richard
>
> -----
> (*) an engine module is also a module...  all that actually makes it
> an OpenSSL engine is two entry points, "bind_engine" and "v_check".
>
How does this understanding work for other applications that use a
FIPS-validated smart card (cryptographic boundary for validation is
the physical card boundary) to sign messages?  Are such applications
required to pass every message (mega)byte through the smart card
serial interface so the low speed smart card chip can do the hashing?

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

OpenSSL - User mailing list
>    I always understood "FIPS-capable OpenSSL" to refer specifically to an
    OpenSSL compiled with the options to incorporate the FIPS canister
    module, not just any OpenSSL build that might be used in FIPS compliant
    applications (as that would be any OpenSSL at all).

Yes, that is historically correct.  I don't believe the project uses the term "FIPS-capable OpenSSL" any more.  Instead, the design and such talk about a FIPS module which OpenSSL can use.

    > I see no reason why libcrypto should be able to load two
    > FIPS-validated modules (*) and use them both, all depending on what
    > algorithms and properties are desired (apart from the "fips"
    > property).

Richard made a typo here.  He means there is no reason why libcrypto should NOT be able to load two modules.

    >  However, I've come to understand that those two modules
    > must not be made to cooperate, i.e. for a signing operation using
    > sha256WithRSAEncryption, it's not permitted for one module to do the
    > sha256 part and the other module to do the RSA calculations.

I believe Richard is wrong here.  Or at least his text could be misleading. If the EVP API does the digesting with one module and then calls another module to do the RSA signing, that is okay.  If the "digest and sign" module calls out to another module *itself* that is probably not okay.

 

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

Richard Levitte - VMS Whacker-2
On Wed, 27 Feb 2019 22:54:41 +0100,
Salz, Rich via openssl-users wrote:
>
> >    I always understood "FIPS-capable OpenSSL" to refer specifically to an
>     OpenSSL compiled with the options to incorporate the FIPS canister
>     module, not just any OpenSSL build that might be used in FIPS compliant
>     applications (as that would be any OpenSSL at all).
>
> Yes, that is historically correct.  I don't believe the project uses
> the term "FIPS-capable OpenSSL" any more.  Instead, the design and
> such talk about a FIPS module which OpenSSL can use.

Correct.

>     > I see no reason why libcrypto should be able to load two
>     > FIPS-validated modules (*) and use them both, all depending on what
>     > algorithms and properties are desired (apart from the "fips"
>     > property).
>
> Richard made a typo here.  He means there is no reason why libcrypto
> should NOT be able to load two modules.

You got it right.  Sorry for the confusion I caused.

>     >  However, I've come to understand that those two modules
>     > must not be made to cooperate, i.e. for a signing operation using
>     > sha256WithRSAEncryption, it's not permitted for one module to do the
>     > sha256 part and the other module to do the RSA calculations.
>
> I believe Richard is wrong here.  Or at least his text could be
> misleading. If the EVP API does the digesting with one module and
> then calls another module to do the RSA signing, that is okay.

Huh?  From the design document, section "Example dynamic views of
algorithm selection", after the second diagram:

    An EVP_DigestSign* operation is more complicated because it
    involves two algorithms: a signing algorithm, and a digest
    algorithm. In general those two algorithms may come from different
    providers or the same one. In the case of the FIPS module the
    algorithms must both come from the same FIPS module provider. The
    operation will fail if an attempt is made to do otherwise.

Ref: https://www.openssl.org/docs/OpenSSL300Design.html#example-dynamic-views-of-algorithm-selection

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

AW: AES-cipher offload to engine in openssl-fips

Dr. Matthias St. Pierre

> -----Ursprüngliche Nachricht-----
> > >    I always understood "FIPS-capable OpenSSL" to refer specifically to an
> >     OpenSSL compiled with the options to incorporate the FIPS canister
> >     module, not just any OpenSSL build that might be used in FIPS compliant
> >     applications (as that would be any OpenSSL at all).
> >
> > Yes, that is historically correct.  I don't believe the project uses
> > the term "FIPS-capable OpenSSL" any more.  Instead, the design and
> > such talk about a FIPS module which OpenSSL can use.
>
> Correct.

I disagree: The term "FIPS Capable OpenSSL" is a technical term from the OpenSSL FIPS 2.0
User Guide (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) and has a very clear and
precise meaning:

It refers to an OpenSSL 1.0.2 (or 1.0.1) library configured and built with `./configure fips ...`
in order to integrate the FIPS Object Module. Until FIPS 3.0 has been released and FIPS 2.0
is history, we should stick to that definition and not confuse FIPS users by reinterpreting it
or pretend that it is not used anymore or has a different meaning nowadays.

Matthias

--

You find the details in Sections 4.2.3 resp. 4.3.3 of  https://www.openssl.org/docs/fips/UserGuide-2.0.pdf.

    4.2.3 Building a FIPS Capable OpenSSL  (Unix/Linux)
    4.3.3 Building a FIPS Capable OpenSSL  (Windows)

Here a brief excerpt:

Once the validated FIPS Object Module has been generated it is usually combined with an
OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1 or 1.0.2 release
can be used for this purpose. The commands
        ./config fips <...other options...>
        make <...options...>
        make install
will build and install the new OpenSSL without overwriting the validated FIPS Object Module
files. The FIPSDIR environment variable or the --with­fipsdir command line option can
be used to explicitly reference the location of the FIPS Object Module (fipscanister.o).

The combination of the validated FIPS Object Module plus an OpenSSL distribution built in this
way is referred to as a FIPS capable OpenSSL, as it can be used either as a drop-in replacement for
a non-FIPS OpenSSL or for use in generating FIPS mode applications.


Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

Richard Levitte - VMS Whacker-2
Uhm, I'm confused. I thought we were talking about 3.0?

"Dr. Matthias St. Pierre" <[hidden email]> skrev: (27 februari 2019 23:34:23 CET)

>
>> -----Ursprüngliche Nachricht-----
>> > >    I always understood "FIPS-capable OpenSSL" to refer
>specifically to an
>> >     OpenSSL compiled with the options to incorporate the FIPS
>canister
>> >     module, not just any OpenSSL build that might be used in FIPS
>compliant
>> >     applications (as that would be any OpenSSL at all).
>> >
>> > Yes, that is historically correct.  I don't believe the project
>uses
>> > the term "FIPS-capable OpenSSL" any more.  Instead, the design and
>> > such talk about a FIPS module which OpenSSL can use.
>>
>> Correct.
>
>I disagree: The term "FIPS Capable OpenSSL" is a technical term from
>the OpenSSL FIPS 2.0
>User Guide (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) and
>has a very clear and
>precise meaning:
>
>It refers to an OpenSSL 1.0.2 (or 1.0.1) library configured and built
>with `./configure fips ...`
>in order to integrate the FIPS Object Module. Until FIPS 3.0 has been
>released and FIPS 2.0
>is history, we should stick to that definition and not confuse FIPS
>users by reinterpreting it
>or pretend that it is not used anymore or has a different meaning
>nowadays.
>
>Matthias
>
>--
>
>You find the details in Sections 4.2.3 resp. 4.3.3 of
>https://www.openssl.org/docs/fips/UserGuide-2.0.pdf.
>
>    4.2.3 Building a FIPS Capable OpenSSL  (Unix/Linux)
>    4.3.3 Building a FIPS Capable OpenSSL  (Windows)
>
>Here a brief excerpt:
>
>Once the validated FIPS Object Module has been generated it is usually
>combined with an
>OpenSSL distribution in order to provide the standard OpenSSL API. Any
>1.0.1 or 1.0.2 release
>can be used for this purpose. The commands
> ./config fips <...other options...>
> make <...options...>
> make install
>will build and install the new OpenSSL without overwriting the
>validated FIPS Object Module
>files. The FIPSDIR environment variable or the --with­fipsdir command
>line option can
>be used to explicitly reference the location of the FIPS Object Module
>(fipscanister.o).
>
>The combination of the validated FIPS Object Module plus an OpenSSL
>distribution built in this
>way is referred to as a FIPS capable OpenSSL, as it can be used either
>as a drop-in replacement for
>a non-FIPS OpenSSL or for use in generating FIPS mode applications.

--
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

OpenSSL - User mailing list
In reply to this post by Richard Levitte - VMS Whacker-2
>    Huh?  From the design document, section "Example dynamic views of
    algorithm selection", after the second diagram:
   
        An EVP_DigestSign* operation is more complicated because it
        involves two algorithms: a signing algorithm, and a digest
        algorithm. In general those two algorithms may come from different
        providers or the same one. In the case of the FIPS module the
        algorithms must both come from the same FIPS module provider. The
        operation will fail if an attempt is made to do otherwise.
 
There are two options.  First, the application does the digest and sign as two separate things.  Second, the provider implementing digestSign has to be validated to use the other FIPS module.




Reply | Threaded
Open this post in threaded view
|

AW: AES-cipher offload to engine in openssl-fips

Dr. Matthias St. Pierre
In reply to this post by Richard Levitte - VMS Whacker-2

> Uhm, I'm confused. I thought we were talking about 3.0?

Well, the original post started at FIPS 2.0:

  > I am using openssl-fips-2.0.16 and openssl-1.0.2e.
  https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html

But it seems like the discussion in the thread has drifted a little towards the FIPS 3.0 future,
which explains our mutual confusion. For that reason it is even more important that we don't
use legacy terms like "FIPS capable" in the context of FIPS 3.0 and stick to "FIPS Providers"
(or whatever correct new terms are; I'm currently not 100% up-to-date) instead.

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

Richard Levitte - VMS Whacker-2
In reply to this post by OpenSSL - User mailing list
On Thu, 28 Feb 2019 00:17:13 +0100,
Salz, Rich wrote:

>
> >    Huh?  From the design document, section "Example dynamic views of
>     algorithm selection", after the second diagram:
>    
>         An EVP_DigestSign* operation is more complicated because it
>         involves two algorithms: a signing algorithm, and a digest
>         algorithm. In general those two algorithms may come from different
>         providers or the same one. In the case of the FIPS module the
>         algorithms must both come from the same FIPS module provider. The
>         operation will fail if an attempt is made to do otherwise.
>  
> There are two options.  First, the application does the digest and
> sign as two separate things.

My memory is a foggy surrounding that scenario, so I might be wrong,
but I think it was argued that this was invalid use from a FIPS
perspective.  Now, we can't actually stop any application from doing
this, sure!  But...

> Second, the provider implementing digestSign has to be validated to
> use the other FIPS module.

Yes, and this is, as far as I remember, a "combined FIPS module" (I
don't remember the exact terminology, sorry) which is supposed to be
validated together and present itself to libcrypto as one provider,
not two.

However, what you wrote earlier was this:

> If the EVP API does the digesting with one module and then calls
> another module to do the RSA signing, that is okay.

That suggests to me that libcrypto could "magically" combine two
different FIPS providers, which would be none of the two options
mentioned above.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: AW: AES-cipher offload to engine in openssl-fips

Richard Levitte - VMS Whacker-2
In reply to this post by Dr. Matthias St. Pierre
On Thu, 28 Feb 2019 00:51:24 +0100,
Dr. Matthias St. Pierre wrote:
>
>
> > Uhm, I'm confused. I thought we were talking about 3.0?
>
> Well, the original post started at FIPS 2.0:
>
>   > I am using openssl-fips-2.0.16 and openssl-1.0.2e.
>   https://mta.openssl.org/pipermail/openssl-users/2019-February/009919.html

Yes, it did...  and then evolved, as threads on the Internet often do
(or for that matter, in physical life too).

> But it seems like the discussion in the thread has drifted a little
> towards the FIPS 3.0 future, which explains our mutual confusion.

Yup :-)

> For that reason it is even more important that we don't use legacy
> terms like "FIPS capable" in the context of FIPS 3.0 and stick to
> "FIPS Providers" (or whatever correct new terms are; I'm currently
> not 100% up-to-date) instead.

Cool, we agree then :-)

"FIPS provider" is what we use within the team, or sometimes "FIPS
provider module".  They are synonymous, but the latter is more
precise.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

Matt Caswell-2
In reply to this post by Richard Levitte - VMS Whacker-2


On 27/02/2019 22:20, Richard Levitte wrote:

>> I believe Richard is wrong here.  Or at least his text could be
>> misleading. If the EVP API does the digesting with one module and
>> then calls another module to do the RSA signing, that is okay.
>
> Huh?  From the design document, section "Example dynamic views of
> algorithm selection", after the second diagram:
>
>     An EVP_DigestSign* operation is more complicated because it
>     involves two algorithms: a signing algorithm, and a digest
>     algorithm. In general those two algorithms may come from different
>     providers or the same one. In the case of the FIPS module the
>     algorithms must both come from the same FIPS module provider. The
>     operation will fail if an attempt is made to do otherwise.
>
> Ref: https://www.openssl.org/docs/OpenSSL300Design.html#example-dynamic-views-of-algorithm-selection

Also from the design document:

"Once in a FIPS module provided algorithm, we must remain within the FIPS module
for any other cryptographic operations. It would be allowed by the FIPS rules
for one FIPS module to use another FIPS module. However, for the purposes of the
3.0 design we are making the simplifying assumption that we will not allow this.
For example an EVP_DigestSign* implementation uses both a signing algorithm and
digest algorithm. We will not allow one of those algorithms to come from the
FIPS module, and one to come from some other provider."

Note the the text Richard quotes above talks about *the* FIPS module - i.e. it
is in specific reference to our FIPS module. It is not making a general
statement about the FIPS rules. In general, my understanding is that it is ok
for one FIPS module to do signing and another one to do digesting. However we
are making the simplifying assumption that in *our* FIPS module we will not
allow this.

Matt

Reply | Threaded
Open this post in threaded view
|

Re: AES-cipher offload to engine in openssl-fips

suji
From https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

I got these lines

"OpenSSL provides mechanisms for interfacing with external cryptographic
devices, such as
accelerator cards, via “ENGINES.”  This mechanism is not disabled in FIPS
mode.  In general, if a
FIPS validated cryptographic device is used with OpenSSL in FIPS mode so
that all cryptographic
operations are performed either by the device or the FIPS Object Module,
then the result is still
FIPS validated cryptography.
However, if any cryptographic operations are performed by a non-FIPS
validated device, the result
is use of non-validated cryptography.  It is the responsibility of the
application developer to ensure
that ENGINES used during FIPS mode of operation are also FIPS validated.".

Then coming back to my first question, I should be able to offload
AES_Ciphers to my engine right? Then can I assume that either Its a bug in
openssl-1.0.2 versions or I have missed some flags/something?




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
12