Observed issues with the FIPS sample app

Observed issues with the FIPS sample app

[Patrick Robb]

[-- Attachment #1: Type: text/plain, Size: 5190 bytes --]

Hello all,

At the UNH Community Lab, we are now running CI testing for cryptodev
validation using the FIPS sample application. In setting up testing we have
run into issues with the sample app documentation being out of date. In
places it points to dependency versions which do not work with the sample
app, and we are also seeing the sample application failing to run on some
of the supported test vectors. We hope to start a conversation about these
issues with interested community members responsible for maintaining
cryptodev functions in DPDK and the FIPS sample application. If desired, we
could produce an updated setup guide according to how we’ve set up our
environment. But, others who are more involved in developing the sample app
may want to provide their own input. We are grateful for any feedback to us
or development of the sample app which may come out of this conversation. A
synopsis of our experience using the FIPS sample app is below.


*Issues with current documentation for IPsec-mb library:*


According to the current test plan documentation for how to utilize the
DPDK FIPS Validation Application (
https://git.dpdk.org/tools/dts/tree/test_plans/fips_cryptodev_test_plan.rst
),

it is recommended that you pull from the intel-ipsec-mb github repository
and then checkout a specific commit (noted as “latest working commit”). The
commit it recommends using in this documentation is a few commits after the
version tagged “v0.50” however, when trying to build DPDK using this
version of the library, it reports that it does not support any version
older than “1.0.0”. When using the documented version of the library, you
also do not get access to the virtual crypto device that is used in the
examples on this page.


There is also the DPDK user guide for the application (
*https://doc.dpdk.org/guides/sample_app_ug/fips_validation.html*
<https://doc.dpdk.org/guides/sample_app_ug/fips_validation.html>) and this
guide does not list any of those same prerequisites, but when building DPDK
without said prerequisites, you receive the driver warning *crypto/ipsec_mb:
missing dependency, "libIPSec_MB”.* There is a different crypto device used
in the examples on this user guide (*crypto_aesni_mb*) but if you do build
the IPsec library from github, on the “0.50” version you don’t get access
to this device. However, if you instead build the IPsec library on the
latest tagged version (v1.3) you can run the sample application using the
crypto device that is mentioned on this page. Even with being able to run
the sample application on the latest version, not all supported algorithms
pass, there are a few algorithms listed as supported that return a failed
verdict.


It is unclear which steps should be followed and which parts are accurate
as it seems some pieces of each form of documentation are true while others
are outdated.


*Other things to note:*

There are other algorithms that pass on some hosts, but fail on others.
Using an ubuntu 20.04 container, on some hosts, validation of AES-GCM
algorithms works and returns a passing verdict. However, running inside the
same container on our production hosts, these algorithms fail with the
message “CipherText was not present in the TestCase.” There was recently a
*patch*
<http://mails.dpdk.org/archives/test-report/2023-February/350635.html> put
out to fix the AES-GCM validation, however we are seeing it fail to compile
with DPDK.


*All algorithm testing listed below was performed using the
“crypto_aesni_mb” virtual device on version 1.3 of the ipsec library*


*List of working algorithms*:

   -

   AES-CBC
   -

   AES-CMAC
   -

   AES-CTR
   -

   AES-GMAC
   -

   HMAC-SHA1
   -

   TDES-CBC

*List of failing algorithms*:

   -

   AES-GCM
   -

      “CipherText missing from TestCase”
      -

      This failure message is found in the verdict returned from the ACVP
      API
      -

   AES-XTS
   -

      “ACVP-AES-XTS-2.0: General exception. Contact service provider.”
      -

      This failure happens before reaching DPDK application so likely a
      NIST problem
      -

   SHA-1
   -

      “Digests do not match”
      -

      This failure message is found in the verdict returned from the ACVP
      API
      -

      Passes some test cases but fails others
      -

   SHA-256
   -

      “Digests do not match”
      -

      This failure message is found in the verdict returned from the ACVP
      API
      -

      Like SHA-1, fails some but passes others
      -

   TDES-ECB
   -

      “USER1: Failed to get capability for cdev 0”
      -

      “USER1: Error -22: test block”
      -

      These errors are encountered during the validation phase (i.e., when
      the vectors are being run through the DPDK sample application)

*Untested algorithms*:

   -

   RSA
   -

   ECDSA


-- 

Patrick Robb

Technical Service Manager

UNH InterOperability Laboratory

21 Madbury Rd, Suite 100, Durham, NH 03824

www.iol.unh.edu

[-- Attachment #2: Type: text/html, Size: 18113 bytes --]