From 4f7d9f0bcc0de535083bdc240f1f5c1037955990 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Mon, 29 Jun 2015 16:58:04 -0400 Subject: Update README.md. --- README.md | 87 ++++++++++++--------------------------------------------------- 1 file 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" -- cgit v1.2.3