[OpenAFS-devel] Re: configurable cryptosystem support

[Nicolas Williams]

[Apologies for breaking threading.  The mbox on the archive site hasn't
been updated yet and mailman does not show message IDs.]

On January 18, 2007, Marcus Watts wrote:
> Dale Ghent <daleg@umbc.edu> writes:
> ...
> > Dunno if this is exactly what you're looking for, but Solaris has  
> > SCF, the Solaris Crypto Framework which provides kernel-based crypto  
> > (either in hardware or as a software kernel driver) to both userland  
> > and kernel callers.
> > 
> > http://www.sun.com/bigadmin/xperts/sessions/12_crypt/
> > 
> > The programming interfaces are still undocumented, though... at least  
> > for userland, but the cryptoadm(1M) man page is a decent place to start.

The user-land bits are certainly documented: the PKCS#11 spec is the
documentation (plus, the docs.sun.com Solaris Security Developer Guide
has plenty of documentation as well).

> ...
> 
> Um, yes.  Nope, that's not "kerberos 5".  It's probably a perfectly
> good underlying set of cryptographic primitives.  The AES code there
> presumably doesn't do ciphertext stealing, but that's a relatively
> simple elaboration on cbc, which it does provide.
> 
> Sounds like documentation could be an issue.  I hate to ask, but I
> suppose I should -- are these actually "supported" interfaces despite
> the lack of documentation?

The user-land bits of the Solaris Cryptographic Framework are just PKCS#11
(libpkcs11.so.1), and that is a Committed (stable) interface (i.e., you
can use it to your heart's content).  Committed interfaces are also
documented interfaces (see above and below).

The kernel-land bits of it are not, IIRC, a part of the DDI yet, but
that doesn't mean that OpenAFS couldn't get a contract to use them, if
desired.  (A contract meaning that OpenAFS would get suitable warning
prior to any backwards incompatible releases; this should have come up
in the context of VOP interfaces.)

No, support for CTS mode is not included in the SCF, so the caller has
to fashion CTS out of CBC or ECB mode.  And yes, the Solaris krb5 code
currently implements CTS mode fairly inefficiently (with as many calls
into the SCF as there are blocks to encrypt/decrypt; it should really
never do more than two calls into the SCF, and, really, with the benefit
of hindsight I'm starting to wonder at the wisdom of CTS).

OpenSolaris' krb5 crypto bits use the SCF, and the same source (MIT +
CDDL licensed) (with #ifdef KERNELs all over) is used to build the user-
land and kernel-land bits of the GSS-API Kerberos V mechanism.  The
kernel-land mechanism only includes the per-msg token functions and
everything needed to make that work (i.e., the krb5 crypto framework),
but none of the raw krb5 PDUs.

http://docs.sun.com/app/docs/doc/816-4863
http://opensolaris.org/os/community/security/projects/ef/
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/gssapi/mechs/krb5/

If you need more info feel free to ask on security-discuss@opensolaris.org.

Cheers,

Nico
--