| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Overall performance numbers are still bad. Presumably having a single
global PKCS #11 lock does not help here. Need a bitstream with more
ModExp and ECDSA cores before this will matter much, but will likely
need to figure out some way to do per-session locking instead of
global for operations we want to run in parallel. At which point
we'll be on the road to deadlock hell, so will need some care.
|
|
|
|
|
|
At the moment this only works with a single worker thread: multiple
threads get weird errors from PKCS #11. This is probably a PKCS #11
implementation issue rather than a bug in this script. So, in the
spirit of test-driven development, this script is the failing test.
|
|
|
|
|
|
p11util has long since been overtaken by developments: everything it
used to do is now doable on the console, and if for some reason we
really needed a tool to change PINs via the RPC port, we could do it
in a dozen lines of Python using the cryptech.libhal RPC API.
hsmbully may still be a useful test, but all the antics with
configuring SQL database and on-disk keystores is long since obsolete.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Python ctypes library allows us direct access to the public
symbols of a shared library, so we never bothered to implement support
for using the dispatch vector returned by C_GetFunctionList(). Well,
it turns out that there are useful debugging tools like pkcs11-spy
which require the dispatch vector support, so refactor to add it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
