#4039 p11_child::sign_data() function implementation is not FIPS140 compliant
Closed: Fixed 2 years ago by jhrozek. Opened 2 years ago by sbose.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 1711318

There are two problems with implementation of p11_child::sign_data() function
in regards of FIPS140 compliance:

(1) Usage of SHA-1.

SHA-1 is used in a signature for integrity protection which means it is a
sensitive use. Thus it falls under FIPS requirements.
Also the way it is used can't be considered "used in HMAC".
Thus code must be reworked to avoid usage of SHA-1 whenever possible, i.e.
implementation should lookup list of supported by Smart Card alternatives and
choose more modern/FIPS approved option if available.

For Smart Cards that do not support approved alternatives this change will make
impossible its usage in FIPS mode. This is expected behaviour.

Presumably "manual" hashing in case of ECC key may be dropped at all but (2)
must be taken in to account.

(2) The way signature verification is implemented breaks "No Algorithm
decomposition" rule from "FIPS140 Compliance Checklist":
"When applying signatures do not Hash the content on your own and then call the
raw signature API, instead call the API that compute hash and signature in one
shot by reading the whole message"

Metadata Update from @sbose:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1711318

2 years ago


I opened https://github.com/SSSD/sssd/pull/843 for this. I think the RSA side should be fine.

I'm a bit undecided about EC keys and (2). So far only the draft of version 3.0 http://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/csprd01/pkcs11-curr-v3.0-csprd01.html defines ECDSA mechanisms with better hashes than SHA1. The current version 2.40 http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/os/pkcs11-curr-v2.40-os.html only knows about plain ECDSA and ECDSA with SHA1. Since p11_child currently only uses the two step method (hash in software and ECDSA on the card) when generating the signature and not when verifying it I hope this might be ok.


Metadata Update from @sbose:
- Issue assigned to sbose

2 years ago

Metadata Update from @sbose:
- Custom field patch adjusted to on

2 years ago

Since p11_child currently only uses the two step method (hash in software and ECDSA on the card) when generating the signature

For sake of history:
As it was discussed with Sumit, strictly speaking this step ("hash in software") is not required at all (as there is no difference if card signs random data or hash of random data). So this step is only done to have a similar flow of execution with different key types. But with replacement of sha1 with sha512 this step doesn't hurt either.

and not when verifying it I hope this might be ok.

I tend to agree.

Metadata Update from @atikhonov:
- Issue tagged with: PR

2 years ago

Commit 7f0a8f5 relates to this ticket

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 2.3

2 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/5008

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.