Change to CAC/PIV II regression?

[seanenck]

Problem Description

I'm using opensc-git (archlinux) which is going to be updated whenever there are commits. Between about August 10th (last working build) and August 22nd, I've noticed (what I consider to be) a regression. My CAC card now requires me to enumerate explicitly to use card_drivers = cac; in my opensc.conf where-as before it did not. Before I changed this I noticed the prompt in firefox had switched from prompting about the PIN for my card's 'signature' (e.g. LAST.FIRST.M.ID...) to just a generic 'PIV_II' request. Firefox would prompt once and not proceed (no more prompts, no cert selection, etc.)

Namely: Has a recent commit (last week or 2) prompted a change that would require me to enumerate the cac driver specifically?

Info (for reference)

> opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             Alcor Micro AU9560 00 00

> opensc-tool -n
Using reader with a card: Alcor Micro AU9560 00 00
Common Access Card (CAC)

This is my config file, the card_drivers is obviously new, everything "just worked" before:

app default {
    card_drivers = cac;
	# debug = 3;
	# debug_file = opensc-debug.txt
	framework pkcs15 {
		# use_file_caching = true;
	}
}

Proposed Resolution

I was able to fix this by using card_drivers = cac; as mentioned above

Steps to reproduce

I can reliably reproduce this, I don't know if this is CAC specific or not. If there is a change or any code changes that need to be tested, I am happy to test them (if this is an issue).

Logs

I can provide logs based on analysis of someone with more insight as to whether this is an actual regression or expected change in behavior

[frankmorgner]

What's the output of opensc-tool -n without specifiying card_drivers = cac;?

@Jakuje, can you confirm this problem?

[seanenck]

My apologies, I should have realized that, without cac specified:

> opensc-tool -n
Using reader with a card: Alcor Micro AU9560 00 00
Personal Identity Verification Card

[frankmorgner]

could you paste the output of opensc-tool -n -vvv, when the PIV card is wrongly detected?

[seanenck]

https://gist.github.com/enckse/ccb04a38911b777d68f5586ad228aebf

stdout was still:

Using reader with a card: Alcor Micro AU9560 00 00
Personal Identity Verification Card

[Jakuje]

It looks like this is a dual PIV/CAC card and there was something changed in the PIV driver detection with the merge of the fixes from fuzzing.

The cards I have access (quite older pieces) are now detected as CACeven though there is supposed to be PIV endpoint (at least I think they were detected as PIV), which has a precedence for the recognition. This sounds like opposite issue

Could you try to use git-bisect to find out which commit introduces the change for you?

[seanenck]

Yes, I will do that and let you know what I find

[dengert]

Do you have a opensc-debug.log from when it was working?

Did you have any changes in the previous opensc.conf?

[seanenck]

@dengert - not currently but I could rollback and produce one. I made no changes to my config between this working and not working

I was able to do some minor testing:

commit	note
83f45cd	builds, regression has happened
ffe38fd	build errors
360e95d	build errors
8fe377e	build errors
f66ceab	last working build, everything works normally

build errors appeared to be:

card-setcos.c: In function ‘parse_sec_attr_44’:
card-setcos.c:812:13: error: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Werror=sign-compare]
     if (len < 1+iACLen)
             ^
card-setcos.c:833:13: error: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Werror=sign-compare]
     if (len < 1+1+1+iParmLen)
             ^
card-setcos.c:876:13: error: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Werror=sign-compare]
     if (len < 1 + iACLen)
             ^
cc1: all warnings being treated as errors

I can provide more specifics if/as needed later

[frankmorgner]

If you run configure with --disable-strict, those warnings should not be treated as errors...

[seanenck]

If I --disable-strict, 8fe377e will build and the regression is there

[seanenck]

If I checkout 8fe377e and git checkout f66ceab -- src/libopensc/card-piv.c the regression no longer occurs

[dengert]

I think he may need #1454 that was merged today.

But I would still like to see a opensc-debug.log and the opensc.conf file when it did work as a CAC card.
The order of the drivers may have been different or one of the card_atr blocks may have said use the CAC driver. (The new minimal opensc.conf does not have any of these card_atr blocks.)

In the opensc-debug.log it looks like it thinks it is a PIV, and the SELECT AID is formated a little different.

[dengert]

Could also be: 3e5a9a4
Would also like to see working and failing opensc-debug.log....

[seanenck]

@dengert I can reproduce, I will try and get you debug logs from before/after tomorrow.

just, again for reference, my opensc.conf is this (with the card_drivers = cac;; added to allow me to use my smartcard for now)

cat /etc/opensc.conf
---
app default {
	# debug = 3;
	# debug_file = opensc-debug.txt
	framework pkcs15 {
		# use_file_caching = true;
	}
}

[seanenck]

Compiled latest and it does appear fixed.

@dengert you said you would still like logs, which I can provide. Do you want working before regression logs + regression logs + after fix of regression logs (3 logs)?

[dengert]

Was the above with card_drivers = cac; ?

It looks like your card is a Dual CAC/PIV card, so either driver can be used. But they see different certs and maybe PINS. So the user has to tell OpenSC which driver they want to use.

Without specifying which order to try internal order is used, You can see the order of drivers by using opensc-tool --drivers

So there may be a few things going on:
Your old opensc.conf with comments may have changed the order so cac was before PIV-II.
It could be the PIV driver had a false positive, but based on https://gist.github.com/enckse/ccb04a38911b777d68f5586ad228aebf it looks like a PIV card.

There is some old code in card-piv.c dating back to 2006, that does not look correct, but has not
caused any problems. The response to SELECT_AID looks a little different from your CAC card. But it still says it is a PIV card.

[seanenck]

The above gist was without specifying card driver when things were not working properly.

Perhaps I am misreading but from what you are saying: my config did not change between when it was working a few days ago and when it stopped working after getting the latest build this morning (I have my config git controlled as well) which would, to me, imply that opensc changed how it dealt with my mostly empty config that I've posted previously.

When I run opensc-tool -D (--drivers does not exist) it still reports PIV-II before cac even though with the changes from today it is now working (card_drivers = cac is not in my config, I removed it after getting latest and seeing it was working several hours ago).

everything is working, this is the report I get from opensc-tool -n right now

Using reader with a card: Alcor Micro AU9560 00 00
Personal Identity Verification Card

> opensc-tool -D
Configured card drivers:
  cardos           Siemens CardOS
  flex             Schlumberger Multiflex/Cryptoflex
  cyberflex        Schlumberger Cyberflex
  gpk              Gemplus GPK
  gemsafeV1        Gemalto GemSafe V1 applet
  asepcos          Athena ASEPCOS
  starcos          STARCOS
  tcos             TCOS 3.0
  oberthur         Oberthur AuthentIC.v2/CosmopolIC.v4
  authentic        Oberthur AuthentIC v3.1
  iasecc           IAS-ECC
  belpic           Belpic cards
  incrypto34       Incard Incripto34
  acos5            ACS ACOS5 card
  akis             TUBITAK UEKAE AKIS
  entersafe        entersafe
  epass2003        epass2003
  rutoken          Rutoken driver
  rutoken_ecp      Rutoken ECP driver
  myeid            MyEID cards with PKCS#15 applet
  dnie             DNIe: Spanish eID card
  MaskTech         MaskTech Smart Card
  atrust-acos      A-Trust ACOS cards
  westcos          WESTCOS compatible cards
  muscle           MuscleApplet
  sc-hsm           SmartCard-HSM
  mcrd             MICARDO 2.1 / EstEID 1.0 - 3.5
  setcos           Setec cards
  PIV-II           Personal Identity Verification Card
  cac              Common Access Card (CAC)
  itacns           Italian CNS
  isoApplet        Javacard with IsoApplet
  gids             GIDS Smart Card
  openpgp          OpenPGP card
  jpki             JPKI(Japanese Individual Number Cards)
  coolkey          COOLKEY
  npa              German ID card (neuer Personalausweis, nPA)
  default          Default driver for unknown cards

[dengert]

From what we have so far, 8fe377e introduced a problem, which was fixed by 3631b2d in #1454 The problem caused the PIV driver to not beable some objects for teh card.

What was confusions was you referred to your card as a CAC card, which usually means you want to use the CAC driver and it was using the CAC driver in the past. But your card is a dual CAC/PIV. So it may have been working for you in the past using the PIV driver. Is this correct?

I was under the impression that previously the CAC driver was being selected and somehow the many changes cause the PIV driver to be selected. It now sounds like nothing has changed in selection of drivers and PIV was selected all along and things are back to normal.

[seanenck]

Yes, as far as I'm aware it was using the PIV driver (it would be a dual PIV/CAC), stopped (my workaround was to tell it to use CAC), and then after the fix has started working without issue. Sorry if I caused any confusion previously (hopefully I don't introduce more).

I mainly opened this ticket because I experienced the regression for more than "1 build" and more than "1 day" (I use nightly builds of opensc) and wanted to make sure that this was either a known change or that it had eyes on it if it was an issue.

At this point: is there value in investigating this further? I will assist however I can if it should move forward, at the same point if we don't want to chase a solved problem, that is understandable as well.

[dengert]

This issue can be closed.

[seanenck]

Thanks for the help everyone