In short, if you did not set your PUK during initialization of the card with applet versions <= v0.6.0, the PUK might have a default value of 00..00, depending on your smartcard.
This might be the expected behavior for you, but it was documented otherwise for IsoApplet.
Hence, I consider this a vulnerability.
Allow me add some technical background.
The JavaCard API provides an object-oriented class for the handling of PINs and PUKs (OwnerPIN).
The behavior of the check method on an non-initialized OwnerPIN object is not defined by the JavaCard API specification. This did not catch my (or anyone else's, unfortunately) eye until now.
Please note that only the PUK is affected in IsoApplet because the PIN is required to be initialized before use of the applet.
Still, the PUK is also handled by an OwnerPIN object - so don't be confused when I speak of OwnerPIN but actually mean the PUK of the IsoApplet.
Some JavaCard firmware/API implementations (read: smartcards) set a default value for the OwnerPIN.
So even if you never initialized the OwnerPIN (IsoApplet: PUK), it might still be initialized.
That's the culprit.
Am I affected?
You are only affected if you did not set your PUK upon initialization of the applet, i.e. skipped entering a PUK when asked by pkcs15-init --create-pkcs15.
I can hardly imagine that this use case would appear in productive deployments.
Furthermore, some smartcard implementations use a sane (in my opinion) approach to handle non-initialized OwnerPIN objects: They cannot be verified.
Among my cards, the following cards are not affected:
NXP JCOP J3A80
AcosJ A40 Dual
The following of my cards are affected:
G&D SmartCafé 6.0 and 7.0
Feitian A40 and A22
You can explicitly test if you can reset your PIN by using opensc-tool -s 002C0001140000000000000000000000000000000030303030.
If is succeeds with SW1SW2 0x9000, you are affected.
However, even if your smartcard follows the "sane" behavior, I would still very much advise you to apply counteractive measures as you are relying on unspecified behavior if you don't.
Please see the following questions/answers.
As a side note, I would obviously highly recommend to set the PUK, anyway.
What is the nature of a possible attack? Has it been exploited on my particular card?
An attack could use RESET RETRY COUNTER APDU to reset you PIN and subsequently use your private keys on the smartcard.
Hence, if you can still use your smartcard with your initial PIN, there has not been an attack.
The attacker needs physical access to your card or exploit your host system, in which case he might also perform different attacks, e.g. sniffing your PIN or hijacking authenticated smartcard sessions.
The main risk is losing your smartcard - so update immediately.
When and how was this fixed? What do I have to do?
This issue was fixed in commit 6810ffc269dad4d844cad899dec6a0d7ca3241db or release 0.6.1, respectively.
If you did set your PUK upon applet initialization, there is no need to take action.
Otherwise, you need to re-install your IsoApplet on your smartcard.
This means that you will lose access to you private key(s).
A different method without losing access to your keys would be to explicitly block your PUK by executing opensc-tool -s 002C000114FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30303030 multiple times (until you see SW1SW2 63C0, i.e. the PUK is blocked and zero tries are remaining).
This should be safe, but I would still advise you to update to the newest IsoApplet version.
Lastly, I would like to sincerely thank Bratislav Planic for discovering and reporting this issue.
If you have questions other than the above, feel free to ask them here or contact me privately: wendlandphilip@gmail.com.
I am sorry for the inconvenience.
What is it?
In short, if you did not set your PUK during initialization of the card with applet versions <= v0.6.0, the PUK might have a default value of
00..00, depending on your smartcard.This might be the expected behavior for you, but it was documented otherwise for IsoApplet. Hence, I consider this a vulnerability.
Allow me add some technical background. The JavaCard API provides an object-oriented class for the handling of PINs and PUKs (
OwnerPIN). The behavior of thecheckmethod on an non-initializedOwnerPINobject is not defined by the JavaCard API specification. This did not catch my (or anyone else's, unfortunately) eye until now.Please note that only the PUK is affected in IsoApplet because the PIN is required to be initialized before use of the applet. Still, the PUK is also handled by an
OwnerPINobject - so don't be confused when I speak ofOwnerPINbut actually mean the PUK of the IsoApplet.Some JavaCard firmware/API implementations (read: smartcards) set a default value for the
OwnerPIN. So even if you never initialized theOwnerPIN(IsoApplet: PUK), it might still be initialized. That's the culprit.Am I affected?
You are only affected if you did not set your PUK upon initialization of the applet, i.e. skipped entering a PUK when asked by
pkcs15-init --create-pkcs15. I can hardly imagine that this use case would appear in productive deployments.Furthermore, some smartcard implementations use a sane (in my opinion) approach to handle non-initialized
OwnerPINobjects: They cannot be verified.Among my cards, the following cards are not affected:
The following of my cards are affected:
You can explicitly test if you can reset your PIN by using
opensc-tool -s 002C0001140000000000000000000000000000000030303030. If is succeeds with SW1SW2 0x9000, you are affected. However, even if your smartcard follows the "sane" behavior, I would still very much advise you to apply counteractive measures as you are relying on unspecified behavior if you don't. Please see the following questions/answers. As a side note, I would obviously highly recommend to set the PUK, anyway.What is the nature of a possible attack? Has it been exploited on my particular card?
An attack could use
RESET RETRY COUNTERAPDU to reset you PIN and subsequently use your private keys on the smartcard. Hence, if you can still use your smartcard with your initial PIN, there has not been an attack. The attacker needs physical access to your card or exploit your host system, in which case he might also perform different attacks, e.g. sniffing your PIN or hijacking authenticated smartcard sessions.The main risk is losing your smartcard - so update immediately.
When and how was this fixed? What do I have to do?
This issue was fixed in commit 6810ffc269dad4d844cad899dec6a0d7ca3241db or release 0.6.1, respectively. If you did set your PUK upon applet initialization, there is no need to take action.
Otherwise, you need to re-install your IsoApplet on your smartcard. This means that you will lose access to you private key(s).
A different method without losing access to your keys would be to explicitly block your PUK by executing
opensc-tool -s 002C000114FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF30303030multiple times (until you see SW1SW263C0, i.e. the PUK is blocked and zero tries are remaining). This should be safe, but I would still advise you to update to the newest IsoApplet version.Lastly, I would like to sincerely thank Bratislav Planic for discovering and reporting this issue. If you have questions other than the above, feel free to ask them here or contact me privately: wendlandphilip@gmail.com. I am sorry for the inconvenience.
I will keep this issue open until 19 June 2019.