Fix #15
Merged
Fix #15
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
openssl.c: In function 'sc_pkcs11_verify_data': openssl.c:384:19: warning: 'pkey_ctx' may be used uninitialized in this function [-Wuninitialized] openssl.c:325:16: note: 'pkey_ctx' was declared here
LudovicRousseau
added a commit
that referenced
this pull request
Jan 9, 2012
misterzed88
pushed a commit
to misterzed88/OpenSC
that referenced
this pull request
Apr 6, 2020
available, resorting to card-level settings from PIN policy when needed. This fixes interoperability problems with cards where there is PKCS OpenSC#15 PIN info available. Update the PIN info command to return PIN verification state and number of remaining PIN attemts. This info is needed and used all the way out to the applications, through the PKCS OpenSC#15 and PKCS OpenSC#11 layers.
misterzed88
pushed a commit
to misterzed88/OpenSC
that referenced
this pull request
Apr 6, 2020
- Simplifying code and avoiding code duplication, including the PIN-pad case. - We automatically get the needed support for padding the PIN. After this change the PIN verification for the Idemia Cosmo 8 cards is interoperable with the AWP middleware, as long as the card is used through the PKCS OpenSC#15/PKCS OpenSC#11 APIs where we have the proper PIN policy available.
misterzed88
pushed a commit
to misterzed88/OpenSC
that referenced
this pull request
Apr 6, 2020
… for PIN unblock operations. This helps some of the card drivers which otherwise would have a hard time locating the PUK for a PIN.
misterzed88
pushed a commit
to misterzed88/OpenSC
that referenced
this pull request
Apr 6, 2020
…or a PIN during an unblock operation (this is a sign of a card with invalid PKCS OpenSC#15 info). Without this error message the program just terminated silently, which is confusing to the user.
This was referenced Jun 29, 2020
misterzed88
pushed a commit
to misterzed88/OpenSC
that referenced
this pull request
Jul 2, 2020
… for PIN unblock operations. This helps some of the card drivers which otherwise would have a hard time locating the PUK for a PIN.
5 tasks
frankmorgner
pushed a commit
that referenced
this pull request
Jul 2, 2020
unblock operations. This helps some of the card drivers which otherwise would have a hard time locating the PUK for a PIN.
misterzed88
pushed a commit
to misterzed88/OpenSC
that referenced
this pull request
Jul 4, 2020
…or a PIN during an unblock operation (this is a sign of a card with invalid PKCS OpenSC#15 info). Without this error message the program just terminates silently, which is confusing to the user.
5 tasks
frankmorgner
pushed a commit
that referenced
this pull request
Jul 22, 2020
…or a PIN during an unblock operation (this is a sign of a card with invalid PKCS #15 info). Without this error message the program just terminates silently, which is confusing to the user.
riastradh
pushed a commit
to riastradh/OpenSC
that referenced
this pull request
Aug 19, 2020
The previous erase sequence did not always work. For example: % pkcs15-init -C Using reader with a card: Feitian ePass2003 00 00 New User PIN. Please enter User PIN: 1234 Please type again to verify: 1234 Unblock Code for New User PIN (Optional - press return for no PIN). Please enter User unblocking PIN (PUK): Failed to create PKCS OpenSC#15 meta structure: Security status not satisfied % pkcs15-init -E Using reader with a card: Feitian ePass2003 00 00 Failed to erase card: Security status not satisfied This apparently bricked many people's ePass2003 devices: OpenSC#767 https://sourceforge.net/p/opensc/mailman/message/33621883/ https://github.com/OpenSC/OpenSC/wiki/Feitian-ePass2003 Feitian provided a proprietary binary blob called `FIX_TOOL' to recover devices from this state, but declined to offer source code when asked: https://download.ftsafe.com/files/ePass/Fix_Tool.tar.gz https://download.ftsafe.com/files/reader/SDK/Fix_Tool_20200604.zip With reverse-engineering help by Saleem Rashid (@saleemrashid on Github), I was able to find the sequence of three APDUs that the tool submits to the device to erase it. The mechanism seems to be: 1. Install a magic PIN. This is like install_secret_key, as used by internal_install_pin, but with a few different magic constants. 2. Verify the magic PIN. 3. Delete the MF file, without selecting anything first. With this patch, `pkcs15-init -E' successfully erases my ePass2003, and I am able to initialize it with `pkcs15-init -C -p pkcs15+onepin' if I set both a user pin and a PUK. (This patch does not prevent the ePass2003 from getting into the state which could not be erased by the old erase sequence.)
frankmorgner
pushed a commit
that referenced
this pull request
Sep 23, 2020
The previous erase sequence did not always work. For example: % pkcs15-init -C Using reader with a card: Feitian ePass2003 00 00 New User PIN. Please enter User PIN: 1234 Please type again to verify: 1234 Unblock Code for New User PIN (Optional - press return for no PIN). Please enter User unblocking PIN (PUK): Failed to create PKCS #15 meta structure: Security status not satisfied % pkcs15-init -E Using reader with a card: Feitian ePass2003 00 00 Failed to erase card: Security status not satisfied This apparently bricked many people's ePass2003 devices: #767 https://sourceforge.net/p/opensc/mailman/message/33621883/ https://github.com/OpenSC/OpenSC/wiki/Feitian-ePass2003 Feitian provided a proprietary binary blob called `FIX_TOOL' to recover devices from this state, but declined to offer source code when asked: https://download.ftsafe.com/files/ePass/Fix_Tool.tar.gz https://download.ftsafe.com/files/reader/SDK/Fix_Tool_20200604.zip With reverse-engineering help by Saleem Rashid (@saleemrashid on Github), I was able to find the sequence of three APDUs that the tool submits to the device to erase it. The mechanism seems to be: 1. Install a magic PIN. This is like install_secret_key, as used by internal_install_pin, but with a few different magic constants. 2. Verify the magic PIN. 3. Delete the MF file, without selecting anything first. With this patch, `pkcs15-init -E' successfully erases my ePass2003, and I am able to initialize it with `pkcs15-init -C -p pkcs15+onepin' if I set both a user pin and a PUK. (This patch does not prevent the ePass2003 from getting into the state which could not be erased by the old erase sequence.)
xhanulik
added a commit
to xhanulik/OpenSC
that referenced
this pull request
May 18, 2022
1 task
frankmorgner
pushed a commit
that referenced
this pull request
Mar 22, 2023
## Driver The card runs CardOS 5.4, the new driver is therefore a stripped-down version of ```card-cardos.c``` The only place where I have to diverge from the original driver is ```set_security_env```, because the card expects ```MSE RESTORE``` instead of ```MSE SET```. I abuse ```key_ref``` to store the corresponding ```seIdentifier```, as our pkcs\#15 structures do not include the entry. Because the card shares the ATR with other CardOS 5.4 cards, the new driver precedes ```cardos-driver``` within ```internal_card_drivers[]```. ## PKCS\#15 emulation Within EF.DIR there are 5 applications. The last two carry (apparently not entirely usable) PKCS\#15 structures. ```pkcs15-skeid.c``` binds the _fourth_ application in the list. Otherwise ```sc_pkcs15_bind_internal``` would get called and create an unusable token. In the case of the fifth application this is prevented by ```SC_PKCS11_FRAMEWORK_DATA_MAX_NUM = 4```. Because there is no point in calling ```sc_pkcs15_bind_internal``` for this card, I added it to ```sc_pkcs15_is_emulation_only```. This does not prevent ```sc_pkcs15_bind_internal``` from [getting called](https://github.com/OpenSC/OpenSC/blob/70771735ae10180bb039043b9a1b00b66bf00fc1/src/libopensc/pkcs15.c#L1296 ) though (if synthetic binding was unsuccessful). I consider this behaviour a bit counterintuitive. I mention it here to report on and justify what I have done, it has no noticeable effect on my driver (any more). Let me know if ```sc_pkcs15_is_emulation_only``` warrants a separate GitHub issue. ## PINs There is a global User PIN labeled BOK. The qualified certificate (key) requires user consent and a separate (local) Signature PIN labeled KEP. The "official" proprietary PKCS\#11 module requires both the codes for every signature. Fortunately, the card is happy with the Signature PIN only, as there seems to be no convenient way to have multiple PIN codes per slot. I considered emulating (parts of) the "official" behaviour wihtin a custom ```pin_cmd``` that contained the following: ```C if (data->pin_reference == 0x87 && data->cmd != SC_PIN_CMD_CHANGE && data->pin_type != SC_AC_CONTEXT_SPECIFIC) { sc_log(card->ctx, "Non-specific KEP PIN encountered, handling it as BOK instead."); data->pin_reference = 0x03; } ``` I ultimately decided against the idea. It adds complexity (or confusion) and provides little benefit. I mention the issue because it is connected to a failure in ```pkcs11-tool --test --slot 1 --login```: [log](https://github.com/OpenSC/OpenSC/files/10326667/pkcs11-tool_test_slot_1.log). Because the local Signature PIN is used for the session, ```test_verify()``` fails [here](https://github.com/OpenSC/OpenSC/blob/70771735ae10180bb039043b9a1b00b66bf00fc1/src/tools/pkcs11-tool.c#L6639). The card enforces CKA_ALWAYS_AUTHENTICATE and therefore reports that the Signature PIN is (no longer) verified, apparently because signatures have been computed during ```test_signature()```. The only effect of this is that the built-in test fails even though the token works (reasonably) well. The above ```pin_cmd``` hack would result in a passed ```pkcs11-tool --test --slot 1 --login```. I include this information mainly to justify a PR with a failed test attached. If the behaviour of ```pkcs11-tool --test``` in the context of a local Signature PIN and ```user_consent``` warrants a separate GitHub issue, do please let me know. For completeness, [here](https://github.com/OpenSC/OpenSC/files/10326703/pkcs11-tool_test_slot_0.log) is the output of ```pkcs11-tool --test --slot 0 --login```.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
openssl.c: In function 'sc_pkcs11_verify_data':
openssl.c:384:19: warning: 'pkey_ctx' may be used uninitialized in this function [-Wuninitialized]
openssl.c:325:16: note: 'pkey_ctx' was declared here