1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
{{{
#!htmlcomment
This page is maintained automatically by a script. Don't modify this page by hand,
your changes will just be overwritten the next time the script runs. Talk to your
Friendly Neighborhood Repository Maintainer if you need to change something here.
}}}
{{{
#!html
<h1>PKCS #11</h1>
<h2>Introduction</h2>
<p>This is an implementation of the <a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a> API for the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a>
project. Like most PKCS #11 implementations, this one is incomplete
and probably always will be: PKCS #11 is very open-ended, and the
specification includes enough rope for an unwary developer to hang not
only himself, but all of his friends, relations, and casual
acquaintances.</p>
<p>Along with the PKCS #11 library itself, the package includes a
companion Python interface ("cryptech.py11"), which uses the ctypes
module from the Python standard library to talk to the PKCS #11
implementation. The Python implementation is intended primarily to
simplify testing the C code, but can be used for other purposes; while
it seems unlikely that anything could ever make PKCS #11 "fun", the
<code>cryptech.py11</code> library attempts to make it a bit less awful by
providing both direct acess to the raw PKCS #11 API and a somewhat
more "pythonic" API layered on top of the raw API.</p>
<h2>Novel design features</h2>
<p><a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a>'s data model involves an n-level-deep hierarchy of object
classes, which is somewhat tedious to implement correctly in C,
particularly if one wants the correspondence between specification and
code to be at all obvious. In order to automate much of the drudge
work involved, this implementation uses an external representation of
the object class hierarchy, which is processed at compile time by a
Python script to generate tables which drive the C code which performs
the necessary type checking.</p>
<h2>Current status</h2>
<p>As of this writing, the implementation supports only the RSA, ECDSA,
SHA-1, and SHA-2 algorithms, but the design is intended to be
extensible.</p>
<p>The underlying cryptographic support comes from the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a>
<code>libhal</code> package.</p>
<p>Testing to date has been done using the <code>bin/pkcs11/</code> tools from the
BIND9 distribution, the <code>hsmcheck</code> and <code>ods-hsmutil</code> tools from the
OpenDNSSEC distribution, the <code>hsmbully</code> diagnostic tool, the Google
<code>pkcs11test</code> test suite, and a somewhat ad hoc set of unit tests using
Python's unittest library along with our own <code>cryptech.py11</code> library.</p>
<p>The library is also known to work as an <code>OpenSSL</code> engine when used
with the <code>engine-pkcs11</code> package spun out of the OpenSC project. This
has not been tested extensively, but key generation, signature, and
verification all work (with RSA keys -- the engine appears not to
understand ECDSA keys, we have not investigated into details here).</p>
<h2>Copyright status</h2>
<p>The <a href="http://www.cryptsoft.com/pkcs11doc/STANDARD/" title="PKCS #11">PKCS11</a> header files are "derived from the RSA Security Inc.
PKCS #11 Cryptographic Token Interface (Cryptoki)". See the
<code>pkcs11*.h</code> header files for details.</p>
<p>Code written for the <a href="https://cryptech.is/" title="Cryptech">Cryptech</a> project is under the usual Cryptech
BSD-style license.</p>
}}}
[[RepositoryIndex(format=table,glob=sw/pkcs11)]]
|| Clone `https://git.cryptech.is/sw/pkcs11.git` ||
|
