| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Track change from hal_rpc_pkey_attribute_t to hal_pkey_attribute_t.
|
|
|
|
|
|
We're going to want this in a separate branch from ksng at least for a
little while, so that we can flip back and forth easily to run the
same tests.
Current code doesn't even compile yet, but is far enough along to be
worth backing up off-machine.
|
|
|
|
|
|
|
|
|
|
|
|
PKCS #11's notion of a "read-only" session is odd: read-only sessions
can still create/modify/destroy objects, just not "token" objects.
C_SeedRandom() has its own special "nope, didn't implement that" error
code, apparently the one everything else uses wasn't good enough.
C_Login() has different error codes for "you're already logged in" and
"you're already logged in as somebody else".
|
|
Testing against https://github.com/google/pkcs11test.git found various
bugs, some trivial, some more interesting, some arguably places where
the specification is looser than pkcs11test. I'm still digging
through the test results, but this commit fixes several of the most
obvious issues.
|
|
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.
|
|
{session,token}_object tables to preserve the mapping from pkcs11 token
objects to libhal pkey objects.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
"p11util" is now something of a misnomer, since there's no longer
anything about it that's specific to PKCS #11. Probably should become
a libhal utility program, eventually.
|
|
This version isn't really expected to work properly, but it's far
enough along to be worth archiving before starting runtime testing.
|
|
So far this is just dumb little things like changed names for old data
types and functions. Changes to use new API features will come later.
|
|
|
|
anything particularly clever with the new capabilities (yet).
|
|
|
|
|
|
|
|
|
