Hi Jack,

I followed the steps in https://bugzilla.redhat.com/show_bug.cgi?id=1186896#c31 using SCP01 card. Format, Enroll, applet upgrade/downgrade and key change were successful.

I tested format and enrollment using SCP03 v7 card, for and enroll were successful but noticed the following log messages for TKS

0.http-bio-23443-exec-5 - [14/Sep/2017:15:48:58 EDT] [14] [6] [AuditEvent=COMPUTE_SESSION_KEY_REQUEST][CUID_encoded=#00#05#00#45#A7#02#00#1F#00#07][KDD_encoded=#00#00#04#47#00#1F#00#07#A7#02][Outcome=Success][AgentID=TPS-nocp1.idm.lab.eng.rdu2.redhat.com-25443] TKS Compute session key request
0.http-bio-23443-exec-5 - [14/Sep/2017:15:48:58 EDT] [14] [6] [AuditEvent=COMPUTE_SESSION_KEY_REQUEST_PROCESSED_SUCCESS][CUID_decoded=00050045A702001F0007][KDD_decoded=00000447001F0007A702][Outcome=Success][status=0][AgentID=TPS-nocp1.idm.lab.eng.rdu2.redhat.com-25443][IsCryptoValidate=true][IsServerSideKeygen=true][SelectedToken=Internal Key Storage Token][KeyNickName=#01#03#70][TKSKeyset=defKeySet][KeyInfo_KeyVersion=0x1][NistSP800_108KdfOnKeyVersion={11}][NistSP800_108KdfUseCuidAsKdd={12}] TKS Compute session key request processed successfully

I shall attach the corresponding debug log messages for TKS.

I am yet to test using SCP03 v6 card.

Created attachment 1326187 [details]
TKS debug log

Roshni:

I"m not sure what is wrong there? Which part of the log should I call out as unusual? I will keep the need info flag open until you get what you need.

The main thrust of my test was to determine if the hmac secret key generated using the hsm tools, was still working in the nistpsp800 case for the scp01 token. In scp03, the master key will be either des3 for sc 6 or aes for sc 7. We already know we have a sc 7 hsm problem in progress.

Looks like something is missing here [NistSP800_108KdfOnKeyVersion={11}][NistSP800_108KdfUseCuidAsKdd={12}](In reply to Jack Magne from comment #5)
> Roshni:
> 
> I"m not sure what is wrong there? Which part of the log should I call out as
> unusual? I will keep the need info flag open until you get what you need.

Looks like some information is missing her [NistSP800_108KdfOnKeyVersion={11}][NistSP800_108KdfUseCuidAsKdd={12}]
> 
> The main thrust of my test was to determine if the hmac secret key generated
> using the hsm tools, was still working in the nistpsp800 case for the scp01
> token. In scp03, the master key will be either des3 for sc 6 or aes for sc
> 7. We already know we have a sc 7 hsm problem in progress.
Could you comfirm if any other additional testing is required apart from https://bugzilla.redhat.com/show_bug.cgi?id=1186896#c31 and also comment 30 of the bug?

OK:

1. The odd logging display, though probably wrong, should have nothing to do with this issue. We can file a separate one if we like.

2. Yes. my main concern was the hmac master key on hsm issue, so, great that test along with the other sanity testing that seemed to have happened, should be quite sufficient. thanks,jack

(In reply to Jack Magne from comment #7)
> OK:
> 
> 1. The odd logging display, though probably wrong, should have nothing to do
> with this issue. We can file a separate one if we like.

https://bugzilla.redhat.com/show_bug.cgi?id=1497347

Jack,

I was trying out keychange operation using SCP03 v6 card and when 

tks.defKeySet.nistSP800-108KdfOnKeyVersion=00
tks.defKeySet.nistSP800-108KdfUseCuidAsKdd=true

were set in TKS CS.cfg. I see a failure. Attaching the TKS and TPS debug logs and the respective CS.cfg. Please let me know if anything is wrong in the configuration.

Created attachment 1333796 [details]
TKS CS.cfg

Created attachment 1333797 [details]
TPS CS.cfg

Created attachment 1333798 [details]
TKS debug log

Created attachment 1333799 [details]
TPS debug log

OK, will take a look.

HI:

OK, I took a look, I can't tell from the trace exactly why it failed, but I would wonder if you have tested it out with the default values for the following:

tks.defKeySet.nistSP800-108KdfOnKeyVersion=00
tks.defKeySet.nistSP800-108KdfUseCuidAsKdd=true

???


If that has been proven to work this might be some other issue. Also the reason for this kind of testing for this bug was to make sure that nistSP800 works ok on the scp01 cards with the hmac master key installed on the hsm.



Just for info also, scp03 has it's own AES_CMAC based kdf, which should not be affected by those sp800 related params.


Conclusion:

If your issue works with default params for the above, we should be ok on the gnd v6 card.

If we find something else going on, we can create a new bug of some kind to be determined.

thanks,
jack

[root@nocp1 alias]# rpm -qi jss
Name        : jss
Version     : 4.4.0
Release     : 8.el7_4
Architecture: x86_64
Install Date: Thu 14 Sep 2017 02:50:56 PM EDT
Group       : System Environment/Libraries
Size        : 1033434
License     : MPLv1.1 or GPLv2+ or LGPLv2+
Signature   : (none)
Source RPM  : jss-4.4.0-8.el7_4.src.rpm
Build Date  : Tue 12 Sep 2017 01:06:15 PM EDT
Build Host  : x86-020.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://www.mozilla.org/projects/security/pki/jss/
Summary     : Java Security Services (JSS)


Verified using SCP01 smartcard tokens as explained in https://bugzilla.redhat.com/show_bug.cgi?id=1488846#c3

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:3300