can be loaded at ADMINISTRATION life cycle phase to change
the behavior of the VERIFY command in regard to return codes.
When that package is loaded, the return code of the VERIFY
will be ISO7816-4 compliant (63Cx with x being the value of
the remaining retry counter when required verification has failed).
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5565 c6295689-39f2-0310-b995-f0e70906c6a9
can be loaded at ADMINISTRATION life cycle phase to change
the behavior of the VERIFY command in regard to return codes.
When that package is loaded, the PIN can be created with this
"verifyRC" flag in cardos.profile if the return code must be
ISO7816-4 compliant (63Cx with x being the value of the remaining
retry counter when required verification has failed).
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5558 c6295689-39f2-0310-b995-f0e70906c6a9
the first usage is to update the public key PKCS#15 object attributes
and to encode it's direct value.
(support of the Oberthur's AuthentIC V3.2 card)
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@5001 c6295689-39f2-0310-b995-f0e70906c6a9
From http://en.wikipedia.org/wiki/Malloc#Casting_and_type_safety
" Casting and type safety
malloc returns a void pointer (void *), which indicates that it is a
pointer to a region of unknown data type. One may "cast" (see type
conversion) this pointer to a specific type, as in
int *ptr = (int*)malloc(10 * sizeof (int));
When using C, this is considered bad practice; it is redundant under the
C standard. Moreover, putting in a cast may mask failure to include the
header stdlib.h, in which the prototype for malloc is found. In the
absence of a prototype for malloc, the C compiler will assume that
malloc returns an int, and will issue a warning in a context such as the
above, provided the error is not masked by a cast. On certain
architectures and data models (such as LP64 on 64 bit systems, where
long and pointers are 64 bit and int is 32 bit), this error can actually
result in undefined behavior, as the implicitly declared malloc returns
a 32 bit value whereas the actually defined function returns a 64 bit
value. Depending on calling conventions and memory layout, this may
result in stack smashing.
The returned pointer need not be explicitly cast to a more specific
pointer type, since ANSI C defines an implicit conversion between the
void pointer type and other pointers to objects. An explicit cast of
malloc's return value is sometimes performed because malloc originally
returned a char *, but this cast is unnecessary in standard C
code.[4][5] Omitting the cast, however, creates an incompatibility with
C++, which does require it.
The lack of a specific pointer type returned from malloc is type-unsafe
behaviour: malloc allocates based on byte count but not on type. This
distinguishes it from the C++ new operator that returns a pointer whose
type relies on the operand. (see C Type Safety). "
See also
http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014586.html
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4636 c6295689-39f2-0310-b995-f0e70906c6a9
; do not pad PIN in pkcs15init. It's already done in libopensc/pkcs15-pin;
; the 'do_verify_pin()', 'sc_pkcs15init_verify_key()' and 'do_get_and_verify_secret()' are replaced by unique 'sc_pkcs15init_verify_secret()'; edit debug messages;
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4123 c6295689-39f2-0310-b995-f0e70906c6a9
* reduce to a few, supported functions.
* change all functions to take the debug level as parameter.
* use symbolic names for the debug levels.
* fix tools to pass "verbose"/"opt_debug" as ctx->debug.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4118 c6295689-39f2-0310-b995-f0e70906c6a9
This patch is not largely tested and it will be followed (hope in a few hours) with another one
that will replace the using of the static pincache
with the pincache as the content of the AUTH pkcs15 object.
In the intervention into the card specific part I tried to respect its creator's coding style.
Sorry, if it's not always the case.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4057 c6295689-39f2-0310-b995-f0e70906c6a9
When creating application DF ('PKCS15-AppDF'), User PIN is not yet created, and AC type 'SC_AC_SYMBOLIC' cannot be resolved.
So, in the card profile, the macro '$PIN' cannot be used to define the ACLs of the application DF.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3967 c6295689-39f2-0310-b995-f0e70906c6a9
at the profile level the difference between EF and BSO is:
- BSO path is always the path of the host DF and do not indexated when template is instanciated;
- EF path is always ending with file-id that is always indexated when template is instanciated.
New non-static 'sc_profile_get_file_instance' procedure to instanciate non-template entries.
In profile.c get_uint() accepts hexadecimals.
In CardOS profile (I venture to) increase the xDF sizes
and change ACL to permit the key re-importing.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3919 c6295689-39f2-0310-b995-f0e70906c6a9
Nowhere in pkcs15init/pkcs15-cardos.c is the user pin ever
requested or presented to the card.
Since the update acl for the key object uses the user pin, the GENERATE
KEY operation fails when it isn't logged in.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3537 c6295689-39f2-0310-b995-f0e70906c6a9
pkcs15-cardos.c:547:5: warning: "SET_SM_BYTES" is not defined
pkcs15-cardos.c:585:5: warning: "SET_SM_BYTES" is not defined
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3517 c6295689-39f2-0310-b995-f0e70906c6a9
static is a good hint to the compiler for that - the function isn't used
outside of this file.
"static inline" is not valid, visual studio doesn't compile that.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3209 c6295689-39f2-0310-b995-f0e70906c6a9
Viktor Tarasov
jps
vtarasov
andre
ludovic.rousseau
viktor.tarasov
aj
martin
nils