| Age | Commit message (Collapse) | Author |
|---|
|
Apparently this is how the cool kids handle hiding library-internal
symbols now, using objcopy is old hat. Ondrey tells us that this
should work on GNU/Linux and on *BSD, which, at the moment, just
leaves OSX, which we already handle with an OSX-specific kludge.
|
|
|
|
Oleg found a cute bug where C_SignUpdate() and C_SignFinal() would
generate an incorrect signature which C_VerifyUpdate() and
C_VerifyFinal() would think was fine because the verification code had
essentially the same bug as the signature code. None of this applied
to the (much) more commonly used C_Sign() and C_Verify() functions,
which is why nobody noticed until now.
Bug fixed in sw/libhal commit 36dfaf0adbddbb9f1f7852911228b3ab24ba01aa
but we need a regression test to make sure we don't reintroduce the
bug. So we add a test which computes the signature both ways, then
verifies it with PyCrypto as well as both ways with our own code.
We should probably be doing more comparisons of RSA results with
PyCrypto. For ECDSA with non-deterministic signatures it's a bit
harder, but more checking against the Python ecdsa library would still
be a good idea.
|
|
Database location environment variable is now CRYPTECH_PKCS11_DATABASE.
Installed library is now libcryptech-pkcs11.{so,dylib}.
|
|
Like several other recent commits, this just nails up some value which
really should be coming from the HSM via some as-yet-unwritten RPC
call, but that can wait until after the upcoming workshop.
|
|
|
|
opensc's pkcs11-tool wants to use C_GetInfo(), C_GetSlotInfo(), and
C_GetMechanismList(). All are trivial functions, but we hadn't
implemented any of them. As with most of the informational functions,
some of the returned values are nonsense: in the long run, fixing this
just means adding one or more new informational queries to the RPC
protocol, but I'm not going to do that while we're in, well, not code
freeze, but at least code jello.
Adding C_GetMechanismList() exposed that we had never added all the
SHA-224 variants to pkcs11.c: since these are just a pass-through to
libhal, adding them now seems low-risk (famous last words).
Closes #40.
|
|
|
|
|
|
Apple, for reasons unknown, chose not to implement SOCK_SEQPACKET.
This works on Linux and *BSD, and libhal's MUX daemon uses it to avoid
having to add its own framing protocol on top of SOCK_STREAM. So, at
least for now, Mac OS X will not support the multiplex daemon, only
direct connection to the HSM by a single client.
|
|
{session,token}_object tables to preserve the mapping from pkcs11 token
objects to libhal pkey objects.
|
|
${foo_BLD} Makefile cleanup.
|
|
really need it for libpkcs11.
|
|
|
|
|
|
The Mac OS X build compiles, but is otherwise completely untested, and
won't even be testable until cryptech_rpcd support configuring
high-speed UARTs on Mac OS X (OS-specific voodoo).
|
|
|
|
tweaks Lintian wanted.
|
|
garbled reports if a test fails.
|
|
Disable 3416-bit RSA key generation tests while we sort out whether
simply padding the modulus out to the next 32-bit boundary is
sufficient to support these with ModExpS6/ModExpA7.
|
|
|
|
|
|
* Don't modify the wheel PIN unless specifically requested
* Don't try to run the Novena RPC test server (or any server) by default.
Still need to rewrite some of the RSA key tests, particularly the
external key load test, to conform to known implementation constraint
that key length must be a multiple of 32 bits; deferred until we
switch back to hardware modexp, as this won't matter until then.
|
|
|
|
|
|
|
|
|
|
|
|
key is a session object. Doesn't actually save us anything, but Jakob
tells us that this makes a difference on some HSMs so we people use
this kind of setup and we need to support it.
Explicitly disallow private keys as session objects, since we have no
way to protect them. Update unit-tests now that we return the correct
error code for this case.
|
|
|
|
keys to be stored as session objects, so test that doing so fails as
expected, and update other tests to specify CKA_TOKEN = True.
|
|
|
|
created by earlier keypair.
|
|
token, since we just demonstrated (the hard way) that testing only one
is not sufficient.
|
|
|
|
in handle lookup code.
The mapping between PKCS #11 objects and libhal handles isn't quite
right yet. This is a snapshot of bugfixes accumulated along the way,
before refactoring mapping code to deal with the underlying problem.
|
|
Error handling and hte underlying functions and macros that support it
will probably change a bit more as it goes along. Trying to strike
the right balance between having the main code be readable and having
the underlying support code be at least comprehensible and
straightforward to review.
Also need to address current over-use of CKR_FUNCTION_FAILED.
|
|
|
|
|
|
|
|
|
|
Turns out that the one remaining old PKCS #11 unit test we weren't
passing was a broken test: code was correctly rejecting CKA_ID
conflicts. Rewrote test, and added test setup code to use separate
client and server keystores when using the ks_mmap keystore driver.
|
|
At this point we are passing most of the unit tests in RPC loopback
mode. Remaining failure is TestKeys.test_keygen_token_vs_session(),
which gets HAL_ERROR_KEY_NAME_IN_USE when attempting to generate a
session key and a token key with the same CKA_ID value, so clearly
something is not quite right yet in the keystore selection logic.
|
|
|
|
|
|
defaults.
|
|
automatically if present.
|
|
|
|
libhal RPC API takes RSA key lengths in bits, not bytes.
Insisting on receiving matching CKA_ID in both public and private
templates on key generation is probably unwise, so back down using
CKA_ID from private template if provided, otherwise from the public
template, and only raise incompete template error if both are missing.
|
|
|
