needed to store information about EC curve supported by card.
Primary usage is when importing/generating key to get know if particular curve is supported by card.
This adds algorithm IDs 0xA, 0xA, 0xC which as documented
by the NIST PIV specification is algorithms AES-128, AES-192
and AES-256 respectively.
This patch also addresses some of the hardcodes that prevented
nonces greater than the single byte TLV length tags would allow.
It was explicitly tested with AES-256 and 256 byte nonces.
Signed-off-by: William Roberts <w2.roberts@samsung.com>
fixes a lot of warnings which pass a const buffer to the APDU's data
Note that a non-const data member is only required for sc_allocate_apdu
sc_free_apdu. They are currently used with an explicit typecast.
However, sc_allocate_apdu and sc_free_apdu both are not used once in the
entire project. One might also simply throw both functions away.
-- Both are thrown away. (VT)
In PukDF of PKCS#15 the public key value can be presented by 'direct value', by path or by path and reference.
For the different cards the public key can be stored in EF, internal EF or in card specific SDO (security data objects).
A new card handle allows to read out the public key from the card specific SDOs.
CK_VERSION is included into PKCS#11 data but is not specified by PKCS#15.
CK_VERSION can be provided by card's pkcs15 emulator or by the card's driver,
including the cards with the native support of pkcs#15 (and thus without pkcs15 emulator).
That's why the more general solution is to have these data included into 'sc-card' data type.
'PACE' is extremely card specific protocol and has not to be ostensibly
present in the common part of OpenSC:
* currently in OpenSC there is no card driver that supports or uses this protocol;
* amazing content of the common 'sc_perform_pace' -- beside the verbose logs
the only substantial action is to call the card/reader specific handler.
According to the current sources and the pull request 83
this 'common' procedure is called by the card driver or
card specific tool/operation.
* currently the 'PACE' can be thouroghly tested only by one person (Frank Morgner),
and only using the OpenSSL patched with the PACE specific patch.
So, at least a dedicated configuration option could be introduced when comiting PACE to the common part.
* common 'sc_perfom_pace' has the same role as the 'initialize-SM' handler of the existing SM framework
and can be implemented as card specific SM, as the others cards do.
This confirmed by Frank Morgner, the author of PACE commits and nPA card driver, himself.
(https://github.com/OpenSC/OpenSC/pull/83)
To be used in windows:
"In Windows, file handles can not be shared between DLL-s, each DLL has a separate file handle table.
For that reason reopen debug file before every debug message."
sc_context_repair() procedure from Hunter William
"Workaround some threading and data lifetime issues when card handle changes and need to re-associate card"
http://www.opensc-project.org/pipermail/opensc-devel/2011-December/017445.html
Introduce some usefull define macros, error code 'inconsistent configuration'.
Introduce procedure to calculate CRC32 digest,
to be used in minidriver to calculate the 'freshness' values.
Implements PC/SC interface to PACE-enabled readers defined in PC/SC
pt. 10 AMD 1 and BSI TR-03119.
PACE can be started using `sc_perform_pace`. This function currently
calls the new `perform_pace` from `struct sc_reader_operations`, if the
reader has the needed capabilities. `sc_perform_pace` could also be
extended with a stand-alone implementation of PACE (code could be
imported from here http://vsmartcard.sourceforge.net/npa/README.html).
Note that the reader's PACE capabilities are correctly determined by
calling GetReaderPACECapabilities.
OpenSC's new PACE capabilities can be tested using the `npa-tool` from
the Virtual Smart Card Architecture (see link above).
* Print out warning when mlock fails, and continue.
* The warning required a ctx to be passed in, so that means
changing a few function signatures.
https://www.opensc-project.org/opensc/ticket/389
On Windows every DLL has their own file descriptor table, thus specifying
-v from any of the OpenSC tools resulted in a crash when the tool tried to override
ctx->debug_file with stderr.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5359 c6295689-39f2-0310-b995-f0e70906c6a9
It is used by cardmod to pass in pointers to the PC/SC handles
provided by the caller of cardmod. Other drivers will return
an error if this routine called.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5190 c6295689-39f2-0310-b995-f0e70906c6a9
; 'known' pkcs#15 applications are moved to the head of the card applications array;
; card specific 'bind finalization' code moved to the dedicated procedures;
; remove unused sc_application member, procedures;
; remove commented code;
; add debug messages;
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5045 c6295689-39f2-0310-b995-f0e70906c6a9
when used with virtual reader, the APDUs can be buffered in the reader's
internal buffer, before sending it to the distant card.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5021 c6295689-39f2-0310-b995-f0e70906c6a9
Frank Morgner
Viktor Tarasov
William Roberts
Stef Walter
andre
vtarasov
martin
dengert