* Add object type "secrkey" to help of --type switch in pkcs11-tool
Reading an object with pkcs11-tool requires the `--type` switch. The help for that switch is currently incomplete as it is missing the (not very friendly named" *secrkey* option used to read out a secret key object.
I have added this information to the help description.
* Update man page
Describe secrkey option of pkcs11-tool's --type switch in man page
Framework-pkcs15.c silently ignores adding objects if MAX_OBJECTS
is exceeded while creating the fw_data objects. This simple fix
is to change the MAX_OBJECTS from 64 to 128. A better fix would
be to realloc the objects arrays as needed.
__pkcs15_create_data_object and __pkcs15_create_secret_key_object
now return rv like the other __pkcs15_create_*_object routines.
pkcs15_dobj_get_value now calls sc_pkcs15_read_data_object just like
the other pkcs15_*_get_value routines. The problem was introduced
in 0c3412bb 2018-04-09 which added:
`return sc_to_cryptoki_error(SC_SUCCESS, "C_GetAttributeValue");`
before trying to read the data object.
The MAX_OBJECT problem was discovered while trying to use a new PIV
card with 24 standard cert objects and 10 other objects for a total
of 106 objects. Each cert object corresponds to a cert, pubkey,
private key, and the cert object itself for a possible 112 data objects.
The pkcs15_dobj_get_value was found while running:
running pkcs11-tool -r -y data --application-id 2.16.840.1.101.3.7.2.1.1
using git bisect to locate the bad commit. The pkcs11 data objects are
created last from the pkcs15 objects which are a linked list with no limits.
On branch fix-object-restrictions
modified: src/pkcs11/framework-pkcs15.c
* consistently use term "Invalid key ID; must be 1, 2, or 3" in error messages
about invalid key IDs instead of various alternatives.
* use error type SC_ERROR_INVALID_ARGUMENTS instead of SC_ERROR_INVALID_DATA
when the key_id was passed to the respective function
* harmonize the checks to consistently use 'key_id < ... || key_id > ...'
In addition, initialize a variable to keep clang & compilers on OSX happy.
Combine sequences
sc_log(..., "...");
LOG_FUNC_RETURN(...);
where c_log() prints a constant string
by
LOG_TEST_RET(..., "...");
This change results in shorter, more concise code as well as
better harmonized error messages.
Don't terminate the messages with a period, because they are going to end up
as the first argument to a format string of the form "%s: ...".
I.e. they will be part of a longer string and terminated by a colon anyway.
When card->sm_ctx.ops.free_sm_apdu gets called in sc_sm_single_transmit
with a prior transmission error, then `sm_encrypt` still tries to
decrypt the response and hence, accesses the previously uninitialized
`resp`.
Use defined symbolic names for well-known DOs to copy data to a correctly
defined buffer 'apdu_data' using ulong2bebytes() instead of relying on
"magic" constants and C's string semantic.
Also use 'sizeof(apdu_data)' instead of additional magic constants.
Use defined symbolic names for well-known DOs to copy data to a correctly
defined buffer 'data' using ulong2bebytes() instead of relying on
"magic" constants and C's string semantic.
Also use 'sizeof(data)' instead of strange strlen() calculations.
Use defined symbolic names for well-known DOs to copy data to a correctly
defined buffer 'data' using ulong2bebytes() instead of relying on
"magic" constants.
Random data from PIV card is obtained using GENERAL AUTHENTICATE command
for a request of a Challenge from the card. "00 87 00 9B 04 7C 02 81 00"
Usually 8 bytes are returned.
NIST 800-73-3_PART2, "A.1 Authentication of the PIV Card Application Administrator"
"Table 11. Authentication of PIV Card Application Administrator" shows an example of
how to do this.
Some cards (one I have: 3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00)
will not allow 2 of these commands in a row. (Maybe assuming command is only
used as in Table 11 and is expecting the second command.)
Code was added to card-piv.c so if "6A 80" is returned, try the command one more time.
For any other GENERAL AUTHENTICATE failure, SC_ERROR_NOT_SUPPORTED is returned.
piv_get_challenge may be called within a loop from sc_get_challenge if more random
data is needed thus causing the the 2 commands to sent in a row.
On branch piv-improved-matching
Changes to be committed:
modified: card-piv.c