aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRob Austein <sra@hactrn.net>2015-06-29 16:58:04 -0400
committerRob Austein <sra@hactrn.net>2015-06-29 16:58:04 -0400
commit4f7d9f0bcc0de535083bdc240f1f5c1037955990 (patch)
treeb022b561aac4243bea3aed9cef9b6aa18ea7ba90
parentaf566e0a410b81832d9b107833d1c978e02ef48d (diff)
Update README.md.
-rw-r--r--README.md87
1 files changed, 16 insertions, 71 deletions
diff --git a/README.md b/README.md
index be84f6b..2ddcb09 100644
--- a/README.md
+++ b/README.md
@@ -28,81 +28,30 @@ the necessary type checking.
As of this writing, the implementation supports only the RSA, SHA-1,
and SHA-2 algorithms, but the design is intended to be extensible.
-Underlying cryptographic support is via [Cryptlib][], which may need
-to change (more on this below).
+The underlying cryptographic support comes from the [Cryptech][]
+`libhal` package.
The object store is currently implemented using [SQLite3][], which may
-also need to change (more on this below too).
+also need to change (more on this below).
Testing to date has been done using the `bin/pkcs11/` tools from the
-BIND9 distribution and the `hsmcheck` tool from the OpenDNSSEC
-distribution. Beyond the test results (such as they are) reported by
-these tools, the primary test of whether the PKCS #11 code is working
-as expected has been validation of the signed DNSSEC data generated by
-`hsmcheck -s`, via a script using [DNSPython][].
+BIND9 distribution, the `hsmcheck` and `ods-hsmutil` tools from the
+OpenDNSSEC distribution, and the `hsmbully` diagnostic tool. Beyond
+the test results (such as they are) reported by these tools, the
+primary test of whether the PKCS #11 code is working as expected has
+been validation of the signed DNSSEC data generated by `hsmcheck -s`,
+via a script using [DNSPython][].
In a nutshell, the current state is that the code runs without
throwing any obvious errors, and generates what DNSPython thinks are
-good signatures. Much more testing will be required, by a much wider
-variety of test tools.
+good signatures. More testing would be a really good idea.
-## Open issues ##
+## Open issue: SQLite3 ##
-Two critical design choices in this software were made with full
-knowledge that we might need to change them later:
-
-* The use of Cryptlib as a provider for the underlying cryptographic
- operations, and
-
-* The use of SQLite3 as the object store.
-
-
-### Cryptlib ###
-
-[Cryptlib][] is a very nice piece of software, but it's not really
-designed for use under something like [PKCS11][]. It seemed worth a
-try anyway, because it would have been nice to be able to use
-Cryptlib's RPC mechanism, take advantage of Cryptlib's rule-based data
-protection system, and so forth, but implementing PKCS #11 requires
-doing various things which Cryptlib quite correctly discourages. So,
-not a perfect fit.
-
-The current code works with Cryptlib's software RSA implementation,
-primarily due to an oddity of RSA: once one has handled the PKCS #1.5
-padding, the RSA signature and decryption (sic) operations are
-mathematically identical. Fine so far as this goes, but:
-
-* This probably does not hold for other signature algorithms (well,
- the math certainly does not, I haven't yet investigated what the
- Cryptlib API does if one attempts to "decrypt" using an ECDSA key);
- and
-
-* The Cryptlib manual says that there are some extra protections
- around keys stored in hardware devices that would forbid using this
- trick with an FPGA implementation of RSA.
-
-The latter (extra protections) is probably something we could work
-around if necessary, but the former may make this a moot point.
-
-All of the above notwithstanding, Cryptlib was a reasonable choice for
-the initial implementation, as we had no FPGA RSA to work with and
-needed to develop with *something*. Surprisingly little effort has
-gone into Cryptlib-specific code (probably less than would have been
-required with, eg, OpenSSL, because the Cryptlib API is cleaner).
-
-Bottom line: we haven't lost anything by this approach, we're just not
-done yet.
-
-There are a few other issues with using Cryptlib in this context which
-I will detail if they become relevant, but I'll skip them for now
-since I don't think they'll end up being relevant here.
-
-
-### SQLite3 ###
-
-The choice of [SQLite3][] for the data store was made with several
-factors in mind:
+The choice to use use of [SQLite3][] as the PKCS #11 object store was
+made with full knowledge that we might need to change it later. That
+said, we made the initial choice with several factors in mind:
* Relative ease of development (it's all just SQL schemas and queries);
@@ -118,10 +67,8 @@ factors in mind:
significantly smaller had license issues, eg, gdbm).
Overall, this has worked relatively well, but it's not necessarily
-what we want in the long run: it fails the minimum complexity test,
-and at least in the current implementation requires two separate kinds
-of storage, one for keys (currently a PKCS #15 keyring) and one for
-attributes (the SQLite3 database).
+what we want in the long run, if only because it fails the minimum
+complexity test.
The current implementation keeps much of the SQL data in an in-memory
database: only "token objects" are stored in on disk. This matches
@@ -136,7 +83,6 @@ we're just doing proof-of-concept work, but is something we should
consider seriously before deciding that this is ready for "production"
status.
-
## Copyright status ##
The [PKCS11][] header files are "derived from the RSA Security Inc.
@@ -147,7 +93,6 @@ Code written for the [Cryptech][] project is under the usual Cryptech
BSD-style license.
[PKCS11]: http://www.cryptsoft.com/pkcs11doc/STANDARD/ "PKCS #11"
-[Cryptlib]: https://www.cs.auckland.ac.nz/~pgut001/cryptlib/ "Cryptlib"
[SQLite3]: https://www.sqlite.org/ "SQLite3"
[DNSPython]: http://www.dnspython.org/ "DNSPython"
[Cryptech]: https://cryptech.is/ "Cryptech"